Rush to Ajax makes for happy hackers

The rush to adopt Ajax is leading web developers to make basic security mistakes, in some cases a decade old, that leave gaping holes in their applications. That is according to researchers here at the Black Hat security conference in Las Vegas. Some said that in some cases developers should avoid Ajax altogether rather than open their businesses to attack.

In a presentation entitled ‘Premature Ajaxulation’, SPI Dynamics researchers Billy Hoffman and Bryan Sullivan cataloged a myriad of attacks that are made possible when developers follow advice or use scripts found in otherwise reputable blogs, web sites and manuals.

While there are many ways to mitigate these security risks, the researchers said that as a last resort developers should ‘consider abstinence’ from Ajax.

“Just because all your friends are doing it, it does not mean you are ready for it,” Hoffman said.

The SPI researchers said they have seen Ajax sites that contain rudimentary ‘client-side pricing’ vulnerabilities that were common on the web 10 years ago.

This kind of vulnerability allows a malicious user to name their own price when buying something online, by forging the price field that the browser sends to the web server. In the old days, this meant editing the value of a hidden field in an HTML form.

Now SPI’s researchers have found sites that send this price data using Ajax calls, which can be forged just as easily as HTML forms by those who know what they are doing.

The main problem with Ajax is the J, for JavaScript, the language which handles the client-side logic of the application. While it can be obfuscated somewhat to make it harder for a person to read, it is plain text that can also be read and reverse-engineered by the bad guys.

The researchers showed a series of attacks on a mocked-up airline website, which, far from being a straw man, they said was built purely using guidance and code found in Ajax manuals and websites.

One attack showed the Ajax call for paying for a flight could be turned off, while leaving the call for booking the flight turned on, potentially giving the attacker a free flight. Another attack showed that when one function temporarily reserves a flight and a subsequent function releases that flight, a hacker could turn off the latter function to create a denial-of-service attack in which all flights show up as reserved and none can be purchased by any user.

“Whenever you have a resource allocated in one function and released in another there is the possibility of this kind of DoS attack,” Sullivan said.

Many web application developers do not ‘get’ the fact that what they are basically doing with Ajax sites is exposing a bunch of server APIs for people to play with, the researchers concluded.

An Ajax web page will deliver a JavaScript script that the browser can use to call these APIs correctly and in the right order, but the user is under no obligation to do so.

An additional problem is the tendency for developers to dump all their JavaScript functions in one .js file that is header-linked on all a site’s pages, SPI’s researchers said.

While this is good advice when it comes to code management and convenient client-side caching, it also could expose functions that some users should not see, they said. This would be particularly dangerous if administrator APIs were exposed.

Separately, Danny Allan, director of security research at SPI competitor Watchfire, now part of IBM, told us that about 85% of Ajax apps have vulnerabilities, and that there are several areas of concern when it comes to Ajax security.

One of these is authentication and authorisation. In some cases Ajax apps, because of the increased back-and-forth between browser and web server, do not pass along the user’s cookie, meaning the application’s APIs could be called without the user being identified.

Allan said his number one concern at the moment is an attack called ‘prototype hijacking’, which came to light at a European hackers conference in January this year. The attack sees the bad guy overwriting an application’s XMLHttpRequest method - the piece of code used to create data objects that can be sent and received by the app - so that data is covertly sent to the attacker.

SPI’s Hoffman identified the trend towards Ajax apps that can also work in an offline mode as another great cause for concern, as even more JavaScript is delivered to the client. “Offline apps scare the crap out of me,” he said. “You are going to put that much business logic on the client so you can use it offline?”

Client-side technology such as Google Gears, which comes with an SQL Lite database, opens up the possibility of simplified SQL injection attacks that can be crafted in offline mode, he said.

And with software such as Microsoft’s Silverlight, it can be very difficult to tell, before compiling, which code will end up on the client and which will end up on the server, he said.