Hacker News Reader

Comment by tzury | Hacker News Reader

Douglas Crockford's comment on that post:

    This statement is strictly true: JSON is unsafe for
    anything but public data unless you are using  
    unpredictable URLs. It is true for all data formats. 

    There was never a good reason to believe that JSON 
    reduced the need for vigilant design.

View on HN

This is wrong or awkward answer at best.

Your session based generated HTML (i.e. Your Credit Card usage history) is safe against these kind of attacks, also guess what your XML is safe as well and all other data formats that cannot be called and interpreted by JavaScript from another domain. Heck even session based generated images are safe and cannot be read from another domain, other than some rare bugs (they are security bugs and will be fixed, not design issues).

Another format I can think of that cannot keep session based information safe is JavaScript. I wrote about a real world example of this before (a vulnerability in IntenseDebate) : http://www.mavitunasecurity.com/blog/javascript-scope-and-in...

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.

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