About the Author

Chris Shiflett

Hi, I’m Chris: entrepreneur, community leader, husband, and father. I live and work in Boulder, CO.


JavaScript Hijacking

A few readers have asked for my opinion regarding the recent fuss over a "new kind of web-based attack" that's being called JavaScript hijacking:

Security researchers have found what they say is an entirely new kind of web-based attack, and it only targets the Ajax applications so beloved of the Web 2.0 movement.

Although the attack is not at all new, it is worth reading about if you're using Ajax and don't know what CSRF is. Jeremiah's Gmail exploit from early last year is a good example that uses CSRF for information disclosure, which is all this really is.

Being in the web application security profession myself, I appreciate the strong desire among my peers to increase awareness, but I'm not fond of the tendency to deliberately misinform people and incite fear based upon false pretenses. We should strive to offer clarity, not confusion. In this particular case, there are also some strong technical concerns to consider.

In some of the comments I've read in various places, people new to CSRF recommend checking the Referer header as a safeguard. This does not offer sufficient protection against CSRF, because an attacker can forge HTTP headers with Flash.

About this post

JavaScript Hijacking was posted on Fri, 06 Apr 2007. If you liked it, follow me on Twitter or share:

8 comments

1.Shawn Lauriat said:

Thank you for this. I had commented as such on Bruce Schneier's blog link to which Brian Chess had replied somewhat to the effect that I had misunderstood how the attack worked, but it really does just seem to me that they found a quick and easy way of parsing the result of an already successful CSRF attack.

Fri, 06 Apr 2007 at 16:15:43 GMT Link


2.Chris Shiflett said:

I am quite sure that my comment is deleted or not shown at all.

You're right, and with a comment that begins like that, it's not surprising.

Stefan, you've got your own blog to spread vitriol among the people who can tolerate your behavior. Don't expect me to willingly expose my readers to it.

Until you can maintain professional discourse, you won't be allowed to participate in discussions here.

Sat, 07 Apr 2007 at 14:49:45 GMT Link


3.Jordan said:

Bickering aside, I think the technical details that Stefan points out are important. I might temper them a bit with the fact that it's a combination of CSRF and the violation of the same domain policy that makes the attack interesting. If it's not CSRF, then you're not going to get useful data back from your script request, and because you can subvert the javascript object creation, then you get access to the useful data. The really interesting vulnerabilities are in cases where both are an issue.

And in fact, there are two distinct sets of fixes to the problem for that reason. The first class depends on getting the server to not send data back to the client because you can tell it wasn't from your legitimate application (via cookie value on the url, or whatever similar method), and the others depend on helping the browser do the right thing and keep the same domain policy intact (prefixing JSON data with comment characters, for example).

Sat, 07 Apr 2007 at 18:02:18 GMT Link


4.Stefan Esser said:

Jordan,

you will find many different definitions of the term CSRF. If you read for example the wikipedia definition you will read:

The following characteristics are common to CSRF:

* Involve sites that rely on a user's identity

* Exploit the site's trust in that identity

* Trick the user's browser into sending HTTP requests to a target site

* Involve HTTP requests that have side effects

If you look at the last point you will see that the <SCRIPT> attack is not a CSRF according to the Wikipedia definition at all. And not only in the Wikipedia definition. Most people exclude data retrieval only URLs from CSRF because they do not perform an action on behalf of the victim, but only retrieve data that is under normal circumstances not readable by the attacker because of Cross Domain Policies. Because an attacker cannot get this data under normal circumstances it is usually not considered a vulnerability, because it cannot be abused without browser vulnerabilities.

This is (or better was) actually also the definition of Mr. Shiflett himself. But hey, it would not be the first time that he redefines some term just to not be wrong.

Sat, 07 Apr 2007 at 19:10:26 GMT Link


5.Chris Shiflett said:

Hi Jordan,

Very well put. Because this particular problem is a subset of CSRF, developers can opt to address the symptom, the root cause of the problem, or both.

In the technical discussions I've read, there seems to be too much emphasis on addressing the symptom. I think this can at least be partially attributed to the fact that this is being promoted as a new problem, so developers understandably want to find new solutions.

These new solutions have merit (defense in depth), but a failure to address the root cause of the problem incurs a risk that's worth considering.

Sat, 07 Apr 2007 at 19:15:39 GMT Link


6.Chris Shiflett said:

Hi Stefan,

Thanks for trying to be professional. That's all I ask.

If you look at the last point you will see that the <SCRIPT> attack is not a CSRF according to the Wikipedia definition at all.

I think this particular point in the Wikipedia article is misleading. CSRF is not restricted to requests that perform an action. There are other reasons to forge requests. For example, capturing JavaScript errors is a technique that can be used to work around the same-origin policy for port scanning, checking to see whether a user is logged in, etc.

The distinction made in the Wikipedia article might be due to someone who believes that forging a request is only a problem if it performs an action, because an attacker cannot access the response. Clearly, this is not true.

This is (or better was) actually also the definition of Mr. Shiflett himself.

Yes, the Wikipedia article and most other descriptions of CSRF are at least partially based upon Foiling Cross-Site Attacks or Security Corner: Cross-Site Request Forgeries, but this doesn't mean I agree with every point in every description.

But hey, it would not be the first time that he redefines some term just to not be wrong.

These baseless, ad hoc attacks are not welcome here. I'll forgive this one, but don't expect this type of behavior to be tolerated again.

Sat, 07 Apr 2007 at 19:47:36 GMT Link


7.Chris Shiflett said:

Matasano Security has posted a straightforward analysis.

In the comments, Thomas Ptacek also makes an astute observation about the severity of this particular breed of CSRF:

If you audit your application for CSRF flaws, you’ve defeated this attack. Moreover, the well-known preexisting exploits for CSRF are actually worse than this attack.

I completely agree.

Sun, 08 Apr 2007 at 19:07:19 GMT Link


8.Chris Shiflett said:

Via Simon, JSON and Browser Security:

Douglas Crockford suggests using secret tokens to protect JSON content, and avoiding wrapper hacks to protect unauthorised JSON delivery as they may fall foul of undiscovered browser bugs in the future.

In other words, address the root cause of the problem instead of symptoms. If you can prevent CSRF, you don't have to worry about JavaScript hijacking.

Wed, 11 Apr 2007 at 14:17:53 GMT Link


Hello! What’s your name?

Want to comment? Please connect with Twitter to join the discussion.