Original URL: http://www.theregister.co.uk/2008/04/14/ajax_charlatans_old_school_attack/

Security experts warn against Web 2.0 charlatans and 'premature AJAXulation'

Old-school threats to rushed migration

By Gavin Clarke

Posted in Security, 14th April 2008 20:55 GMT

RSA Forget a wave of Web 2.0 threats taking down your software, stealing your data or exposing users - the real danger is posed by some existing attack techniques. And it's IT charlatans peddling over-night AJAX solutions that'll leave you vulnerable.

Two security experts from Microsoft and Hewlett Packard have warned against "premature AJAXulation" - the practice of using quick fixes to turn existing software in into Rich Internet Application wonders - saying these are architecturally flawed.

Microsoft security program manager Bryan Sullivan, during a joint session called Ajax Applications: A Blueprint for Disaster, told RSA: "People talk about sexy new Web 2.0 attacks. What's going to break the internet are these old Web 1.0 attacks like SQL injection, which works well against Web 2.0 applications. They are more efficient and more effective."

Billy Hoffman, manager for HP software' security labs, added: "Companies will say: 'We can Web 2.0ify your existing applications in 15 minutes - we've got a wrapper'. These people are charlatans, and you should punch them in the face. They are taking your back-end database tiers and moving them to the parameter."

Illustrating their point, Hoffman and Sullivan - authors of AJAX Security, presented a chunk of real-life code, five-lines in length, and invited their audience to count the vulnerabilities. The total? Seven, including SQL injection, denial of service, a logic bomb, privacy escalation, request forgery, and cross-site scripting.

The real problem, particularly in turning existing applications into Web 2.0 and RIAs, comes when server-based applications are sliced up and put on the client with the expectation users will dutifully not call APIs out of order. This is not just naive. It breeds a vast amount of complexity that makes it harder for testers to catch potential gaps.

Hoffman and Sullivan demonstrated a sample airline auction service they'd built using commonly occurring advice and tools - combining JSON, and running in Firefox and Internet Explorer - that they scanned and hacked using Firebug and regular application development tools.

Lack of honesty

Honest users of the service would bid on a number of publicly available fares, have their bid accepted, and the money would be deducted from their account. If their bid were rejected, then the process would start again.

The duo, though, proceeded to hack the program by finding and calling the APIs out sequence.

They were able to find more flights than had been available for public view on the main site, and they then called the API directly to book the flight so the system accepted their offer without going through the bid process - setting their own price, and having it accepted.

They also launched a DoS attack to keep calling the service and to block book a flight without ever completing the transaction and without paying. When a transaction isn't completed, the system assumed the user is on a slow connection, and it keeps the process open. This way it was possible to fill up the entire fleet using a few JavaScript calls.

Old-school problems like DoS are a threat to all companies, even the big boys like Google with its Gmail and Microsoft with Live Messenger. Rather than bring down a site, hackers can make it unavailable by choking the internet connections. "Put this in the context of traditional DoS attacks," Sullivan said. "How do you do DoS against Gmail and Live Messenger? You can't overwhelm them with traffic, we are taking their application logic and using it against them. We are finding assumptions and problems in error handling and causing deadlocks."

Back on their sample airline auction site, the duo noted that each page contained JavaScript code that called the functions of other pages, and this enabled the hackers to quickly find previously hidden pages, such as the administrators' site. From there, it wasn't worth hacking the user ID and password, because administrator functions were exposed as JavaScript.

Other areas for entry points include form files, cookies, headers and newer things like web services, with the WSDL left turned on and helpfully explaining the parameters.

The pair stressed their site was architected and built using advice available on AJAX web sites and though books, indicating these problems exist as fundamental assumptions to many programmers. "We are following the advice we were given," Sullivan said.

Client mistrust

According to the duo, the first step to recovery from premature AJAXulation is to learn not trust your client. In the Web-2.0-attack world, the client becomes a gateway to the server and can actually take the hard work out of attacking systems for hackers. In their example, Hoffman and Sullivan showed how a SQL injection attack could be achieved in three queries instead of the usual hundreds.

In the server scenario, the hacker would have to bind to the selected table, but in the AJAX environment, the client can run the JSON request to the database tier with web-server data packaged as database data.

This poses a huge problem for the QA teams tasked with spotting holes and preventing potential hacks, according to Hoffman, because JavaScript attacks are not displayed during testing.

And you can forget code obfuscation, which is used to make code difficult to read and understand, as a means to thwarting complicated attacks. Obfuscated code can be scanned using a simple JavaScript parser and the desired code quickly identified. "The point to take away, is not obfuscation is pointless: it's good at keeping the script kiddies away but it's not a defense," Sullivan said.

Once you do accept that client-side code cannot be protected, encrypted, or obfuscated and then you can take further protective steps, according to Sullivan and Hoffman. These include:

Recalling the work of author James Martin, the pair said re-architecing your applications away from reliance on the client would solve things like SQL injections and process overflows. Martin was writing in the era of punch cards, but the pair said his advice its still valuable today. “Everything can be solved with proper input validations,” Sullivan said.®