Security Management Strategies for the CIOGoogle's Gmail recently caught the attention of the Web developer community about the possibilities of Ajax (Asynchronous JavaScript and XML
Requires Free Membership to View
).
Ajax is a set of technologies used together to extend browser functionality and allow users and
applications to access, share and edit content. While this Web development technique is nothing
new, it is viewed as part of Web 2.0, a second generation of Web
services, which like all Internet-based services, brings with it its own security concerns.
Let's look at how Ajax operates, how it can be exploited, and what you can do to prevent an
attack.
How Ajax works
Ajax applications are mainly executed on a user's machine. They exchange small amounts of data
behind the scenes with the server, so the entire Web page does not have to be reloaded. This adds
functionality to a page and makes it seem more responsive, like Gmail's real-time spell check, for
example. Ajax uses technologies like Cascading Style Sheets (CSS),
Document Object Model (DOM)
and Dynamic HTML (DHTML),
but its main driver is Java Script's XMLHttpRequest object, which can be set to operate behind the
scenes asynchronously and triggered by user keystrokes, a timer or other similar events. This means
the JavaScript code on a Web page can connect to Web servers independently of the user and pull in
cross-domain content.
 |
||||
|
|
|||
|
||||
How hackers exploit Ajax
Web applications typically use the same origin policy, which constrains them to only connect to the
server that delivered the base page. However, that does not apply to Ajax scripts, so malicious or
compromised scripts could steal data stored in cookies or directly access the originating server.
For example, an attacker could exploit cross-site
scripting vulnerabilities covertly because the application can perform multiple requests in the
background while the functionality remains normal to the user.
Preventing Ajax exploits
If you use Ajax within your Web application, its overall complexity will greatly increase, and each
server side function will be an additional target for attackers. Here are five steps you can take
to decrease these threats:
- The key coding discipline of never trusting the client still applies, so any security controls should be implemented on the server and never controlled by the user.
- Initially, keep the application straightforward. Reducing and simplifying any Ajax calls makes it easier to evaluate all possible types of requests that can be generated by a page or application during security testing.
- Document and explain how the application communicates with the server and handles the responses it receives. Cover such issues as SSL connections for sensitive information.
- Complete security testing prior to moving the application online, with special emphasis placed on checking for access control and input validation flaws.
- Visit the Web Application Security Project for help with developing secure Ajax applications.
Remember, because the security model of XMLHttpRequest is not viable in the long-term for Web 2.0 applications, it's important to stay abreast of emerging solutions that could resolve the cross-domain problem. For example, the JSON (JavaScript Object Notation) Request doesn't allow the exchange of cookies during the request, while Adobe's Flex ActionScript does allow server side control over which sites are allowed to cross-domain with it.
Finally, if you are looking at automated application security assessment tools, make sure you select one that supports Web applications which use Ajax, such as Cenzic's Hailstorm and S.P.I. Dynamics' WebInspect.
About the author:
Michael Cobb, CISSP-ISSAP is the founder and managing director of Cobweb Applications Ltd., a
consultancy that offers IT training and support in data security and analysis. He co-authored the
book IIS Security and has written numerous technical articles for leading IT publications.
Mike is the guest instructor for SearchSecurity's Web Security
School and, as a SearchSecurity.com site expert, answers user questions on application
and platform
security.
This was first published in September 2006
Join the conversationComment
Share
Comments
Results
Contribute to the conversation