HDIV is an open-source Java Web Application Security Framework, recently released version 2.0. The features offered by HDIV 2.0 are the same as the last release, but now they are available for new frameworks such as Spring MVC 2.0 and JSTL 1.1. In addition to that it has been added support for new versions of Struts 1 and Struts 2, specifically, Struts 1.3.8 and
Struts 2.0.9.
HDIV helps to prevent most of the common types of web application vulnerabilities, such as SQL injection, cross-site scripting, and parameter tampering.
Many times this short definition isn't enough to understand what HDIV is. In order to really understand it, it's necessary to understand which are the source of the most common web application vulnerabilities.
The main problem and the source of most problems is that all the data (html, cookies, etc), not only editable data, sent to the clients is editable by them. In other words, the first rule in web application security is: don't trust a client request!
Once this rule is known there is a second problem for the developer: how can the data sent back by the client be validated and trusted?
Some web frameworks already offer some validation functionalities but many times they are not enough to cover common validation needs. For example, if you have a link in your web application such as
http://www.myhost.com/action1.do?account=56 to read information about the account number 56, how can you guarantee that a client doesn't update this value to be able to check someone else's account? (They could, for example, alter the URL to point to account 40...)
With standard security validators (more suitable for editable data validation), it's not possible to check that and you need to create custom validations - for example, including an account id at HttpSession or using user identity in the SQL executed in the database. This security problem, known as instance level security, is very hard to solve because within a web application there are thousands of similar requests that need to be validated.
There are standard solutions for this problem. For example, Acegi (AKA Spring Security) offers an instance level security solution. Many times, however, it's difficult to apply it, especially when you work with old databases or heterogeneous information systems. Besides, there is an important performance overhead if you try to apply a generic instance level security solution.
That's why in many companies there isn't an instance-level security standard solution and they implement this security feature on their own.
Even when programmers are aware of these security risks, applications are usually vulnerable in some of the thousands of request.
It is at this point where it's very interesting to have a solution like HDIV, which offers:
- Integrity: HDIV guarantees integrity (no data modification) of all the data generated by the server which should not be modified by the client (links, hidden fields, combo values, radio buttons, destiny pages, cookies, headers, etc.). Thanks to this property HDIV avoids all the vulnerabilities based on the parameter tampering.
- Editable data validation: HDIV eliminates to a large extent the risk originated by attacks of type Cross-site scripting (XSS) and SQL Injection using generic validations of the editable data (text and textarea).
- Confidentiality: HDIV guarantees the confidentiality of the non editable data as well. Lots of the data sent to the client has key information for the attackers database registry identifiers, column or table names, web directories, etc.
As a consequence HDIV mitigates web application vulnerability risks and it serves as the first security wall in the application security.
Other of the lesser known functionalities offered by HDIV is log generation. For each detected attack HDIV generates a log including attack type, time, IP, username, parameters, url.
How HDIV works
First of all, it's important to understand how HDIV works. HDIV needs to know all the links and forms included within the resultant HTML and it gets them from custom tags when the JSP is processed at the server side. In addition to that HDIV adds an extra parameter (HDIV_STATE) to all the links and forms.
If the web application is using HDIV's supported custom tags to create all the links and forms, the integration of HDIV is very easy, as you only have to add a web filter and update the TLD definition within web.xml file. On the other hand, if the application creates links or forms elements directly (without supported custom tags), it's necessary to update the JSP to make it use custom tags.
HDIV architecture
HDIV has two main modules: Validation Filter and Custom Tags.
Validation filter and the core of HDIV are the same (included at the hdiv-core module) for all web frameworks but it's necessary to create new custom tags for each framework, because each framework has their own tags or tlds.
Future plans for HDIV- Webflow Integration
Currently HDIV supports three state management strategies. On the memory and hash strategies HDIV stores an object (state) at the server side for each possible request processed within a JSP (one of each link or form). From a scalability point of view it's interesting to limit the size of the server side cache. In the current release it's possible to define a maximum cache size but many times it's difficult to define an appropriate number because it depends on the application.
Webflow provides a way to logically divide clients navigation. Thus, HDIV will use webflow listeners capabilities to decide when to delete objects from the cache.
Another interesting feature it's to add automatically the webflow execution key to each link or form using HDIV's custom tags. Now within Struts, Struts 2 and Spring MVC applications we have to add this id manually and we would like to automatize this task.
- Support for other frameworks
Originally HDIV was designed for Struts, but it was thought as well in other frameworks future applicability. Currently HDIV supports: Struts 1.x, Struts 2.x , Spring MVC (Spring 2.0), JSTL 1.1.
For the future HDIV is planning to support: Webwork, Stripes and JSF.
You can get more details about HDIV from
hdiv.org
