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.
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)
Menu
915
