Ajax developers playing with fire

The rise of Asynchronous JavaScript and XML (Ajax) applications is exposing enterprises and end users to a new series of security threats, but developers are insufficiently aware of the risks.

"We are seeing a rise in web application attacks because people are realising that it is easier to go through the Web application," Billy Hoffman, a lead security researcher with Spi Dynamics, told vnunet.com. 

"There is all sorts of money to be made in Web security," Hoffman said at the AjaxWorld conference in Santa Clara, California. 

"It is often easier to attack an application through the web layer than by trying to break through the firewall or spoof around the intrusion detection system. Criminals take the path of least resistance."

From the end-user perspective, Ajax is a programming technique that allows websites to pre-fetch data and facilitate more interactive websites.

Google unveiled Ajax tools for its search engine on Tuesday that let Web publishers integrate search and search results directly onto their webpages.

Other popular services using Ajax include the Flickr photo sharing service and the Digg social book-marking site. 

Under the hood, Ajax uses Web services techniques such as XML to transmit information directly from a database to the website.

In a non-Ajax application, the same application would have required a web server to build the actual webpage presented to the user. But an Ajax application combines disparate data sources directly on the client system.

Whereas the database was kept within the safe confines of the corporate firewall, Ajax requires the services to be directly accessed by outside systems. "When you 'Ajaxify' an application, it increases the attack surface," said Hoffman.

Yahoo was hit by a security vulnerability in its online mail service last summer.

A maliciously crafted email message allowed attackers to access users' email accounts, download the contents of their address books and send out spam emails from the hacked accounts.

Such threats are known as cross-site scripting vulnerabilities (commonly referred to as XSS) because they span several services.

They are rapidly becoming a dominant online threat category, according to Hoffman. Salesforce.com, PayPal and Google have all been forced to repair XSS security holes in their online software.

The issue of Ajax security is mainly a matter of developer culture, according to Hoffman. As the programming technique is relatively immature, it has not yet established best practices.

Web developers have not paid much attention to the security of their code because they typically have a background in graphics design.

Software developers who start creating code for the Web, meanwhile, are not used to worrying about suddenly exposing new Web services to the Internet.

Sample code published by trade publications and books about Ajax programming also fails to instil safe programming skills.

Hoffman claimed that the AjaxWorld magazine handed out to delegates at the conference featured a code sample that could allow an attacker to hack into the service. 

"In a space like Ajax you have a lot of developers who do not really know much about it. They are reading books and tutorials, but these tutorials are giving them really bad security advice," he warned.

"You have a developer culture that is saying: 'Let me learn how to do Ajax,' and they are not being told how to do it securely."

Writing secure Ajax code is further complicated by the fact that the language was never created with Ajax applications in mind and is very hard to debug.

Validating the data will mitigate most attacks, Hoffman said. Cross site scripting attacks, for instance, can work by entering SQL commands in an email registration box.

By ensuring that an email features an '@', and banning punctuations other than the dot, offers a straightforward way to prevent such attacks.

Hoffman also flamed the "perpetual open betas" used by many online applications. In an attempt to rapidly develop their products, firms bypass closed tests and instead invite users to put live data in their unfinished products.

While it might be a good strategy to quickly launch a product, it spells doom for the application's security, Hoffman argued.

"It's like hanging out a big sign saying: 'Hey, hackers. Here's some code that hasn't been pounded on too hard. Let's come and attack me.'

"This whole concept of go fast is being pushed by market pressures and it is really the last thing that you want to do."

Copyright ©v3.co.uk

ajaxdevelopersfireplayingsoftwarewith