Why we need to clean up __proto__

Allen Wirfs-Brock allen at wirfs-brock.com
Wed Dec 28 15:37:01 PST 2011

On Dec 28, 2011, at 11:58 AM, gaz Heyes wrote:

> I'd also like to add that __proto__ allows valid JSON to change it's object type and allow functions within properties. There isn't a compelling exploit scenerio for this yet but who knows what is possible if setters come into the equation. 

I assume by "valid JSON" you really mean any object literal rather than the use of the built-in JSON.parse function.

The ES5.1 specification for JSON.parse, if strictly followed, should not set the the [[Prototype]] of the object created by JSON.parse('{"__proto__": []}') to anything other than Object.prototype.  The JSON.parse spec. explicitly says  that [[DefineOwnProperty]] is used to create for create properties.  The spec. for JSON.parse also says "It is not permitted for a conforming implementation of JSON.parse to extend the JSON grammars".  It is probably debatable whether or not giving "__proto__" special meaning would is iimplicitly a grammar change.  However, the intent of that statement was that JSON.parse should must operate as specified and without extension. 

Firefox (9 at least) appears to conform to the JSON.parse spec. in this regard.

TC39 has already agreed that as in ES.next is would provide a a normative specification for an "optional" __proto__ feature.  This is a good reminder that when we do that we need to carefully specify details such as requiring that JSON.parse does not recognize it. 

> alert(({"__proto__":[]}).sort)
> alert(({"__proto__":function::['parent']}).location)

The second example threw me for a while until I figured out that :: is an e4X construct.  A conforming implementation of JSON.parse should reject such syntax.


More information about the es-discuss mailing list