[olliej]

The post actually appears to endorse using eval to parse JSON. Not only does that allow invalid JSON through, it disallows some valid JSON, and of course is a huge security hole.

If you want to handle JSON data in JavaScript use JSON.parse -- it's the safest, fastest, and most correct path to having your data available to you.

[update: edited to remove bizarre use of whole vs hole... boggles]

[fletchowns]

Yes! I was shocked to see him recommend the use of a straight eval for parsing JSON.

json2.js is a must! JSON.parse and JSON.stringify are your friends.

https://github.com/douglascrockford/JSON-js/blob/master/json...

[Encosia]

Keep in mind that json2.js' JSON.parse() ultimately uses eval() after a few sanity checks. Definitely better than a blind eval(), but not quite the panacea it's often purported to be.

[daleharvey]

just pointing out to others although the parent probably already knew, but JSON.parse is native in all modern browsers, json2 is only needed if you support older browsers (ie7)

[JackdawX]

Holy crap, I did not know that.

[olliej]

Too my knowledge all browsers now ship with json built in -- if you must work with older browsers (not an entirely unreasonable requirement) you should check for the JSON object first, and if it isn't present load json2.js. Otherwise you're just adding an additional load penalty to your site (and on mobile browsers that can be 100s of milliseconds)

[DanielRibeiro]

Json2.js does the check. However, it has to be loaded in order to be checked. Not a big issue if you are minifying and bundling all your js files before sending them to the browser client.

[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.