[ajross]

I gotta ask: that just sounds wrong to me. The fact that it used a built-in parser was supposed to have been a feature of JSON. Have we pedantricized that into a bad thing now too? What's the disadvantage of "allowing invalid JSON" in an application protocol you control? Likewise, what's the value of valid JSON (I honestly don't know what the example here is) that can't be parsed by a Javascript interpreter?

And where does the "huge security hole" come from? I certainly hope you're not saying that you trust requests generated by client code...

[kwamenum86]

"And where does the "huge security hole" come from"

eval'ing a response from a third party essentially runs their code in your context. JSON.parse does not.

[olliej]

The moment you use eval to parse "JSON" data you _are_ trusting content from the client. eval _executes_ javascript, JSON just happens to be mostly compatible with JS object and array literal syntax so it "Just Works".

Because eval is executing the data it is using the full JS parser. That means that while '{"name":"bill"}' works as expected '{"name": window.location = "myevildownload.com"}' does too.

JSON.parse is built into the language. It enforces strict JSON conformance so you can't end up accidentally having invalid content that won't be parsed by other JSON libraries, and it does not execute data -- it creates the object graph and nothing else. If there's anything that is not valid JSON it fails and has no side effects. When constructing the object graph it uses the real Object and Array constructors, so nothing can be injected that way. When setting properties on objects it sets them directly and does not call setters.

If you use JSON.parse to parse your JSON data, it is not possible for an attacker to either run or inject code in your site.

And it's faster than eval.

[majmun]

> The moment you use eval to parse "JSON" data you _are_ trusting content from the client. eval _executes_ javascript, JSON just happens to be mostly compatible with JS object and array literal syntax so it "Just Works".

not nesseserily , this attack could be easily mitigated if supposed JSON string is first parsed and validated on server. and only then send back to eval() on browser.

so it is therefore not inherently unsafe to use eval() on JSON.

[olliej]

Your server side validation would have to be a full JSON parser. So in order to use eval, you're adding a full server side parse of the data on each request, increasing server load, and request latency (i've seen sites sending megs of json to the browser).

All so that you can save 6 characters of typing to load the JSON less efficiently on the client side.

Of course because people _do_ do this most engines these days preflight calls to eval to see if they can be parsed as a subset of pseude-JSON. Note: this doesn't make it safe, any inject xss is not valid json so will still be a hole, and these preparsers try to bail out quickly so treat only a minimal subset of JSON. In JavaScriptCore (so all webkit browsers other than chrome) you can't have escaped characters in string literals nor any non-ascii characters anywhere.

[nickik]

JS is just not enougth lisp in that way. In lisps you have the parser in your langague (read). You cant call eval on a string and thatway avoiding this securety hole.

(You can call eval on a string but it will just return that same string)

[checker]

Cross site scripting. Evaling json enables a vector for javascript code injection and execution.