• New possibilities for Cross-Site Scripting (XSS)

Another unfortunate truth is that attackers can be more creative (in other words, dangerous) with the use of Cross Site Scripting (XSS) vulnerabilities. [ref 5] Typically, attackers had to use XSS holes in a "single-threaded" world, where the attack was being carried out while the user's browser was in a wait state. This wait state provided some visual/behavioral cues to the user of a possibly misbehaving application. With the introduction of Ajax, an attacker can exploit Cross Site Scripting vulnerabilities in a more surreptitious manner. While you check your mail with an Ajax-enabled application, the malicious code could be sending email to all your friends without your browser giving you any visual cues at all.

Adequate, specialized security testing must be performed prior to moving the application into production to address these areas of concern. Even though Ajax applications are web applications, an organization's existing security testing methodologies may be insufficient due to the highly interactive nature of these applications.

4. How Ajax Complicates Current Security Testing Methodology

While testing a regular web application, a penetration tester starts by footprinting the application. The intent of the footprint phase is to capture the requests and responses so that the tester understands how the application communicates with the server and the responses it receives. The information is logged through local proxies such as Burp [ref 6] or Paros [ref 7]. It is important to be as complete as possible during the footprint phase so that the tester logs requests to all pages used by the application.

After that step, the tester will start the process of methodical fault injection, either manually or using automated tools, to test parameters that are passed to and from the web server.

Ajax complicates this methodology because of its asynchronous nature. Ajax applications are typically noisier when compared to regular web applications. An application may make multiple requests in the background even when it appears to be static to a user. A tester has to be aware of several situations which might cause difficulties with the application testing process. These include:

• The issue of "state"

In the regular web application world, the state of the application has been fairly well defined. Everything residing in the DOM for a page could be considered as the current state of the page. If the state needs to change, a request was sent to the server and the response defined how the state changed.

In the Ajax world, things can change much more subtly. The application can potentially generate different types of requests depending on the current state of the page. The request generated by clicking on a list box may be different from the request generated by clicking on the same list box if the user has first select a radio button on the page. Additionally, the response can update part of a page so that the user may now have new links or new controls to interact with on that page. During security testing, this behavior is of concern because it is much more difficult to determine if the tester has seen all possible types of requests that can be generated by a page or application. [ref 8]

• Requests initiated through timer events

This refers to updates to the user interface without any user interaction, through timer-based events. Applications may periodically send requests to the server to update information on the web page. For example, a financial application may use the XHR object to update parts of the web page that display current stock market information. The tester may not be aware of this process happening in the background if they do not catch the request at the right time, since there may not be visible links or buttons to suggest to the tester that there are requests being made in the background.

• Dynamic DOM updates

Ajax responses can contain JavaScript snippets that can be evaluated by the web application and presented at the user interface. This might include new links, access to new documents on the server, and so on. One way to achieve this is by using the eval() statement. [ref 2, ref 8] The eval() statement takes a single parameter, a string, and executes it as if it were a part of the program.

An good example is Google Suggest where the application receives a JavaScript snippet which gets evaluated and shows up as possible suggestions to complete the query entered. This behavior can be problematic for the manual tester as well someone using automated tools. Either one will have to understand the context around how the JavaScript is being used in the web application. Close attention needs to be paid when an input parameter is sent back which becomes evaluated on the client side. This might sound like typical XSS and it is, but it has just become so much easier to exploit. Applications which perform blacklist validation are even more susceptible because attackers don't need to inject as many tags. Several methods have been available to use XSS without the script tag in the past as well.

• XML Fuzzing

Ajax can be used to send requests and receive responses in XML format. Simplistic automated tools do understand GET and POST methods but may not understand how to deal with information encapsulated using the XML format.

The tester has to ensure that developers have not deviated from a secure architecture. In a secure system, the security controls are implemented in an environment which is outside the control of the end user. While performing reviews, one must look through the client side code to determine if it is somehow modifying the state of variables (cookies, FORM parameters, GET parameters) before submitting them to the server. Any time this happens, the JavaScript code needs to analyzed to determine the reasoning for this.

Just like typical web applications, all Ajax requests should be tested for authorization issues. Developers might fall victim to believing that just because a page is called behind the scenes through the use of a client-side scripting engine, that authorization isn't necessary. This is not the case.

5. Conclusion

Ajax applications provide new possibilities through its highly interactive nature. Developers should be weary of new insecurities introduced by these capabilities. Security testers must augment their methodology and toolset to handle Ajax applications.

In this article, the authors have provided an introduction to some of the security implications found in Ajax technologies. Penetration testers are seeing that they have the knowledge and tools to evaluate Ajax applications, but that they are somewhat more difficult to test. Future articles will look at more areas of concern as well as helpful tools that can be used with Ajax security testing.

6. References

[ref 1] Google Suggest and Google Maps, two early Ajax applications.

[ref 2] Stewart Twynham, "AJAX Security", Feb. 16th, 2006.

[ref 3] Andrew van der Stock, "AJAX Security", OWASP Presentation given on February 7, 2006. A direct descendent of this presentation is also available from Andrew van der Stock at http://www.greebo.net/owasp/ajax_security.pdf.

[ref 4] Microsoft's Altas framework tries to integrate as a middle-tier.

[ref 5] Post by "Samy," on a "Technical explanation of the MySpace worm".

[ref 6] Burp web application proxy for penetration testing.

[ref 7] Paros web application proxy for penetration testing.

[ref 8] post by Rogan Dawes, author of WebScarab, on the WebAppSec mailing list.

7. Further reading

• Jesse James Garrett, "Ajax: A New Approach to Web Applications", Feb. 18, 2005.
• Ryan Asleson and Nathaniel T. Schutta, "Foundations of Ajax", APress Publications, Oct 2005.
• Nicholas C. Zakas, Jeremy McPeakandJoe Fawcett, "Wrox Professional Ajax", Feb 2006.
• Eric Pascarello, "Eric Pascarello dissects Ajax security vulnerabilities", Feb. 07, 2006.
• Andrew van der Stock, "Ajax and Other 'Rich' Interface Technologies".

8. About the authors