Hacker News Reader

Comment by jcampbell1 | Hacker News Reader

Douglas Crockford was wrong. This was a real issue back in 2007 that was specific to JSON. A proof of concept exposed gmail contact lists. It is not true for all data formats.

Douglas Crockford defends JSON to the point of making himself look foolish. He causally dismissed this real issue as a non issue, and has done the same with the U+2028/9 line ending issue.

Edit: It is worth pointing out that Google still prefixes their JSON with )]}' to protect users that are still using 2007 browers.

View on HN

The technique of fetching remote content into JavaScript is dangerous. JSON is no more dangerous than any other JS.

Executing foreign code with eval is bad. Parsing foreign text is not. It was a problem when people misused browsers to conflate them.

This has nothing to do with executing foreign code with eval.

Here is how the the attack was performed. On my site, I rewrite the Array constructor. I then add

    <script src="http://gmail.com/mycontacts.json"></script>

Now you visit my site, and I now have stolen all your Google contacts, which are protected by your google password.

You see this has nothing to do with "eval".

That's why google starts their json with while(1); (or something like that) so any effort attempting to evaluate the json itself as javascript code will be stuck in an infinite loop.

The problem here is still "the technique of fetching remote content into JavaScript", not json itself.

I don't understand. Aren't there cross site scripting restrictions?

XSS restrictions generally apply to things such as making XmlHttpRequests from other sites. Loading scripts from other sites generally isn't restricted, since it's used for a variety of legitimate things such as loading jQuery from a CDN.

So how do you prevent this?

Reply on news.ycombinator.com