Comments (16)
I think 5.3.4 is more applicable to memcache injection:
5.3.4 Verify that data selection or database queries (e.g. SQL, HQL, ORM, NoSQL) use parameterized queries, ORMs, entity frameworks, or are otherwise protected from database injection attacks.
There are many requirements already to prevent against specific types of attacks:
- 5.2.3, SMTP or IMAP injection
- 5.2.5, template injection
- 5.3.4, 5.3.5, SQL injection
- 5.3.6, JSON injection
- 5.3.7, LDAP injection
- 5.3.8, 12.3.5, command injection
- 5.3.10, XPath injection or XML injection
- 7.3.1, log injection
You could say, "memcache injection is missing from this list!", and you would be right. But I think it is pointless to try to exhaustively list all systems which would be vulnerable to injection. I would rather see more general requirements that work against all forms of injection.
$memcache->set($key, $value);
This shouldn't be vulnerable to injection. The set
function itself should do the escaping, not the caller. I think it does and this blog post is talking nonsense. Memcache injection is possible, but not with this code example.
The blog post also suggests using prepared statements, but memcache doesn't have those. It also seems to confuse memcache and memcached.
from asvs.
How the proposal is different from current 8.1.1?
# | Description | L1 | L2 | L3 | CWE |
---|---|---|---|---|---|
8.1.1 | [MODIFIED, MERGED FROM 8.1.2] Verify that the application prevents sensitive data from being cached in server components such as load balancers and application caches or ensures that the data is securely purged after use. | ✓ | ✓ | 524 |
edit: but if I watch your code example, then there the problem is not caching as such, but not validated/sanitized value for key
. This part is covered in general Input validation and Sanitization requirements.
In general I smell the usual "testing checklist" vs "list of requirements for reporting" mindset difference here.
from asvs.
These two are completely different!!! Memcache Injection represents a specific attack vector that arises from the unique way Memcache interprets concatenated commands. This risk is distinct from merely caching sensitive data.
from asvs.
These two are completely different!!!
Well, there is a bit difference in your proposal as well:
Ensure that data sent to Memcache servers is properly validated and sanitized to prevent Memcache Injection attacks.
May comment was for this proposal - this proposed text is quite similar to 8.1.1 requirement - the end goal is the same.
Now when I watched your code example, it was a bit different problem there than proposed requirement.
from asvs.
I would like to highlight some key distinctions that make the inclusion of specific guidelines for Memcache Injection distinct from what is currently covered in 8.1.1.
Firstly, requirement 8.1.1 primarily addresses the prevention of sensitive data being cached in server components and ensuring secure purging of data post-use. While important, this requirement doesn't explicitly cover the validation and sanitization of data being used in cache operations, especially in the context of Memcache.
The core of Memcache Injection attacks lies in the manipulation of cache keys or values, which is not directly addressed in 8.1.1. The proposed requirement emphasizes the need for specific handling of data sent to Memcache servers, focusing on validating and sanitizing the data used in Memcache commands to prevent attackers from executing malicious operations.
I encourage you to review the nature of Memcache Injection attacks.
from asvs.
I was going to write the answer, but... everything I started to write is already written. Sometimes I wonder do people read before they post comments... :)
For (re)starting point:
edit: but if I watch your code example, then there the problem is not caching as such, but not validated/sanitized value for key. This part is covered in general Input validation and Sanitization requirements.
In general I smell the usual "testing checklist" vs "list of requirements for reporting" mindset difference here.
from asvs.
@Sjord I understand your point about the potential confusion between 'memcache' and 'memcached.' To clarify:
Memcached is the specific open-source distributed memory caching system. It's the actual software that runs as a daemon and provides the caching functionality.
Memcache, on the other hand, is often used more generally to refer to the concept or methodology of caching objects in memory to speed up applications. Additionally, in some programming languages, like PHP, there are libraries named 'Memcache' used to interface with the Memcached service.
Regarding with the set
function, this method is not typically designed to perform escaping or sanitization of input data. Its focus is on caching efficiency, not security.
Let's go for a real world example for Memcache Injection, to simplify this, a user's routing information is stored like this:
user_email = "[email protected]"
cache[user_email] = "server1"
An attacker finds a way to inject a newline character and additional command. Now, the cache has an entry that not only stores the attacker's route, but also executes the malicious command which changes the route for the user to an attacker-controlled server.
I'm curious to understand the reasoning behind the viewpoint that including Memcache Injection in the ASVS would be pointless. Could you elaborate on how we distinguish between vulnerabilities like LDAP or IMAP Injection, which are deemed valid for inclusion, and Memcache Injection, which is considered not necessary to include?
from asvs.
If we separately include things like LDAP injection and IMAP injection, I agree that we can't really ignore memcache injection. I do however think it is highly likely that at some point we will need to compress these requirements into less requirements.
In the meantime, is there any sanitization required other than preventing newlines @ImanSharaf?
from asvs.
I think the best solution for memcache and other forms of injections is to use a library with an API that automatically encodes/escapes/validates. The application does not have to take care of injection anymore, since this is abstracted away by the library. PHP's memcache APIs already do this, so
$memcache->set($key, $value);
is not vulnerable. The problem occurs if the application talks to memcache directly and creates its own commands by concatenating strings.
I think "use a high-level API instead of talking to the other system directly" can be a nice requirement, solving many security problems.
from asvs.
I think "use a high-level API instead of talking to the other system directly" can be a nice requirement, solving many security problems.
From the requirement point of view, it applies to the last bit which communicates with an external component (in this case Memcache).
from asvs.
Thoughts on:
Verify that the application uses a high-level API which performs input sanitization instead of communicating directly with a memcache instance to prevent injection attacks. Alternatively, ensure that content is carefully sanitized before being sent to memcache.
from asvs.
I don't like the direction, I think we should concentrate only on preventing security holes from happening not giving architecture (and not directly security-related) advice.
from asvs.
Having discussed with @elarlang, I think we don't need to be too prescriptive...
Verify that the application sanitizes content before it is being sent to memcache to prevent injection attacks.
Any final thoughts?
from asvs.
Having discussed with @elarlang, I think we don't need to be too prescriptive...
Verify that the application sanitizes content before it is being sent to memcache to prevent injection attacks.
Any final thoughts?
It works for me.
from asvs.
The situation at the moment:
- requirement: Verify that the application sanitizes content before it is
beingsent to memcache to prevent injection attacks. - category/section: "V5.2 Sanitization and Sandboxing"
- level: it depends, how we going to describe levels, at the moment I would say 2
- cwe: there is no precise match, canditates are listed in the "data neutralization issues" list, but I can not see anything to match. Descriptions and titles are quite specific for other problems. So, at the moment I would leave it empty.
from asvs.
Opened #1856 to add this
from asvs.
Related Issues (20)
- 2.3.1 seems weak HOT 1
- 13.4.2 seems too broad and not testable HOT 22
- 13.5.3 rate limiting should apply to all APIs HOT 8
- client should not send longer request headers than server can accept HOT 6
- new V5 section for architecture requirements HOT 2
- Requesting Clarifying Definition in the Business Logic Section Header HOT 3
- Something amiss in requirement description for v5.0-50.5.3 HOT 4
- lowercase vs uppercase grammar (original: 6.2.1 causes capitalization inconsistency) HOT 10
- 5.1.1 - terminology, GET and POST... HOT 14
- clarifying 5.1.3 HOT 9
- Should easily visible logout functionality be a requirement or a recomendation HOT 15
- Tracking supporters HOT 6
- V9 rework - 9.2.5 has insufficient value HOT 5
- 2.10.5 (v4.0.3-9.2.3) - belongs in authentication (needs improvement and scope check) HOT 15
- 7.2.3 (v4.0.3-7.1.3) - wording improvement HOT 4
- 7.2.4 (v4.0.3-9.2.5) - improve the wording to cover all connection errors and failed certificate checks HOT 10
- move section V5.5 (and V5.4) to V10 HOT 18
- Ismael HOT 1
- Finalize web socket requirements HOT 12
- Proposal to remove serverless references HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from asvs.