Ajax security -- A reality check

Ajax (Asynchronous JavaScript and XML) is the new kid on the block and already has everyone talking. Companies, designers, developers, researchers, testers, security professionals -- everyone wants a piece of it. Applications such as Google Suggest or Google Maps are just two examples to fire up your imagination about what Ajax can do for your Web site.

The ability of Ajax to interact with the server behind the scenes, without reloading the browser page, has given a whole new dimension to Web development. It helps developers create a rich interactive Web application without the inconvenience of reloading the Web page, resulting in a much-improved user experience. For example, now a developer doesn't have to wait until the form is submitted to do a bunch of validations. He can do all those validations on the fly as the values are entered in the form fields. That is just one very small example of how to use Ajax. Your imagination is the limit to what you can do with it.

Ajax is not a new technology but a collection of existing technologies working together. Using JavaScript's XMLHttpRequest method, a client browser can connect to the server and download a small piece of HTML, text or JavaScript code to update a small portion of an existing HTML page rather than reloading the entire HTML (like in traditional Web pages). It is this ability that has made Ajax so popular. You can find more details about how Ajax works in an article by Jesse James Garrett, "Ajax: A new approach to Web applications."

Like every technology, Ajax comes with its share of security issues. It's not that Ajax is introducing new security flaws or vulnerabilities. It's the way developers approach this technology combined to a certain extent with the way Ajax works that can cause security flaws to creep in. With Ajax, the logic is scattered across both the client and the server. Unlike in earlier applications, where the entire logic was stored on the server, now there is a higher probability that the developers might ignore some validation rules or overlook access restrictions. That can open a vulnerability in the application. And the fact that the logic is stored both on the client and the server doesn't help testers or code auditors either.

Since Ajax is a relatively new method, there's a lack of good examples on the Internet to help developers who want to learn about it. As a result, developers start learning on their own and write the code for live applications along the way. Since they are learning the technology, their focus is more on making it work rather then making it secure. Chances are those modules are not as mature and may result in deploying vulnerable code in production.

Prior to Ajax, we knew that whatever code was sent to the browser was static so whatever HTML or JavaScript that was sent to the client, remained that way. Now, Ajax can let you dynamically modify that content on the client side. It opens a whole new world to both the developers and attackers alike. As we saw with Samy's MySpace worm, Samy exploited the cross-site scripting (XSS) vulnerability on MySpace and became a hero of more then a million users. Now imagine if he created something more malicious such as logging keystrokes on the login page. He would have gotten the passwords of millions of users. Ajax has taken XSS to a whole new level. Another issue associated with this is since the JavaScript can be modified dynamically, an attacker can insert a malicious script at runtime, execute it and remove it after execution, making it very difficult to spot that malicious script.

Ajax applications are also difficult to debug because the logic is distributed on both the client and the server. This could lead to some bugs making their way to the production that can be exploited by malicious people. Identification of those bugs could be hindered even more because of the lack of mature testing tools for Ajax.

In traditional Web applications, the business logic was stored on the server side and some of the validation logic using JavaScript was stored on the client side. With Ajax, the logic is now distributed across the client side and the server side. That may be fine for some Web applications, but the majority of them would not like their business logic exposed. It can be used by competitors or malicious people to understand the functionality of the Web application. The client side logic can be obfuscated, but that is not a foolproof solution.

Ajax security advice How to safely deploy Ajax New chapter and verse on Ajax security Ajax in Action -- Chapter 7, Security and Ajax

Logging is another area that may get overlooked while using Ajax. In a traditional Web application, companies could determine if they wanted to log all or some user activities. They could do that because the entire business logic was residing on the server. In Ajax world, where the logic may also reside on the client, the existing logging tool may not be sufficient.

We will see a lot more of Ajax in the future, and as the industry matures we will see security best practices gaining momentum. The Open Web Application Security Project has already started working on Ajax security standards, and very soon vulnerability assessment tools such as Watchfire's AppScan and SPI Dynamics' Webinspect will address Ajax. But companies shouldn't wait for others and should start by doing due diligence on their own. After all, every step -- however small -- is a step forward in securing your application.

-------------------------------
About the author: Anurag Agarwal, CISSP, works for a leading software solutions provider where he addresses different aspects of application security. You may e-mail him at anurag.agarwal@yahoo.com.