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.
Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
