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