Hardening Utils Part 1: HDIV

Security can be implemented into a J2EE application on both programmatic as well as declarative ways. The much more flexible one is doubtless the later one which can be archived by using servlet filters or listeners and few lines in the specific deployment descriptor (web.xml). Some interesting projects have recently been kicked-off addressing certain security features in such a declarative fashion. I call them J2EE hardening utilities. The first, and probable most powerful one, I want to talk about is HDIV. Before I can do this, however, I have to explain one of its most interesting features: page tokens.

Page Tokens

As I have already explained in my last writing, HTTP is stateless so we need a session id (JSESSIONID) send either by cookie or within the url in each session-related request. By including such an id, a user can usually access all resources, no matter whether he has been given a specific link to it or not. This fact allows attacks such as Cross-site Request Forgery (CSRF) to be carried out. An attacker can send a link like http://application/?action=delete to an user authenticated to execute a certain command within the user's session and without ones noticing it. Of course this kind of attack would only be possible when the victim uses cookies for transmitting his session, because otherwise the URL wouldn't be generic any more and not foreseeable by the attacker, respectively. What we have to do here to prevent this attack is to include some session-related token into the URL in addition to the session cookie. This technique is known as session tokens.

We can improve this by using tokens which are not only related to the session but also to a certain page the user has received. This token can then be evaluated to only allow the user to access those pages he has provided a link to from the application itself. With this technique we can not only harden our applications session management but also the whole authorization system since the user can't access restricted pages such as http://application/admin when he never has provided a link to it.

The HDIV State

The HDIV state is basically an implementation of the page-token idea I talked above. Well, it can actually do even more then that. It distinguishes between two sets of HTTP parameters: those which are editable by the user such as input fields, text fields and so on and those which should normally never been manipulated by the user such as hidden fields. The later (non-editable parameters) are automatically included within the HDIV state object and validated on discrepancies on each client request. For being able to provide this feature in a transparent and automatic fashion, HDIV facilitates two techniques: First, it implements a servlet filter to check the correctness of the parameters provided.
Second, it extends various taglib libraries (Struts, Spring MVC and JSTL) to automatically insert the HDIV state as an additional parameter in all kind of link elements such as or as an extra form element (hidden field). This depends on how you configure HDIV, this state parameter can then either be a short reference to the state object in the users session object (example: _HDIV_STATE_=12-23-2323) or a pretty nasty long parameter holding all state data in a encrypted and base 64 encoded way, respectively. Since certain sites such as start pages (/index.jsp) should or must be accassable without any state information, these pages can of course easily be excepted of HDIV's validation. As complicated it might sound at first, HDIV is a pretty easy to handle tool and provides your application an awesome amount of security out of the box, as long as it fully facilitates one of the supported frameworks (Struts, Spring MVC or JSTL).

Here is an example source code snippet from an HDIV secured site:

The HDIV Validator

HDIV comes with a nice validator functionality allowing you to check all ingoing parameter values for suspicious characters (such as <>," ) that could be facilitate by an attacker to carry out an Cross-site Scripting attack, SQL injection and so forth. Since HDIV only allows editable parameters to be manipulated by the user, validation rules have only to be applied to those parameters (e.g. input fields). However, since HDIV is based on Spring its configuration is pretty long-winded for implementing an own validation rule base. In one of my next postings, I will present a much more suitable tool for this job: OWASP Stinger.

More Features

HDIV also supplied several additional features I haven't talk about yet. One example is Cookie protection, which works roughly in the same way as with non-editable parameters. The other is parameter obfuscation, where all parameter names and non-editable parameter values, are obfuscated by HDIV so that an attacker can get no clue about the function of this as he might would get when seeing parameters such as "id" (database object id) or "file=/test.jsp" (possible filename injection). Instead he will only see a query string like "1=1&2=2" which HDIV will map transparently to its real values stored in the state object before they are send to the application. HDIV has even more that it can do, just have a look at its decent documentation.