Enterprise Ajax security with ICEfaces.

The question is simple: Can enterprise application developers deliver Rich Internet Applications using Ajax techniques, but do so in a secure and cost-effective manner?

The evidence is mounting: The Yammer (1) and MySpace (2) worms are two early examples that illustrate Ajax based implementations are susceptible to attack, and these attacks have the particularly nasty characteristic of being completely invisible to the users being violated, and thus can proliferate at astounding rates.

The solutions are sparse: While the Ajax world is exploding with new capabilities and wiz-bang features, technology providers have been derelict in addressing fundamental security issues in the offerings they promote, leaving a formidable security challenge for the application developer to address. In this paper we will examine some of the fundamental security issues related to client-centric Ajax techniques, and will show how these issues can be overcome using a server-centric approach based on Java EE and ICEfaces.

The Fundamentals of Ajax Insecurity

The client is untrusted, SO DON"T TRUST IT! This is as fundamental as it gets. The entire web security model is based on the premise of an insecure client, and established and proven security architectures have evolved on this basis. With the popular adoption of Ajax techniques, there is a growing tendency toward client-centric implementations despite the fact that the approach breaks the fundamental premise of the untrusted client.

So, regardless of what client-centric Ajax technology you might pick, you will have to address some fundamental security issues.

Client-centric business logic and data: In order to enable a rich user interface, most sophisticated Ajax libraries promote a client run time environment where the user interface and associated business logic and data coexist on the client in order to achieve the rich interactive features required. There is simply no way to protect business logic and data in these types of implementations, which means that the developer must be diligent about identifying sensitive logic and data and determining how best to secure it. It will be necessary to push sensitive parts of the implementation back to the server in order to properly protect them, which can lead to considerable additional complexity in the implementation, and may severely restrict the Ajax features that can be used.

Client-centric validation: While client-side validation using Ajax techniques can be effective for providing immediate feedback to the user, it cannot be trusted to ensure the data submitted back to the server-resident elements of the application is valid and safe. It is necessary to implement a complete server-resident validation subsystem to sufficiently protect server-based assets. Now you face the challenge of maintaining two sets of validation logic, and any inconsistencies between them may open a security hole in the application.

Furthermore, an attacker may gain clues on how to attack the application by examining the client-resident validation logic.

XMLHttpRequest (XHR): The XHR is fundamental to all Ajax approaches, and the basic mechanism itself does not introduce additional security concerns as it inherits the same privileges as the initial HTTP request. Additionally, XHR is not permitted to make cross-domain requests, so in itself XHR can be a secure mechanism. The security issues with XHR arise from its improper/ insecure use. One prevalent approach is to use XHR to implement a network interface back into server-resident resources. While this may be the most straightforward way to implement a client-centric, Ajax-based application, the network interface to those protected services cannot be concealed and offers the hacker a well-defined attack surface, if proper access control is not established. The security concerns with XHR are magnified by the invisible nature of mechanism. Any security violation achieved through XHR can occur without being in any way visible to the user, which means that a security breach can propagate rapidly through a community of users that is completely unaware that an attack is in progress. The use of XHR in cross-site scripting attackscan be particularly lethal for this reason.

Implementation Complexity: The distributed nature of a client-centric, Ajax-enabled, application introduces complexity to the application when compared with traditional server-centric approaches. It requires a significant amount of JavaScript development, which in itself introduces complexity to development and testing. Furthermore, the distinct roles of developer, designer, and security expert are blurred in this model. Now your JavaScript developer needs to be a security expert as well. The bottom line is that as complexity rises, the potential for security issues also rises, and the QA process will not typically catch these issues, as they manifest themselves as hidden unintended functionality. This unintended functionality can be fertile ground for the diligent attacker. Beyond the complexity of your own implementation, the implementation of the Ajax framework itself may be inherently insecure. It is a pretty safe bet that a complete security audit has not been performed on your JavaScript framework of choice.

Security Through Obscurity: The notion of the untrusted client trumps the notion that client resources can be protected through some form of obfuscation. The simple fact is, obfuscation provides no real security, and in the worst case may provide a false sense of security to the developer.

Leveraging the Java EE Architecture

From the previous discussion it is clear that there are fundamental security concerns with client-centric approaches, and that extreme diligence will be required to implement a suitable security architecture. There is a big advantage if we can step away from client-centric approaches and back toward server-centric approaches, as we can leverage the existing, industry-proven Java EE security architecture.

[FIGURE 1 OMITTED]

An Established Security Architecture: Security has always been a first-class consideration in the Java EE stack and has matured to the point where the security architecture is well established from the persistence layer through to the presentation layer. Furthermore, proven implementations such as JAAS and Acegi are prevalent, so you don't have to invent a security architecture and implement it yourself.

Separation of Roles: Another advantage of the Java EE architecture is that it promotes clean separation of roles between the page designer, Java developer, and security architect. The security architect can establish overall security policies, and identify appropriate technologies for implementation. The Java developer can use the specified security technologies to implement back-end security, and establish necessary access control at various levels of the application architecture. The page designer can deal with high-level concepts like user roles when implementing the 151, and will not have to be concerned about the details of the access control implementation itself.

So where is the Ajax? It is all fine and good to say we are going to use a server-centric approach and leverage the existing Java EE security architecture while maintaining separation of roles during development, but can we achieve effective rich client features based on Ajax techniques with such an approach? We turn our attention to the Java EE presentation layer technologies to make this determination. JSF is the most recent addition to the Java EE stack and it provides a good foundation to build on. JSF itself is not Ajax-enabled and relies on a full-page refresh to effect presentation changes, but it is completely server-centric so provides us with the security characteristics that we seek. So, if we can establish Ajax functionality in JSF without compromising the server-centric nature of the framework we will be able to inherit the existing Java EE security architecture. This is precisely where the open source ICEfaces technology comes into play.

ICEfaces: Server-centric Ajax with JSF

Preserving the JSF Lifecycle: Central to the JSF architecture is the JSF lifecycle, which is illustrated in Figure 1 below.

The lifecycle kicks off with a standard request, which is processed to apply request values, passes through validation, updates the model values, invokes application-specific processing, and finally results in new presentation generated from the render response phase of the lifecycle. If you look to Ajaxify JSF it is important that the approach not circumvent the JSF lifecycle, otherwise you may be circumventing the servercentric security architecture that we seek to preserve. You can expect that if XHR is used from the JSF generated presentation markup to directly access server-side resources you will be exposed to the same security concerns associated with client-centric approaches. In order to ensure lifecycle preservation, any use of XHR needs to be restricted to standard form submission so the entire JSF lifecycle can execute. There are two key mechanisms required to achieve Ajax functionality under this restriction.