Difference between HDIV and ESAPI

Question

I am planing to develop a web application using Spring MVC and trying to figure out which is the best library to use to over come Top 10 OWASP issue. I came to see two HDIV and ESAPI, can any one please help me to understand the difference between them.

Thank you for your help.

Answer 1

Well first and foremost, OWASP's ESAPI is no longer a flagship product for OWASP anymore: major development work on the library stagnated and the 2.1 release was just to fix a major CVE. Looks like regular contributions go into the HDIV library. HDIV also has copious resources demonstrating how to integrate it into common web frameworks--their documentation covers Spring, Grails, and of course it started with Struts1 and Struts2.

HDIV provides a powerpoint that talks about its architecture. Though I really don't like that it says it eliminates XSS (it doesn't, and cannot) the basic architecture looks pretty good.

The only thing IMHO that HDIV appears to be missing when searching the documentation is a method of canonicalization-as-intrusion-detection. In theory, because its relying on hashes taken on non-editable data, you are getting a warning that someone tried to possibly tamper with your parameters. However, with esapi, it will detect muliple encoding attacks and inform you accordingly--it gives you better information. (Parameter name, user Id, and the attempted input.)

Also HDIV doesn't appear to have several features that ESAPI provides:

• Protection against log injection
• Authentication mechanisms --> While rarely used, it does have a better implementation for Java Security than what you get out of the box. It also has an intuitive model of a user.
• Well -tested cryptographic implementations --> If you want safe-to-use Java crypto, security assessments HAVE been run against ESAPI.
• SQL Injection defenses that can be used in instances where (for some reason) you can't use parameterized queries or stored procedures.
• Context-specific output encoding. Though due to ESAPI's current status of collecting dust, if you need encoding I would use this instead.. Its important to note that proper output escaping is 10M times better than any input filtering/validation. You can skip a WAF and still have excellent security. The reverse statement is false.
• Fine-grained control of parameter-specific input validation. The WAF approach just labels generic field types and applies a one-rule-fits-all approach to rule types. ESAPI lets you get as fine grained as you want by using validation.properties.

Answer 2

First of all I think the approach and scope of both web application security frameworks is different. In some of the aspects they can be also complementary solutions that can be used together.

Regarding the approach, HDIV tries to automate security best practices through the integration with web frameworks. In order to implement this approach, HDIV has been integrated within some of the most used Java/JVM web frameworks such as: Spring MVC, Grails, JSF, Struts 1, Struts 2. It’s important to note that if your application uses web frameworks tags to render links and forms, HDIV does not require any change within the source code, just a declarative configuration (XML or Java config based configuration).

On the other hand, ESAPI offers a number of utilities (APIs) that developers must use within their source code. In other words, the programmer has to include manually all this utilities in their source code. ESAPI is not web framework dependent and can be used in any web application because it's not integrated with web frameworks.

Regarding the scope, HDIV does not cover some of the features offered by ESAPI and also is limited to the supported web frameworks. It's important to note that some of these features are already covered by web frameworks (Struts, Spring MVC,...) or by solutions like Spring Security:

