-
-
Notifications
You must be signed in to change notification settings - Fork 653
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Missing Prototype Pollution Check in ASVS #1563
Comments
https://twitter.com/JoshCGrossman/status/1635987227736961025 Agree we should have this, I have reached out to @hackvertor for his opinion on your wording:
|
Here are my thoughts on protecting against this attack. I would recommend that developers use new Set() or new Map() instead of using object literals: let allowedTags = new Set();
allowedTags.add('b');
if(allowedTags.has('b')){
//...
}
let options = new Map();
options.set('spaces', 1);
let spaces = options.get('spaces') If objects have to be used then they should be created using the Object.create(null) API to ensure they don't inherit from the Object prototype: let obj = Object.create(null); If object literals are required then as a last resort you could use the let obj = {__proto__:null}; You can also use the Object.freeze() and Object.seal() APIs to prevent built in prototypes from being modified however this can break the application if the libraries they use modify the built in prototypes. Node also offers the ability to remove the |
Sanitizing keys is a bad approach since you have to use a denylist of bad values. It's far better to use new Set() or new Map() since these APIs do not have prototype pollution vulnerabilities provided they are used correctly. |
Thank you, @tghosth and @hackvertor, for your valuable input on the Prototype Pollution check. I appreciate the detailed recommendations on how developers can protect against this type of attack. [NEW] Verify that the application mitigates Prototype Pollution vulnerabilities by employing one or more of the following strategies:
|
So this is still a little too detailed. I would propose:
What do you think @ImanSharaf ? I am separately going to try and get the detailed guidance into a cheatsheet. |
For category it waits: #1643 |
Do you agree with this @ImanSharaf? I will discuss category with elar afterwards, |
To address prototype pollution, I recommend that we do not confine our solutions to exclusively using Set() or Map(). It would be nice to be more flexible in this regard. |
Ok so what wording do you suggest @ImanSharaf ? I think the originally proposed wording is too general...
Note that there is now a cheatsheet on this: https://cheatsheetseries.owasp.org/cheatsheets/Prototype_Pollution_Prevention_Cheat_Sheet.html |
Opened #1843 @ImanSharaf please let know what you think |
That works for me |
I noticed that the ASVS (Application Security Verification Standard) does not include a check for Prototype Pollution vulnerabilities. Prototype Pollution is a critical vulnerability that can allow attackers to manipulate an application's JavaScript objects and properties, leading to serious security issues such as unauthorized access to data, privilege escalation, and even remote code execution.
As JavaScript applications become more complex, Prototype Pollution attacks are becoming more common. It is therefore essential that the ASVS includes a dedicated check to help ensure that web applications are protected from this type of vulnerability.
I strongly recommend that the ASVS be updated to include a Prototype Pollution check, a sample check could be this one:
The text was updated successfully, but these errors were encountered: