The Problem with JSON

Dietrich Kappe, Thursday, May 10, 2007 @ 3:00 am

I've been tracking the whole insecure JSON debate over the past couple of weeks with some interest. I've been promoting the use of JSONP for a while, so I thought I'd provide a summary of all of the action and summarize what I myself plan to do.

Rob Yates originally proposed some best practices for the use of JSON in secure applications.

When developing a JSON api that contains data that should not be publically accessible to the world use Approach 1 i.e. return plain JSON.

Joe Walker then started the whole imbroglio with his article showing how to subvert JSON services that return arrays. In Joe's example you redefine the Javascript Array constructor, then call a JSON service using a script tag. He later blogged about how this could be done with objects, as well.

Right now these hacks only work on Firefox, and there are limits to the kind of JSON that can be eval'd outside of an assignment statement, but that is no reason to be complacent about this issue.

This guy tried his hand at defeating the above hack by grabbing a fresh copy of the Array object from an iframe, but in the end concluded that in an arms race between the hacker and the application developer on the client-side, the hacker will always win. As Joe Walker pointed out, "In the end you can't trust the environment that you are sending the data to, so you should only send data to people you trust, and that means having URLs that are not predictable."

A related topic (as pointed out in some of the posts above) is that of Cross-Site Request Forgery (CSRF).

Cross-site request forgery, also known as one click attack or session riding and abbreviated as CSRF (Sea-Surf) or XSRF, is a kind of malicious exploit of websites. Although this type of attack has similarities to cross-site scripting (XSS), cross-site scripting requires the attacker to inject unauthorized code into a website, while cross-site request forgery merely transmits unauthorized commands from a user the website trusts. Compared to XSS, CSRF attacks are not well understood by many web developers and few defense resources are available.

These two methods can be used in concert. For example, the JSON hijacking can be used to lift information such as account numbers, and then CSRF is used to construct a URL that causes some sort of malicious action in the application.

As for what I plan to do in my own secure web application development, it remains pretty consistent with what I did before the advent of Ajax:

1. Use SSL, obviously.
2. Don't rely on cookies for authentication and set short timeouts for user sessions. You can require a randomly generated chunk of the path of application url's for each unique session instead.
3. Make sure that all of your URL's that modify data or have other side effects require POST. This doesn't eliminate risk, as an attacker can use Javascript to launch a form POST, but it does cut down on the opportunistic uses of image and other tags that perform a GET -- reducing the avenues of attack.
4. Perform referrer checking. Again, this is no panacea, as an attacker can use flash or XHR to subvert this, but it raises the bar a little more and restricts the avenues of attack further.
5. Use a request token that is dependent on the previous response (SHA-1, etc.) and includes a sequence number. If a request is made that is not valid, the user sessions should be immediately invalidated. (An attacker could theoretically compromise the user's machine so they could defeat even this approach, but at that point I'd have to throw up my hands.)
6. Detect, log and notify on all suspicious activity.
7. Use JSON only for publicly available information, i.e. if they can get it by hacking your browser, they can just as easily get it for themselves.

There are limits, however, to what can be done. As long as browsers have security holes and Javascript allows, well, what is allows, there will always be some new avenue of attack for hackers to exploit. (Let's not even get started on viruses and trojan horses on the client).

Further Reading:

You may want to read an article over at IBM on secure mashups which covers additional ground, such as the use of the fragment identifier (http://host/path#fragment). Also, some additional ideas around REST, HTTP Auth, and resetting the Javascript Array object to its original state through delete Array, can be found here.

Finally, the incomparable Bruce Schneier has a blog entry on a paper on JSON Hijacking. Read it and the comments.

Technorati : ajax, csrf, javascript, json, security

agile ajax

Comments: 1 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   i have read all the comments of rab yates that shown really how to solve the problem of jsdn. really fantastic efforts and ideas

   Comment by mike, Thursday, May 24, 2007 @ 7:56 am

Leave a comment