Skip to content
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

Open
michaelfig opened this issue Dec 23, 2018 · 3 comments
Open

__proto__ attack mitigation #15

michaelfig opened this issue Dec 23, 2018 · 3 comments

Comments

@michaelfig
Copy link
Member

michaelfig commented Dec 23, 2018

Hi,

Standard JSON.parse prevents people from injecting __proto__ into the parsed objects, which are all derived from Object. 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 set obj.__proto__ = {}. However, I would also like to see the attempt to create the following Jessie object produce an error:

let abc = { "__proto__": {}};

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.

@erights
Copy link
Contributor

erights commented Dec 23, 2018

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: new, Object.create and most reflective operations, this, class. A standalone Jessie implementation should not need to support general inheritance. A correct Jessie program must not assume either the existence or non-existence of the rest of the SES runtime; it must run correctly when run as a SES program interacting with other SES objects, and when run on a conforming standalone Jessie implementation. The Object.prototype.__proto__ accessor property is one of these elements of the SES runtime which is absent from the Jessie whitelist.

All these considerations support your proposal. I agree. Jessie should statically prohibit syntax naming __proto__ as a property name, whether with or without quotes, and whether in an object literal or after a dot.

Thanks!

@dckc
Copy link
Contributor

dckc commented Dec 27, 2018

I don't understand why this was closed. Shouldn't some change to the Jessie spec happen first?

@erights
Copy link
Contributor

erights commented Dec 27, 2018

Hi Dan, yes. Thanks!

@erights erights reopened this Dec 27, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants