Discussions

News: HDIV 2.0, Web Application Security Framework, support Spring MVC

  1. 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

    Threaded Messages (6)

  2. Well done![ Go to top ]

    I was waiting for this new release of HDIV. I think it is a very good improvement to support such a powerful framework as Spring MVC. Congratulations!
  3. Only for JSP-based sites?[ Go to top ]

    I watched the introductory PPT slideshow, and HDIV looks like a really useful product. However it seems like it can't be used with sites that don't use Struts/Spring or JSPs. Is this true?
  4. Re: Only for JSP-based sites?[ Go to top ]

    I watched the introductory PPT slideshow, and HDIV looks like a really useful product. However it seems like it can't be used with sites that don't use Struts/Spring or JSPs. Is this true?
    Currently HDIV supports JSP custom tags for Struts 1.x, Struts 2.x, Spring MVC 2.0 and JSTL 1.1. It also supports Struts 2's freemarker html tags (form components and link). You can see an example within showcase example application (token option), see "Example 4 (token based freemarker example)". We are working as weel in Velocity but it hasn't got a link template and we have to do it. It's possible to apply HDIV on whatever presentation technology but of course you have to update or create links and html form components in order to call HDIV methods within html creation process. For example, this is an example of freemarker hidden component template:
    name="${parameters.name?default("")?html}"<#rt/> <#if parameters.nameValue?exists> <#assign hdivValue = dataComposer.compose(parameters.name?default("")?html, "${parameters.nameValue}", false)/> value="${hdivValue}"<#rt/> <!--#if--> <#if parameters.id?exists> id="${parameters.id?html}"<#rt/> <!--#if--> <#if parameters.cssClass?exists> class="${parameters.cssClass?html}"<#rt/> <!--#if--> <#if parameters.cssStyle?exists> style="${parameters.cssStyle?html}"<#rt/> <!--#if--> />
    As you know HDIV needs to know information about forms and links, including: parameter name, parameter value and destiny url. In this template, HDIV needs to know hidden parameter's name and value. In order to get it , HDIV exposes a java object (DataComposer) within the request, which has the responsability to create HDIV States and process them depending on the defined strategy (memory, cipher,hash). For example, if you are using memory strategy , dataComposer object stores created HDIV state within HttpSession.
  5. _HDIV_STATE_ and JSESSIONID[ Go to top ]

    What's the conceptual difference between the two? Non editable data may be stored in http session and is not available at the client side at all.
    For example a link of this type, http://www.host.com?data1=12&data2=24 is replaced by http://www.host.com?data1=0&data2=1, guaranteeing confidentiality of the values representing database identifiers. Also it is possible to hide the name of the parameters becoming the link into http://www.host.com?0=0&1=1.
    Its still possible to change the URL like this: http://www.host.com?data1=1&data2=0 or http://www.host.com?0=1&1=0 Still if the hidden data stored in the http session then its impossible to bookmark the link since the keys are not stored persistently in the session.
    State is stored in the client as a parameter
    This reminds me of ASP.NET's view state approach. Web frameworks gives this functionality to developers. So why use HDIV?
  6. Re: _HDIV_STATE_ and JSESSIONID[ Go to top ]

    I agree, it's possible to implement all the functionalities offered by HDIV by hand , using basic functionalities offered by Servlets specification. The same happens with other many technologies available in the Java world that they automate other tasks that you can do by hand if you want. With the same logic you can say that Hibernate or JPA don't offer nothing new, since you can do the same work using plain JDBC. In other words, HDIV automatizes a very important and hard task (mainly non editable data automatic validation) that many web frameworks (at least web frameworks supported by HDIV) don't offer, and you must to implement it by hand. Considering that within a web application there are thousands of possible requests, it's very easy to forget a validation and generate an important vulnerability. About bookmarkable links, it's obvious that HDIV is useful for authenticated web applications and not for public web pages.
  7. Re: _HDIV_STATE_ and JSESSIONID[ Go to top ]

    With the same logic you can say that Hibernate or JPA don't offer nothing new, since you can do the same work using plain JDBC.
    I'd argue about this but not in this thread.
    In other words, HDIV automatizes a very important and hard task (mainly non editable data automatic validation) that many web frameworks (at least web frameworks supported by HDIV) don't offer, and you must to implement it by hand.
    Well, probably I became spoilt with Tapestry too much...
    About bookmarkable links, it's obvious that HDIV is useful for authenticated web applications and not for public web pages.
    I mean, its physically possible to bookmark the URL http://www.host.com?0=0&1=1 Say user wants to bookmark URL to his own user account for quick access to the page. What happen if he/she navigate this link using new instance of a browser (new session)? Its okay if session expired will occure, but... will it?