Editor's note: Article first published 2006-06-19; updated 2006-06-22. Added several additional references that were mistakenly omitted by the authors, plus a new section on sources for further reading.

1. Introduction

Ajax technologies have been very visible on the web over the past year, due to their interactive nature. Google Suggest and Google Maps [ref 1] are some of the notable early adopters of Ajax. Companies are now thinking of how they too can leverage it, web developers are trying to learn it, security professionals are thinking of how to secure it, and penetration testers are thinking of how to hack it. Any technology that can improve the throughput of servers, produce more fluid page transitions, and make web application even richer for the end user is bound to find a place in the industry.

Ajax is considered the next step in a progression towards the trumpeted, "Web 2.0." The purpose of this article is to introduce some of the security implications with modern Ajax web technologies. Though Ajax applications can be more difficult to test, security professionals already have most of relevant approaches and tools needed. The authors will discuss if today's popular need to say goodbye to the full webpage refreshes using Ajax also means we are saying hello to some new security holes. We will begin with a brief discussion of the technology behind Ajax followed by a discussion on the security impact of applications using Ajax technology.

2. Ajax Primer

Regular web applications work on a synchronous model, where one web request is followed by a response that causes some action in the presentation layer. For example, clicking a link or the submit button makes a request to the web server with the relevant parameters. This traditional "click and wait" behavior limits the interactivity of the application. This problem has been mitigated by the use of Ajax (Asychronous Javascript and XML) technologies. For the purposes of this article, we will define Ajax as the method by which asynchronous calls are made to web servers without causing a full refresh of the webpage. This kind of interaction is made possible by three different components: a client-side scripting language, the XmlHttpRequest (XHR) object and XML.

Let's briefly discuss these components individually. A client-side scripting language is used to initiate calls to the server and then used to programmatically access and update the DOM within the client's browser, in response to the request. The most popular choice on the client is JavaScript because of its ubiquitous adoption by well-known browsers. The second component is the XHR object, which is really the heart of it all. Languages such as JavaScript use the XHR object to send requests to the web server behind the scenes, using HTTP as the transport medium. Then we have the third component, the use of which isn't necessarily set in stone: XML is the data format for messages being exchanged.

Many sites use JSON (JavaScript Object Notation) in place of XML because it's easier to parse and it has less overhead. When using JavaScript to parse JSON, it's as simple as passing it to the eval() function. On the other hand, one might use XPath to parse the returned XML. Also, there are many "Ajax sites" out there which don't use XML or JSON at all, and instead just send snippets of plain old HTML which are dynamically inserted into the page.

As it turns out, Ajax isn't a brand new technology but instead a combination of existing technologies used together to develop highly interactive web applications. In reality, all these components have been around for a number of years, marked by many with the release of Internet Explorer 5.0. Developers have found many uses for Ajax such as "suggestive" textboxes (such as Google Suggest) and auto-refreshing data lists. All XHR requests are still processed by typical server side frameworks, such as the standard options like J2EE, .NET and PHP. The asynchronous nature of Ajax applications is illustrated below in Figure 1.

Figure 1. An Ajax sequence is asynchronous.

3. Security implications with Ajax

Now that we have reviewed the basics of Ajax, let's discuss its security implications. Ajax does not inherently introduce new security vulnerabilities in the realm of web applications. Instead, the applications face the same security issues as classic web applications. Unfortunately, common Ajax best practices have not been developed, which leaves plenty of room to get things wrong. This includes proper authentication, authorization, access control and input validation. [ref 2] Some potential areas of concern involving the use of Ajax include the following:

• Client-side security controls

Some might argue that the dependence on client side programming opens up the possibility of bringing some already well-known problems back into the forefront. [ref 2] One such possibility relates to developers improperly implementing security through client-side controls. As we discussed in the previous section, the use of Ajax requires quite a bit of client-side scripting code. Web developers are now writing both the server-side and client-side code, so this might attract developers towards implementing security controls on the client-side. This approach is horribly insecure because attackers can modify any code running on their client computer when testing the application for vulnerabilities. Security controls should either be completely implemented on the server or always re-enforced on the server.

• Increased attack surface

A second challenge relates to the difficulty involved in securing the increased attack surface. Ajax inevitably increases the overall complexity of the system. In the process of adopting Ajax, developers could code a great number of server-side pages, each page performing some tiny function (such as looking up a zip code for auto completing a user's city and state fields) in the overall application. These small pages will each be an additional target for attackers, and thus an additional point which needs to be secured to ensure a new vulnerability has not been introduced. This is analogous to the well known security concept of multiple point of entry into a house: the difficulty involved in securing a house with one door as compared to securing one with ten doors.

• Bridging the gap between users and services

Ajax is a method by which developers bring end users closer to interfaces being exposed by Service Oriented Architectures. [ref 3]The push to create loosely coupled service-based architectures is a promising idea with many benefits in enterprise environments. As more of these service-based "endpoints" become developed, and as Ajax introduces the ability to push more sophisticated processing to the end user, the possibility of moving away from the standard three-tier model arises.

Typically, many web services within an enterprise (as opposed to on the Internet overall) were designed for B2B, and therefore designers and developers often did not expect interaction with actual users. This lack of foresight lead to some bad security assumptions during design. For example, the initial designers may have assumed that authentication, authorization and input validation would be performed by other middle tier systems. Once one allows "outsiders" to directly call these services through the use of Ajax, an unexpected agent is introduced into the picture. A real-life example of such usage is the consistent pitch from Microsoft to use Atlas [ref 4] hand-in-hand with web services. Developers can now write JavaScript to create XML input and call the web service right from within the client's browser. In the past this was achieved through service proxies at the server.