Javascript Hijacking provides new class of attack vectors for AJAX, and ultimately, ATLAS.

As more "Web 2.0" applications become popular, we continue to see richer and richer user experiences (UX) that astound us. To make UX snappy UI controls leverage technology like AJAX to offer support for better interactive experiences. We all know and love it. Who DOESN'T? I remember the first time I saw the scrolling on Google Maps. I couldn't believe my eyes.

But that comes at a price. People who listen to me speak know I am NOT a fan of melding data and code together. What you get at the data layer should NOT be what you see at the presentation layer. We see so many attack patterns that leverage this to their advantage. From the WMF vulnerability to origins of Office macro hell (and everythng in between), its just not a good idea to do this.

In the Web 2.0 world it gets worse. To get those speed increases developers leverage low overhead round tripping with AJAX interfaces. For those that don't know, AJAX stands for 'Asynchronous Javascript and XML'. The problem is, people are forgetting to keep constructs in XML and are spending more time leveraging the Javascript. And that gets me to this post.

The guys over at Fortify have released a research paper showing the weakness in this approach, and shows how easy it is to build on cross site request forgery to hijack Javascript. And as they point out in their research, this isn't a theoretical attack. We have already seen this in the wild. Remember the exploit for GMail recently? Google was serving the current GMail users’ contacts in unprotected JavaScript, so an attacker could steal the contact list using JavaScript Hijacking. Google has since fixed the problem for GMail, but to my understanding its actually a vulnerability that exists in their Google Web Toolkit API, and is not yet fixed. (Although I am told its being fixed as we speak).

And Microsoft's Atlas framework is not immune either. Although they HAVE made it more difficult to attack, it is still possible to generate a request from a malicious <script> tag with a HTTP GET request. Actually, I recall a few ASP.NET MVPs suggesting in public newsgroups to use GET for performance gains. There is a trade off in doing that; you expose yourself to these types of attacks.

The Fortify guys do a good job in explaining the problem, and better yet, defining how to SOLVE it. I hope Microsoft looks at this new class of attack and creates a mitigation strategy soonest for the Atlas platform.

Right now a work around that twarts this attack vector is to append the current session cookie to each request that returns Javascript. This will defeat the underlying cross site request forgery in the first place, and makes Javascript Hijacking moot since the server can validate the origin of the request. Since ATLAS provides the server-side support for this, it won't be difficult for Microsoft to do this. Predictably, MSRC will first have to threat model this class of attack before making any sort of recommendation for fixing the underlying problem.

Consider my post an early warning to the problem, and an echo of Fortify's research on how to mitigate the risks of this attack. If you are building web applications that use ATLAS, you need to consider this attack vector in your own threat models, and take action to mitigate the problem as you see fit.