"Ajax allows the development of more feature rich, asynchronous applications, but in doing so opens up new possibilities for attackers. We look at the relevant security issues and their possible solutions.

Ajax (Asynchronous JavaScript and XML) lurched into being in 2005 [1]. As a web services model, Ajax is touted as the next big thing by many who work in web development. Like all big things however, Ajax is not without its faults, one of the most pronounced being that not many people actually know what Ajax is, and what potential risks could be introduced into enterprise environments by embracing it. This article examines what Ajax is, the security implications for Ajax applications, and details a range of potential attack vectors against this technology together with possible defences.

At its simplest level Ajax is anything but new, as it is based around old technologies, but pushed beyond their original scope. Ajax is the latest inheritor of the Dynamic HTML mantle, and allows for the development of feature rich and practical web applications. At the purest level all an Ajax web application does is use an XMLHttpRequest JavaScript object to poll data from a remote web server and then manipulate this data to output to a web page utilising the DOM (Document Object Model) [2]. Up until now, Google, Yahoo and Microsoft have been big players in the Ajax development arena, but increasing numbers of high profile websites are turning to Ajax to provide an asynchronous, feature rich environment for their users, without sadly giving too much thought to potential inconveniences such as security.

It is best first to look at JavaScript and browser security issues. Upon initial execution of an Ajax application the originating web server transmits a series of JavaScript instructions to a web browser on a PC, which then executes the instructions it has received. Clearly, the user of an Ajax application places significant trust in the application developers. The JavaScript code of an Ajax application is executable mobile code, and as such an obvious security risk. Typically, browser vendors deal with the thorny topic of JavaScript code execution by having it occur within a sandbox. In addition, the JavaScript security model prevents scripts from different domains from interacting with each other (and affecting the DOM)."

Article Link: http://www.heise-security.co.uk/articles/81264