Fortify Software, which said it discovered the new class of vulnerability and has named it JavaScript hijacking, said that almost all the major Ajax toolkits have been found vulnerable.
JavaScript Hijacking allows an unauthorized attacker to read sensitive data from a vulnerable application using a technique similar to the one commonly used to create mashups, Chess writes in a white paper published today.
Everybody thought that the rise of Ajax as a web programming model would merely exacerbate existing types of attack. Few thought it would give rise to a new class, noted Brian Chess, Fortify’s chief software architect.
Ajax is a way of designing web applications where data is transferred to and from the web site in the background of the page, without the need for a full page refresh when the user interacts with it. It give web apps the feel of desktop apps, and is used in applications such as Gmail.
By exploiting JavaScript hijacking vulnerabilities, attackers would be able to, for example, retrieve email from a victim’s Gmail inbox, or gain access to any data that could be sent them via and Ajax app.
While Ajax stands for Asynchronous JavaScript and XML, it’s entirely possible to use the method without using XML as the transport. You could use HTML, plaintext or, indeed, JavaScript.
And this is where the problem lies, according to Chess.
When applications use the JavaScript data format known as JSON, instead of XML, to transfer data between the browser and the server, it is handled differently by the browser.
Browsers have rules that restrict where HTML data can be sent by domain, called the same origin policy, but these rules are not observed when it comes to JavaScript.
It’s perfectly possible for any one web site to run JavaScript hosted on another domain. Applications such as Google Adsense or Google Maps, for examples, rely upon it.
And Fortify now claims that attackers can exploit this loophole to log into Ajax applications pretending to be their victims, and then receive any data that this application would ordinarily serve up using JSON.
In an example attack, a victim who has already authenticated themselves to an Ajax application, and has the login cookie in their browser, is persuaded to visit the attacker’s web site. This web site contains JavaScript code that makes calls to the Ajax app. Data received from the app is sent to the attacker.
If the Ajax app was a webmail service, the attacker could get the contents of an inbox or address book, for example. Indeed, Fortify’s research was based on an earlier finding by Jeremiah Grossman, who found such a vulnerability in Gmail last year.
According to Fortify, 11 of the 12 Ajax frameworks it tested did not have safeguards in place against such attacks. The company did not, however, test the attack against any live applications.
Vulnerable frameworks include: Microsoft ASP.NET AJAX (aka. Atlas), XAJAX and Google Web Toolkit, Prototype, Script.aculo.us, Dojo, Moo.fx, jQuery, Yahoo! UI, Rico, and MochiKit.
These vendors have all been notified, and will include fixes in their libraries in forthcoming releases, according to Chess. The whitepaper is being released to help coders that have manually created their Ajax objects to build in similar safeguards too, he said.
Since Ajax is in its infancy, this is fair less of a problem than, say, buffer overflows were when they first came to light, Chess noted. There are not a lot of legacy Ajax applications that will need to be fixed. So, Fortify wants to publicize its finding as loudly as possible now to nip the problem in the bud.
