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

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:

• Store sensitive data on the server, and enforce controls from the server
• Perform authentication checks on web pages and web services
• Validate all applications inputs - be they HTTP, headers and cookies, or Postdata
• Verify data types, lengths and formats
• Always use parameterized queries

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.®