-
Notifications
You must be signed in to change notification settings - Fork 16
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
__proto__
attack mitigation
#15
Comments
This is an interesting case, in that JavaScript is in this regard already not a superset of JSON. They both accept the syntax, but, as you point out, with conflicting semantics. Since Jessie is supposed to be a subset of JavaScript and a superset of JSON, this is a good enough excuse for banning it. Jessie purposely omits the elements of JavaScript for talking about inheritance: All these considerations support your proposal. I agree. Jessie should statically prohibit syntax naming Thanks! |
I don't understand why this was closed. Shouldn't some change to the Jessie spec happen first? |
Hi Dan, yes. Thanks! |
Hi,
Standard
JSON.parse
prevents people from injecting__proto__
into the parsed objects, which are all derived fromObject
. Instead an "own property" called__proto__
is created. However, this is still relatively dangerous, as code higher up the chain which is not also explicitly defending against__proto__
injections may inadvertantly override the prototype chain with an attacker's input.I would like to propose that creating
__proto__
members is rejected in Jessie. To my understanding, Jessie already rejects mutable properties, so code can't later setobj.__proto__ = {}
. However, I would also like to see the attempt to create the following Jessie object produce an error:Silently creating an "own property" is quite scary, and IMO should be rejected even if it makes Jessie not entirely a static superset of JSON.
Thoughts?
Michael.
The text was updated successfully, but these errors were encountered: