RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Inherent AJAX Security with Java and JSF : Page 2

Developing enterprise AJAX applications can raise security concerns. By applying server-centric approaches that leverage the inherent security of Java and JavaServer Faces, you can deliver AJAX-enriched presentation to the client, but restrict the client's role to just that—presentation.

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.

Click to enlarge
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.

Stephen Maryka, Chief Technical Officer at ICEsoft Technologies Inc., leads the development of all AJAX-based technologies. He is responsible for ICEfaces product development and all AJAX-related R&D.
Email AuthorEmail Author
Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date