There's good reason why companies desire to make the move: AJAX, as a web-developmenttechnique, is a powerful way to create rich and interactive web applications. Byexchanging 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 longerhas to be refreshed with every small change on a site. The result is asignificant increase in a website's interactivity, functionality, and usability.
The security concerns arise because application logic that onceresided solely on the server side of a session now quite often is shared withthe client. This can increase the attack surface of an applicationsignificantly, now that the application security depends partially on the securityof the client's system as well as how well the AJAX application itself has been designed.
An example of how an AJAXclient can be attacked includes the increased risk for cross-site scripting(XSS) attacks. For instance, when it came to XSS attacks in web mailapplications, XSS traditionally was exploited by enticing the victim to click alink to a webpage that was vulnerable to an XSS attack. When applications like webmail are converted to AJAX,their risk of XSS attacks is increased. If the AJAX-enabled webmail applicationreturns JavaScript (or arrays) from a GET request in response to an asynchronouscall, a transient XSS vulnerability could be created. An attacker can send thevictim an email with malicious script code that gets into the victim's browservia asynchronous data. In fact, the MySpace XSS Worm used a similar attacktechnique.
Another danger is cross-site request forgery (XSRF) attacks. In this case, avictim visits a malicious web site in a separate tab or window while his or herbank web page also is open. In this scenario, there will be a valid and activecookie for the bank website. Because the bank website uses AJAX, certain application interfaces to theclient-side code are likely to be exposed. This creates an opportunity for anattacker to download the code from the bank's website. Now the attacker hasknowledge of the bank's application interfaces. The attacker then can use thevictim's valid cookie to access these interfaces and transfer money or other sensitiveforms of sensitive information. This attack is much easier than trying to guessa SQL statement for an SQL injection attack.
Unfortunately, it's not just the client who is targeted withAJAXapplications. In fact, servers may expose critical interfaces that can be usedto manipulate the application. For instance, in an online bidding website thatincorrectly exposes bidding APIs, an attacker could develop code using the APIto place negative bids, such as a bid with a value of -$5. The same could betrue for shopping cart pricing, sales tax, shipping charges — you name it.Additionally, an attacker could write an application that calls the server APIsin an incorrect or unexpected sequence, thus creating a DoS on the server.
The best way to avoid these and similar security problemsassociated with AJAXdevelopment is to train web developers adequately about secure developmentpractices. And take special care whenever porting existing applications to AJAX. As is the case withall applications, these applications need to undergo penetration tests bysomeone on your team, or a consultant, who is knowledgeable about AJAX and web applicationsecurity. To prevent XSRF attacks, specifically, you want to switch from a persistentauthentication method (such as a cookie or HTTP authentication) to a transientauthentication methods such as “double submit” cookies or secret user-specifictokens tucked within your forms, in addition to cookies.
Additionally, end-user education about web threats isessential for safe web browsing. End users should be taught, especially fromwork computers, not to browse web pages by clicking links in blogs or other webpages. They should take the time to type URLs manually in the address bar, anduse the browser's bookmark feature to revisit those web sites in the future. Sinceit's not possible for users to know the exact technology used by their bank, insurancecompany, or brokerage websites, it‘s always a good idea to train them not to haveother 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 theadherence to best practices development standards — followed up by applicationassessments — is the best way to make sure your web apps stay as security aspossible. As always has been the case with end-users, a little awareness can goa long way when it comes to online safety.
- Amol Sarwate, director of Qualys' vulnerability research lab
