While the challenges associated with AJAX — the mix of Asynchronous JavaScript and XML — security has been talked about for some time, only now is it becoming a mainstream problem as more crucial applications are being converted to AJAX. 

There's good reason why companies desire to make the move: AJAX, as a web-development technique, is a powerful way to create rich and interactive web applications. By exchanging a small amount of data between the client system and the server, such as updating only the cells in a spreadsheet, the entire webpage no longer has to be refreshed with every small change on a site. The result is a significant increase in a website's interactivity, functionality, and usability.

The security concerns arise because application logic that once resided solely on the server side of a session now quite often is shared with the client. This can increase the attack surface of an application significantly, now that the application security depends partially on the security of the client's system as well as how well the AJAX application itself has been designed.

An example of how an AJAX client can be attacked includes the increased risk for cross-site scripting (XSS) attacks. For instance, when it came to XSS attacks in web mail applications, XSS traditionally was exploited by enticing the victim to click a link to a webpage that was vulnerable to an XSS attack. When applications like web mail are converted to AJAX, their risk of XSS attacks is increased. If the AJAX-enabled webmail application returns JavaScript (or arrays) from a GET request in response to an asynchronous call, a transient XSS vulnerability could be created. An attacker can send the victim an email with malicious script code that gets into the victim's browser via asynchronous data. In fact, the MySpace XSS Worm used a similar attack technique.

Another danger is cross-site request forgery (XSRF) attacks. In this case, a victim visits a malicious web site in a separate tab or window while his or her bank web page also is open. In this scenario, there will be a valid and active cookie for the bank website. Because the bank website uses AJAX, certain application interfaces to the client-side code are likely to be exposed. This creates an opportunity for an attacker to download the code from the bank's website. Now the attacker has knowledge of the bank's application interfaces. The attacker then can use the victim's valid cookie to access these interfaces and transfer money or other sensitive forms of sensitive information. This attack is much easier than trying to guess a SQL statement for an SQL injection attack.

Unfortunately, it's not just the client who is targeted with AJAX applications. In fact, servers may expose critical interfaces that can be used to manipulate the application. For instance, in an online bidding website that incorrectly exposes bidding APIs, an attacker could develop code using the API to place negative bids, such as a bid with a value of -$5. The same could be true for shopping cart pricing, sales tax, shipping charges — you name it. Additionally, an attacker could write an application that calls the server APIs in an incorrect or unexpected sequence, thus creating a DoS on the server.

The best way to avoid these and similar security problems associated with AJAX development is to train web developers adequately about secure development practices. And take special care whenever porting existing applications to AJAX. As is the case with all applications, these applications need to undergo penetration tests by someone on your team, or a consultant, who is knowledgeable about AJAX and web application security. To prevent XSRF attacks, specifically, you want to switch from a persistent authentication method (such as a cookie or HTTP authentication) to a transient authentication methods such as “double submit” cookies or secret user-specific tokens tucked within your forms, in addition to cookies.

Additionally, end-user education about web threats is essential for safe web browsing. End users should be taught, especially from work computers, not to browse web pages by clicking links in blogs or other web pages. They should take the time to type URLs manually in the address bar, and use the browser's bookmark feature to revisit those web sites in the future. Since it's not possible for users to know the exact technology used by their bank, insurance company, or brokerage websites, it‘s always a good idea to train them not to have other windows or tabs open while performing sensitive transactions.

Building and maintaining secure web applications isn't easy. And while it's no guarantee, the proper amount of security training and the adherence to best practices development standards — followed up by application assessments — is the best way to make sure your web apps stay as security as possible. As always has been the case with end-users, a little awareness can go a long way when it comes to online safety. 

- Amol Sarwate, director of Qualys' vulnerability research lab