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.
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.
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.
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 firstname.lastname@example.org.
Reader Feedback: Share your comments on this article
Dig Deeper on Software Security Test Best Practices