• Authentication and session management: covered by application servers and Spring Security
• Output Encoding: covered by web frameworks tags (in that case Spring MVC) to avoid XSS (escape functions). Not covered for other kind of encoding like encoding to avoid SQL Injection.
• Cryptographic functions: covered by Spring Security (http://docs.spring.io/spring-security/site/docs/3.1.7.RELEASE/reference/crypto.html) or also ESAPI. I haven’t compared both frameworks but it seems they are similar.
• Parameter-specific input validation: covered by all web frameworks (Struts, Spring MVC, etc.)

HDIV was designed as a complement to the security features offered by Java EE, Spring Security and web frameworks.

In order to understand more deeply the differences between HDIV and ESAPI I will try to compare the features to cover OWASP top ten web risks with both frameworks. I have included the features included within ESAPI 2.x and ESAPI 3.x at github (https://github.com/ESAPI).

A1- Injection:

• HDIV: regarding HTTP parameters’ values, urls and cookies HDIV reduce the risk of this vulnerability to only the data that come from text fields within forms, applying integrity validations for the rest of the data that come from client side (assures the received value is the same as the generated at server side). For text fields included within forms, HDIV offers generic validations (whitelist and blacklist) in order to avoid injection attacks.
• ESAPI: manual input validation for each parameter. This feature is useful but is already offered by almost all web frameworks. In addition to that, SQL encoding features to encode the SQL programmatically before the query execution.

A2-Broken Authentication and Session Management:

• HDIV: does not offer functionalities for this web risk. We recommend to use Spring Security for authentication and the application server features (Servlets specification) for session management.
• ESAPI: offers utilities that must be used programmatically by programmers.

A3-XSS: the same as A1 but in that case to avoid XSS risks.

• HDIV: regarding HTTP parameters’ values and urls HDIV reduce the risk of this vulnerability to only the data that come from text fields within forms, applying integrity validations for the rest of the data that come from client side (assures the received value is the same as the generated at server side). For text fields included within forms, HDIV offers generic validations (whitelist and blacklist) in order to avoid injection attacks injection attacks. HDIV does not include any output encoding feature and delegate this responsibility to web frameworks tags, in this case Spring MVC.
• ESAPI: includes manual input validation for each parameter. This feature is useful but is already offered by almost all web frameworks. Also offers Output encoding features for output encoding. This encoder must be used by programmers within source code.

A4-Insecure Direct Object References:

• HDIV: controls all the data generated at server side (processed by framework tags) ensuring the integrity of the data and eliminating this risk. Does not require any source code change within supported web frameworks. It's important to note that HDIV supports different methods to manage the recollected information: cipher (the state is sent ciphered within the response), memory (the state is stored within HttpSession), hash (the hash of the state is stored in HttpSession and the content within the web response).
• ESAPI: it’s necessary to create a map to include each parameter programmatically and store it in session.
  (http://www.jtmelton.com/2010/05/10/the-owasp-top-ten-and-esapi-part-5-insecure-direct-object-reference/). This feature is included within ESAPI 2.x but I haven’t found within ESAPI 3.x.

A5-Security misconfiguration:

• HDIV: doesn’t include specific functionalities for that but does not allow the access to resources not sent by the server previously, avoiding the exploitation of unexpected behaviors or access to private resources.
• ESAPI: I haven’t found any feature but I am not an expert in ESAPI.

A6-Sensitive Data Exposure:

• HDIV: offers confidentiality feature to hide the values of HTTP parameters. HDIV does not offer any cryptographic API.
• ESAPI: offers a cryptographic API to encrypt, decrypt, etc. More detail at: https://github.com/ESAPI/esapi-java-legacy/blob/master/documentation/esapi4java-core-2.0-crypto-design-goals.doc. This features are included within ESAPI 2.x but I haven’t found within ESAPI 3.x.

A7-Missing Function Level Access Control :

• HDIV: thanks to the integrity validations implemented by HDIV, avoids the exploitation of this web risk and limit the use only URLs generated previously by the server, maintaining the original contract offered by the application.
• ESAPI: offers an API to implement it programmatically. As far as I know It’s similar to the features offered by Spring Security that must be used by programmers within source code to securize each URL.

A8-Cross-Site Request Forgery (CSRF):

• HDIV: adds aleatory tokens to avoid this vulnerability to each form thanks to the HDIV integration with web frameworks form tags.
• ESAPI: offers an API to generate tokens. This tokens must be added by programmers manually to each web form.

A9-Using components with known vulnerabilities:

• HDIV: does not include specific functionalities for that but thanks to the interaction limitations applied by HDIV to the user in many cases is not possible to exploit the known vulnerability.
• ESAPI: I don’t see any feature within the documentation but I am not an expert in ESAPI.

A10-Unvalidated redirects and forwards: This vulnerability is mainly related to the manipulation of non editable data or data generated previously at server side and it’s very similar to A4.

• HDIV: controls all the data sent by the server and doesn't allow the redirection to malicious web sites.
• ESAPI: the solution offered by ESAPI will be the same as the offered for A4 (AccessReferenceMap ) that must be used within the source code.

Roberto Velasco Sarasola (HDIV team)