JavaScript Hijacking FAQ

Q: The System Administrators should be the ones concerned.

A: This is a software problem. It won't be fixed until programmers fix it. The reason we're talking about it is to try to raise awareness among the Ajax development community.

Q: It doesn't really look like an attack, just a method to parse the results of an already successful CSRF attack.

A: The Same Origin Policy implemented by all major web browsers is designed to prevent parsing the results of a CSRF attack. JavaScript Hijacking takes advantage of a hole in the Single Origin Policy. In many cases, allowing an attacker to both read and write data is significantly worse than simply allowing them to make illegitimate requests.

Q: In order to get any of the examples running you need to have access to the page DOM via XSS or some sort of browser bug.

A: Not so. One of the most important things to note about JavaScript Hijacking is that it does not require the presence of another defect.

Q: It's actually not as bad as it could be, since very few people roll their own Ajax libraries.

A: The only data we could find on this subject suggest that 25% of Ajax programmers are rolling their own. Scary!

Q: The paper does argue that any client-side framework requires your server to be vulnerable to this attack, but it is wrong.

A: The paper does not make that claim. Many of the client-side frameworks default to sending HTTP POST requests, which is a poor defense, but does not require the server to be vulnerable. We only characterize a framework as requiring a server to be vulnerable if it defaults to using HTTP GET and provides no defense against JavaScript Hijacking. When we first wrote the paper, none of the client side frameworks did anything to explain the problem to their users or to prevent a programmer from using the framework in a vulnerable way. We're happy to see that that's changing rapidly.

Q: You don't need to eval JSON, there's also a more restrictive JSON-"parser" for JavaScript. They're all available from json.org

A: The JSON parser from json.org eventually calls eval(), but it doesn't really matter. Calling eval() is not a prerequisite to being vulnerable. All you have to do is create an object, so the problem exists no matter how you parse the JSON.

Q: Most AJAX applications use JSON but a lot of them use {} instead of [] and therefore are protected.

A: This is entirely dependent upon the type of objects that the application is communicating. Array syntax is natural for communicating lists and other collections, and if the outermost structure is an array, all of the contents of the array are vulnerable. If the security of your program depends on your choice of data structures, you're on thin ice.

Q: What I am trying to say is that this paper does not outline anything new.

A: We did our best to give credit to relevant prior work, including Grossman's Google attack and Joe Walker's comments on JSON. What we think is new in the paper is:

1. The generalization of Grossman's attack (he said it could not be used against JSON, but we show that it can).
2. An exploration of how widespread the problem is.
3. A discussion of the possible defenses against the attack.

Q: This is not new. Everyone knows you have to do your input validation on the server and that any data you send down in JavaScript or in HTML can be seen by the user. You don't need fancy <script> tags. Just do "View Source" in your Web browser or hook up a proxy in front of your web browser.

A: While it is true that the client can see any messages the server sends, this is not the scenario where JavaScript Hijacking applies. JavaScript Hijacking involves a vulnerable Web site, a victim with a Web browser, and a malicious Web site. The malicious Web site can use JavaScript hijacking to steal the victim's data from the vulnerable web site. Web browsers prevent this in most cases, but the browser makers did not anticipate the use of JavaScript to communicate confidential data.

Q: You only mention JSON. Can this vulnerability be exploited if you are using XML with AJAX instead of JSON?

A: The paper focuses on JSON because it is currently the most widely used data transport format that makes use of JavaScript syntax. Other formats that use JavaScript syntax are potentially vulnerable too, but XML is not vulnerable; the popular browsers correctly apply the Same Origin Policy to protect XML.

Q: How about Stefano Di Paola and Giorgio Fedon's lecture "Subverting AJAX" from 23rd Chaos Communication Congress? It seems to use quite similar techniques, doesn't it?

A: Over the last year or two, there has been a lot of work on increasingly sophisticated techniques for exploiting vulnerabilities such as cross-site scripting. Much of this work is drawing on the same kinds of JavaScript techniques that are being used to build Ajax applications. Di Paola and Fedon's "Subverting Ajax" paper is a great example. However, JavaScript Hijacking is fundamentally different. It does not piggyback on a cross-site scripting vulnerability. It works against applications that were previously widely considered to be reasonably secure.

Q: Microsoft Atlas checks to make sure the request type is application/json before it processes the request. Doesn't that mean it's immune?

A: Checking for application/json in the content-type header is not enough to prevent JavaScript hijacking. An attacker can simply request the data twice.

Here's a two-step attack that bypasses the check:

1. The attack code uses the Adobe Flash player to request the JSON. By using Flash, the attack can set the content-type header correctly. However, it can't directly see the response. (For more on setting http headers using flash, see http://www.securityfocus.com/archive/1/441014)
2. The attack code now generates a <script> tag and requests the data again. The second time around, the Web browser doesn't go up to the server, it takes the data out of its cache. This time the attacker gets access to the data. Atlas doesn't allow HTTP GET by default, and it doesn't instruct the web browser to cache by default, but some people recommend using GET and caching responses in order to improve application performance. Oops! As with the rest of the frameworks we analyzed, we recommend that Atlas take active steps to prevent JavaScript Hijacking.