Geek Answers Handbook

The difference between HDIV and ESAPI

I plan to develop a web application using Spring MVC and trying to figure out which of the best libraries to use in the top 10 OWASP issues. I came to see two HDIV and ESAPI, can someone help me understand the difference between them.

Thank you for your help.

+4
source share
2 answers

First of all, I think that the approach and scope of both web application security systems are different. In some aspects, they may be complementary solutions that can be used together.

Regarding the approach, the HDIV is trying to automate security best practices through integration with web frameworks. To implement this approach, HDIV was integrated into some of the most used Java / JVM web frameworks, such as: Spring MVC, Grails, JSF, Struts 1, Struts 2. It is important to note that if your application uses the framework’s web interface for rendering links and forms, HDIV does not require any changes in the source code, just a declarative configuration (XML or Java based configuration).

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

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

  • Authentication and Session Management: Covered by Application Servers and Spring Security
  • Output encoding: covered by web framework tags (in this case Spring MVC) to avoid XSS (escape functions). Does not apply to other types of coding, such as coding, to avoid SQL injection.
  • Cryptographic functions: protected by Spring Security ( http://docs.spring.io/spring-security/site/docs/3.1.7.RELEASE/reference/crypto.html ) or also ESAPI. I did not compare both structures, but they seem to be similar.
  • Validation of parameter-dependent input parameters: covers all web frameworks (Struts, Spring MVC, etc.)

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

To better understand the differences between HDIV and ESAPI, I will try to compare features to cover the OWASP web risks on both networks. I have included the features included in ESAPI 2.x and ESAPI 3.x in github ( https://github.com/ESAPI ).

A1- Injection:

  • HDIV: regarding HTTP parameter values, URLs and HDIV cookies, the risk of this vulnerability is only for data coming from text fields in forms, applying integrity checks for the rest of the data coming from the client side (ensures that the received value is the same as and generated on the server side). For text fields in forms, HDIV offers general validations (whitelist and blacklist) to avoid injections.
  • ESAPI: Validation of input for each parameter. This feature is useful but already offered by almost all web frameworks. In addition to this, SQL encoding functions for SQL encoding programmatically before executing a query.

A2-Broken Authentication and Session Management:

  • HDIV: does not provide functionality for this web risk. We recommend using Spring Security for authentication and an application server (servlet specification) for session management.
  • ESAPI: offers utilities that programmers should use programmatically.

A3-XSS: same as A1, but in this case, to avoid the risks of XSS.

  • HDIV: regarding the values ​​of HTTP parameters and URLs, HDIV reduces the risk of this vulnerability only for data coming from text fields inside forms, applying integrity checks for the rest of the data that come from the client side (assures that the received value is the same as that generated on server side). For text fields included in forms, HDIV offers general validations (whitelist and blacklist) to avoid injections during injections. The HDIV does not include any output and delegate this responsibility to the website tag frameworks, in this case Spring MVC.
  • ESAPI: Enables manual input validation for each parameter. This feature is useful, but already offered by almost all web frameworks. Also offers encoding output for encoding output. This encoder should be used by programmers in the source code.

Links to a direct A4-Insecure object:

  • HDIV: monitors all data created on the server side (infrastructure tags are processed), ensuring data integrity and eliminating this risk. It does not require changing the source code within a supported web framework. It is important to note that HDIV supports various methods of managing the recalled information: cipher (the state is transmitted encrypted in response), memory (the state is stored in HttpSession), hash (the state hash is stored in HttpSession and content in the web response).
  • ESAPI: You must create a map to enable each parameter programmatically and store it in a session.
    ( http://www.jtmelton.com/2010/05/10/the-owasp-top-ten-and-esapi-part-5-insecure-direct-object-reference/ ). This feature is included in ESAPI 2.x, but I did not find it inside ESAPI 3.x.

A5-Security Configuration:

  • HDIV: does not contain specific functions for this, but does not allow access to resources not sent by the server before, avoiding exploitation of unexpected behavior or access to private resources.
  • ESAPI: I did not find any function, but I am not an expert in ESAPI.

A6-sensitive data exposure:

A7: There is no access control to the functional level:

  • HDIV: Thanks to the integrity check implemented by HDIV, it avoids the use of this web risk and limits the use of only URLs created by a server that supports the original contract offered by the application.
  • ESAPI: offers an API for implementation programmatically. As far as I know, this is similar to the functions offered by Spring Security, which should be used by programmers in the source code to ensure the security of each URL.

A8-Cross Site Request Subroutine (CSRF):

  • HDIV: Adds aleatory tokens to avoid this vulnerability for each form by integrating HDIV with the form tags of web frameworks.
  • ESAPI: offers an API for creating tokens. These tokens must be manually added by programmers for each web form.

A9 - Using components with known vulnerabilities:

  • HDIV: does not contain specific functions for this, but thanks to the interaction restrictions applied by HDIV to the user in many cases it is impossible to use a known vulnerability.
  • ESAPI: I do not see any function in the documentation, but I am not an ESAPI expert.

A10-Unvalidated redirects and forward: this vulnerability is mainly related to the manipulation of non-editable data or data created earlier on the server side, and is very similar to A4.

  • HDIV: controls all the data sent by the server and does not allow redirection to malicious websites.
  • ESAPI: The solution proposed by ESAPI will be the same as that proposed for A4 (AccessReferenceMap), which should be used in the source code.

Roberto Velasco Sarasola (HDIV Team)

+16
source

First of all, OWASP ESAPI is no longer the flagship product for OWASP: the main development in the library has stalled, and release 2.1 is just a fix for the main CVE. Regular contributions seem to go to the HDIV library. The HDIV also has rich resources demonstrating how to integrate them into common web frameworks - their documentation covers Spring, Grails, and, of course, it started with Struts1 and Struts2.

The HDIV provides a powerpoint that talks about its architecture. Although I really don't like the fact that he says that he excludes XSS (this is not so and cannot), the main architecture looks pretty good.

The only thing that IMHO, which HDIV is apparently missing when searching for documentation, is a method for detecting canonization as an intrusion detection. Theoretically, since it relies on hashes taken on non-editable data, you get a warning that someone tried to influence your parameters. However, with esapi, it will detect multicode attacks and let you know - this will give you better information. (Parameter name, user ID, and attempted input.)

In addition, the HDIV does not have several features that ESAPI provides:

  • Log protection
  • Authentication mechanisms → Although rarely used, it has a better implementation for Java security than what you get out of the box. It also has an intuitive user model.
  • Well-tested cryptographic implementations -> If you want secure Java cryptographic analysis, security assessments were performed against ESAPI.
  • SQL Injection protection, which can be used when (for some reason) you cannot use parameterized queries or stored procedures.
  • Context-sensitive output encoding. Although due to the current state of ESAPI dust collection, if you need encoding, I would use instead . . It is important to note that proper output shielding is 10M times better than any input filtering / validation. You can skip WAF and still have great security. The converse is false.
  • Clear control of input parameter checking. The WAF approach simply labels common field types and applies a single rule approach to all rule types. ESAPI allows you to get the finest grains possible using validation.properties .
+5
source

More articles:


All Articles