New Security Threats in AJAX
As mentioned earlier, almost all of the security threats listed for AJAX applications also exist for traditional Web applications. However, there are some points that security-conscious developers and users should keep in mind when using AJAX. XHR requests can be issued asynchronously through JavaScript, exchanging data with the server without any visual feedback to the user. This bears the risk of a malicious application to protocol user interaction without a user’s knowledge. Let us take phishing as a possible AJAX attack. In a phishing attack, a malicious page pretends, for example, to be your local eBay home page. While logging into your eBay account you sense that there is something suspicious with the page and don’t press the submit key but instead close the window. If an XHR request was sent to the server while you typed the password, then whoever owns the malicious page now owns your password. Obviously there is no protection added to the XHR object that defines which script is allowed to use it. So the only protection is to deal with pages you trust and that identify themselves by a public key.

Another source of potential vulnerability is the ever-growing number of JavaScript libraries that are built to make AJAX development easier. You might be introducing another breach of security when you add libraries to your application without knowing the library developers personally, or without checking that the libraries are secure. Even if these library developers were security conscious, would you know which library functions can be executed from a browser URL field and which cannot? How does the library change its behavior if it is used in conjunction with other libraries? I’m not saying that libraries are insecure and should not be used, rather, that not to care about their security is, in itself, insecure behavior.

AJAX is only at the beginning of its evolution and steadily strides toward real desktop integration. This integration adds more functionality to the JavaScript client, possibly in conjunction with lowering the sandbox in which JavaScript is executed. These are all client security issues – the art of protecting the user client from malicious applications, whereby, in fact, the attack surface for application security has not changed at all.

AJAX Application Security with JEE
The art of protecting an application from its users consists of identifying who those users are and successfully enforcing authorization policies. In JavaScript, nothing can be hidden on the client. This means that any code and object instance on the client can be viewed and modified. There is nothing an application can do today to lock down the browser client. If, as a security conscious developer, you don’t control the client, how can it be trusted?

If the client cannot be trusted, then it becomes disqualified to perform authentication and authorization enforcement, and these tasks must to be delegated elsewhere. The Java Platform, Enterprise Edition (JEE), contains a security architecture that meets the security requirements of Web applications, namely reliable authentication, session, and state management; data privacy; and fine-grained authorization. When you use AJAX in combination with JEE, security is enforced on the server on a server-side visual representation of the UI that is rendered to the client. Because no policy is directly accessible on the client via JavaScript, it cannot be changed or modified.

Authentication
The JEE platform provides a declarative and programmatic authentication through container-managed authentication and the Java Authentication and Authorization Service (JAAS). The majority of application servers support a combination of the two so that authentication in JEE becomes pluggable for the administrator to use the security provider of choice. The authentication mechanisms that can be used with AJAX are single sign-on, JAAS LoginModule authentication, container-managed authentication, and Public Key Infrastructure (PKI) authentication. The JEE authenticated user is accessible from the JEE request object so the identity can be propagated to other application layers. An AJAX application user authenticates to the middle tier and the database with a single login. The security context that is built on the server and in the database is not accessible on the client and therefore cannot be modified.

Developers who prefer to use the XHR object method for authentication should be aware of the following limitations:

• When using basic authentication in XHR, any failed login attempt is handled first by the browser, which pops up its own login dialog to retype the username/password pair. To avoid this, use form-based authentication and check the returned HTTP error code.
• PKI-based authentication is not possible in XHR. JavaScript does not have an API that allows an application to access the browser certificate store for authentication. Even if there were an API exposed on the XHR object, there would not be any means for the browser to determine which scripts are allowed and which are not.

Authorization
Never bring a knife to a gunfight! The interactive client in AJAX is not a reliable security layer because security policies that are downloaded with data have the potential to be modified in the DOM tree. AJAX is a presentation layer that should not enforce authorization. Instead, the client should reflect server-side security policies when rendering components, such as buttons and text fields.

If this is not convincing enough for you, let’s assume security policies on the client were immutable. Because browsers do not provide a security context to be used by JavaScript, the security policy for an object must be downloaded as part of the object or function. If security policies get more complex, as in the case of instance-level security, then the downloading of policies needs to happen frequently. With each policy definition adding a minimum of 8 bytes per character to the message size, a negative performance impact can be anticipated.

Using the Java Authentication and Authorization Service (JAAS) authorization architecture in JEE, fine-grained access control is enforced through JAAS permissions in the context of the authenticated user. A server-side framework like JavaServer Faces, in conjunction with an AJAX UI, can ensure that the client display is rendered so it reflects the security policy enforced on the server. In an end-to-end security example, this could mean that information that a user is not allowed to see is not downloaded to the client at all, which also makes sure the information cannot be found in the DOM.

• Fortify's Rachwald Stresses AJAX Security in SYS-CON.TV Interview
• New ICEfaces White Paper Details Robust Security Solution For AJAX-Based Rich Web Applications