Hackers Clean Up With Ajax

The Ajax development tool may be easy to deploy and fun for users, but all of that cool interactivity can also put users in harm's way -- and a pair of researchers has written exploits to prove it.

Bryan Sullivan, senior research engineer for SPI Dynamics, and Billy Hoffman, lead researcher for SPI Dynamics's labs, next month at Black Hat USA will demonstrate their own specially crafted SQL injection and XPath injection attacks as well as "race-condition" exploits on Ajax.

They'll unleash their exploits on a mock Website called "Hacker's Vacation Website" that they built for the Black Hat session entitled "Premature Ajax-ulations" (really).

The crux of Ajax's problem is its heavy interaction with the client machine. Anywhere from one third to one half of most Ajax apps run out on the client, which leaves these apps wide open to attackers, the researchers say. "Any code running on the client is visible to a potential attacker. They can see what you're doing and how you're doing it," Sullivan says.

Ajax server code, too, must be more visible than the traditional Web app so that the client code can access it directly, Sullivan says.

In a traditional Web environment, such as a site that lets you purchase music, the transaction application -- login, authentication, debiting the account, etc. -- would basically run on the server. But with Ajax, that process engages the client with feedback, such as "now we're debiting your account," or "now you're downloading the software," Sullivan explains.

"There's a lot of Ajax logic on the client and it can be manipulated and exploited," Sullivan says.

The relative transparency of the Ajax-based application also makes it much simpler for an attacker to peek into the app and glean its inner workings -- and vulnerabilities -- for nefarious purposes. If a typical Web app is like a microwave -- where no one really knows or sees how it works -- Ajax is more like a toaster. "It's easy to understand, and you can look in and see the hot coils and the bread turning brown," Sullivan says. "It's easy to understand how to break it, too."

The most overlooked and serious security issue in Ajax is data transformation, where data is converted into HTML, Sullivan observes. With Ajax, that transformation often occurs at the client, rather than at the server for performance reasons. But such transformation increases the risk of SQL injection or XPath injection attacks, he says.

"If the server just sends back raw query results to the client, as is often done in Ajax apps, then an attacker can easily append his own commands and get back valid results. The entire database can be retrieved in one or two requests instead of [in] thousands."

And retrofitting an older Web app to Ajax is even less secure than developing it from scratch, the researchers say. "When someone 'Ajaxifies' a traditional Web app for whatever reason -- a good business reason or because it's trendy -- they have now taken an application that was secure and broken it, so it’s not secure anymore," Sullivan says. He says he recently has seen an "Ajaxified" app that updates passwords. "So anyone could access this directory and change anything they want."

So what should enterprises do to secure their Ajax-based apps?

"We're not going to say don't use Ajax. We think it's great," Sullivan says. "But watch your granularity of functions" in your apps. That may mean making a sensitive part of a transaction, for instance, one larger function rather than embedding a lot of back-and-forth correspondence between the client and server, he says. "So before a user could download a song, he or she would need to log in again."

— Kelly Jackson Higgins, Senior Editor, Dark Reading