On Tue, Oct 18, 2016 at 8:57 AM, Isiah Meadows <[email protected]> wrote:
> I'll point out that encoding and evaluating JSON literally can easily > become a potential security issue, anyways (consider if a user can encode > `--></script>` in the relevant data). But you might have a point if you > consider JSONP. > This feels like it's drifting a bit. I'm asserting that the "the alternative definition of *DoubleStringCharacter*" required for JSON.parse can in fact become the *only* definition of that production, retroactively validating the currently-false claims in §24.3.1 <https://tc39.github.io/ecma262/#sec-json.parse> of JSON being a subset of ECMAScript literals. U+2028 and U+2028 would still be line terminators for purposes of ASI/line numbering/etc., but would be allowed unescaped in string literals. On Sun, Oct 16, 2016, 22:08 Richard Gibson <[email protected]> wrote: > >> Allow me to clarify: permitting U+2028 and U+2029 in ECMAScript strings >> would allow safely embedding arbitrary JSON in the precise sense that such >> embeddings would always be syntactically valid and evaluatable Literal, >> ArrayLiteral, or ObjectLiteral expressions. That is already true of >> "__proto__" keys, even though their evaluation results in web browsers >> don't exactly match JSON.parse. >> > > By the way, `"__proto__"` is intentionally different than `__proto__` to > avoid a gaping security hole for those using objects as dictionaries > (untrusted code causing prototypes to change is bad). The string version is > no different from any other property, while the identifier version either > gets or sets the prototype. > While irrelevant to the proposed change, that appears to be false (though it would certainly be beneficial if true)—the special check for "__proto__" in Step 5 of §B.3.1 <https://tc39.github.io/ecma262/#sec-__proto__-property-names-in-object-initializers> uses *propKey*, which step 1 defines as "the result of evaluating *PropertyName*", and evaluation of *LiteralPropertyName* in §12.2.6.7 <https://tc39.github.io/ecma262/#sec-object-initializer-runtime-semantics-evaluation> does not preserve a distinction between *IdentifierName* and *StringLiteral* forms in its result. I also observe equal treatment of quoted and unquoted "__proto__" object literal properties in SpiderMonkey, V8, and Chakra.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
