Professional Documents
Culture Documents
Ajax Security Basics
Ajax Security Basics
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.
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 "singlethreaded" 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:
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.