AJAX and security

Asynchronous Javascript and XML (AJAX) is one of the latest techniques used by web application developers to provide a user experience similar to that of a local application. Unfortunately, AJAX also provides a number of serious security issues that should be considered and, at least partly because the technique is relatively new, many of the tutorials and other documentation completely disregard the security implications. Developing secure code rarely gets the attention it deserves and new technologies are typically slow to develop 'best practices' and to disseminate that information throughout their community. This can only lead to exploits in the future.

Traditional web applications are synchronous in nature, a user clicks a button or link which sends a request to the server; the server replies with a page of HTML and the browser displays the new page. AJAX applications do some amount of work in the background, making requests of the server, sometimes without explicit user input. These applications do not refresh the entire page as they receive replies from the server; they only modify parts of the page or their internal state which gives users a much smoother, less page oriented experience.

One of the best known examples of an AJAX application is Google Maps. While the user is viewing a particular section of the map, the client requests other sections of the map that are not yet visible and this allows the user to seamlessly scroll the map to view off-screen sections. Auto-completion for text fields, automatically updating form elements and form submission without a page refresh are other common uses for AJAX in these 'Web 2.0' applications.

In order to handle the asynchronous server requests, AJAX programs use the Javascript XmlHttpRequest (XHR) object. The name of this object is really where the X in AJAX comes from as XML is not necessarily used in the XHR request or response. A client sends a request to a specific URL on the same server as the original page and can receive any kind of reply from the server. These replies are often snippets of HTML, but can also be XML, Javascript Object Notation (JSON), image data or anything else that Javascript can process.

Various queries and requests that were once handled internally on the server are now exposed as a de facto API for AJAX applications. This drastically increases the attack surface of these programs because there are so many additional ways to potentially inject malicious content. Filtering user input correctly is, as always, the single most important safeguard for a web application; this is an area that traditional web applications have regularly failed to handle correctly. It is difficult to see how adding additional ways to get user input into the application is going to help this problem.

SQL injection and Cross-site scripting (XSS) are two attacks that can be made against an application that does not filter user input correctly. AJAX techniques allow for additional ways to exploit these vectors in the background, undetectable by the user. The Myspace samy worm (more technical description here) is an example of the kinds of things that can be done. At the recent Black Hat Briefings, there was a session describing a port sniffer written in Javascript that could potentially discover internal network details behind a firewall and report them to a malicious site.

The requirement that XHR objects refer only to URLs on the same server is an excellent security choice. Unfortunately, it is probably the single biggest complaint that web designers have about AJAX. Because they often want to display information from various sources on the same page, the restriction is considered to be 'too strict' and to get around it, AJAX bridges came about.

An AJAX bridge proxies requests to other servers, returning the remote server's response. This allows XHR objects to refer to URLs on the server that returned the page, but still retrieve content from other servers elsewhere in the web. Unfortunately, this can lead to various abuses. Depending on how it is written, the bridge can provide a means to attack the third party site via SQL injection or XSS and allow the malicious user to hide behind a level of indirection. Various monitoring tools could detect the attack and shut down access for the aggregating site, effectively causing a denial of service attack. By proxying requests, a site is implicitly trusting its users not to abuse the APIs of third parties.

Many of these attacks are not new, nor do they require AJAX to function, but by incorporating AJAX techniques into web applications, they are made easier. At one time, it was considered reasonable to turn off Javascript for many or all sites, but with the prevalence of Web 2.0 applications, this just is not possible for most web users. Web application developers need to be vigilant in rooting out the bugs that allow these attacks to succeed.