ith the popular adoption of AJAX techniques mushrooming on the web today, real-life security issues were sure to follow, as illustrated by the Yamanner and MySpace worms. The debate over AJAX security now rages, with widely differing opinions. Just google “AJAX security” and you will receive more information than you can sort through?let alone absorb?in a week. Never mind making intelligent strategic decisions based on it and producing secure AJAX-based applications as a result. However, to help you jump-start your research, CGISecurity has conveniently organized some AJAX security content here, and the Open Web Application Security Project (OWASP) has begun to assemble some formal documentation here.

The Common Themes of AJAX Security
As you wade through the plethora of available AJAX security information, you will discover three common themes:

1. AJAX, or more specifically, the use of the XMLHttpRequest object (XHR), does not corrupt the web security model on its own, provided that a strong security architecture is defined and enforced during application development.
2. Defining and enforcing a strong security architecture is a non-trivial exercise, and virtually none of the multitude of JavaScript-laden AJAX libraries that exist today will help you do it. This is an exercise left to the developer?don’t blow it, or blow it off for that matter.
3. Most obviously: the client is untrusted, SO DON’T TRUST IT!!

Let’s assess what each of these themes means to an enterprise that is motivated to leverage the benefits of AJAX, but needs to maintain high levels of security.

AJAX on Its Own Doesn’t Corrupt Web Security
This is the good news. It means nothing about the use of XHR in JavaScript is fundamentally insecure. In fact, XHR is restricted to on-domain HTTP requests, which makes it safe to use provided proper access control is established. And if the contents of an XHR response contain sensitive data, the whole connection can be secured with SSL, so you essentially have a secure foundation on which to build.

From a security perspective, calls in the industry to extend XHR to allow cross-domain requests are ludicrous, as this would compromise the security foundation. The concept of an autonomous JavaScript client freely accessing multiple domains in some sort of SOA/mashup architecture cannot be achieved in a secure fashion, and should be discarded.

Enforce a Strong Security Architecture
If you have security at the foundation of AJAX, then building secure AJAX applications is just a matter of ensuring that you develop your applications in a secure manner. The dos and don’ts associated with this are wide ranging and have been enumerated and described in articles all over the web (at WhiteHatSecurity.com and OWASP.org, just to name a couple). So, it is not whether you can in theory, it is whether you can, and will, in practice.

Don’t expect your favorite JavaScript library to provide inherent security. You need to be conscious of security issues at every step of development. In fact, depending on which libraries you use, you may not be able to ensure security at all. Frameworks that rely on client-side interpreters and/or dynamic script injection are particularly vulnerable to attack, and they could introduce inherent insecurities to any application that uses them. Also, because of the complexity of most JavaScript AJAX libraries, security audits and thorough security testing may be next to impossible.

Don’t Trust the Untrusted Client
It is as plain and simple as it can be: the client is untrusted so don’t trust it. This means that you cannot trust client-side validation, you cannot trust client-side state management of sensitive information, and you cannot trust client-side business logic. But what do most client-centric AJAX libraries promote? You guessed it, all of the above. So if you are going to be security minded, you might not be able to fully leverage the features of your client-centric AJAX technology of choice.

Intertwined with all of this is the blurring of development roles. Client-centric AJAX approaches have already blurred the lines between application developers and web designers, and now the AJAX developer clearly is going to have to be a security expert as well. This blurring of roles compromises proficiency and stifles creativity at all levels. And of course, when you consider all aspects of cross-domain expertise, skill sets start to go from scarce to nonexistent.

All in all, the challenges involved in delivering secure AJAX applications appear to be fairly daunting. What is really needed is an approach that provides inherent security, and maintains role distinction so that security experts can ensure security, while developers and designers focus on creative application solutions.

Leverage Inherent Java and JSF Security
The untrusted client is fundamental to the web security model, and any AJAX approach that strives for inherent security must not compromise this. So you need server-centric approaches that can deliver AJAX-enriched presentation to the client, but restrict the client’s role to just that, presentation. In the enterprise Java domain, the most natural way to achieve a server-centric AJAX architecture is through JavaServer Faces (JSF). Several open source and commercial initiatives have proven this approach to be effective. From these various JSF-oriented offerings, this article examines the open source ICEfaces technology in greater detail to illustrate how security features in Java and JSF can be leveraged to produce an inherently secure architecture for AJAX application development.

This discussion presupposes that JSF and the backing Java enterprise stack of technologies is sufficient to develop secure web applications. The Java enterprise security architecture is well established, with appropriate technologies implemented and best practices well understood. The Java enterprise stack also supports separation of development roles, so within an established security architecture the JSF application developer can focus on application development and inherit from that underlying security architecture. Given this presupposition, if you can implement AJAX extensions to JSF without circumventing the standard JSF architecture, then AJAX applications based on this approach also will inherit the underlying Java security architecture. The key to preserving the JSF architecture is to preserve the JSF lifecycle from form submission to rendering of the response. The challenge is achieving AJAX features within those constraints.

The ICEfaces architecture illustrates how this is possible, beginning with the render response phase. Normal JSF rendering results in a complete page refresh, so in order to “AJAXify” the process, ICEfaces uses a technique called Direct-to-DOM rendering, with incremental update. Basically, the entire response is rendered directly into a server-side DOM, and incremental changes to the DOM are distilled out and delivered to the client via an AJAX bridge. The client-side of the bridge reassembles the changes in the browser DOM, resulting in smooth incremental page updates as you would expect from an AJAX application.

Figure 1. Basic Architecture of ICEFaces Partial Submit Mechanism

The other half of the equation is reacting in an AJAXian manner to user interaction with the page. ICEfaces achieves this with a partial submit mechanism that allows the developer to define what components in the page will automatically submit over the bridge, based on user interaction. Partial submit adheres to the normal JSF form submit mechanism, and it is initiated using XHR in the bridge. A partial submit results in execution of the full JSF lifecycle, including validation of all controls with which the user has interacted. Lifecycle execution completes with rendering of a new presentation and incremental changes delivered over the bridge to the client browser. (Figure 1 illustrates the basic architecture.)

This architecture allows Java enterprise developers to build pure server-centric Java applications that include AJAX functionality without requiring any low-level AJAX development and that inherit underlying Java enterprise security characteristics. Concrete security benefits that the approach delivers include the following:

• The application is completely server-centric. No business logic or application data is managed at the client, only pure presentation.
• Validation is all performed server-side, so no mismatches or inconsistencies between client-side and server-side validation can occur.
• XHR is used only for standard form submission. No security pinholes are opened with XHR acting as a data interface into the server-side application data. The attack surface is limited to the UI itself, eliminating invisible attacks.
• The AJAX bridge is fixed-size and fixed-function, making it security-auditable and -testable.
• No dynamic script injection is required, and there are no client-side interpreters that can be compromised.
• JSF automatically escapes output, preventing injection of malicious JavaScript and cross-site scripting attacks.
• Back-end persistence technologies such as Hibernate escape SQL input, preventing SQL-injection attacks.
• Existing Java enterprise access-control techniques can be applied.
• SSL can be used to secure the connection.

Inheriting Security Is Easier Than Inventing It
Now if you go back to your long list of AJAX security dos and don’ts, you will see that this approach gives pretty good blanket coverage. Security is inherent, allowing developers and designers to focus on the creative aspects of application development. So if you are about to enter the world of enterprise AJAX development and security is paramount, use server-centric approaches based on JSF and inherit a security architecture rather than inventing one yourself.