Validation of input using the Hibernate Validator (JSR 303) compared to other platforms (ESAPI, Apache Commons, etc.)

Question

I looked at various frameworks for validating input, including the Hibernate Validator impl for the JSR 303 bean validation, as well as the ESAPI authentication interface and DefaultValidator .

ESAPI input validation revolves around matching a regular expression pattern through the ESAPI.properties file.

ESAPI Route :

ESAPI.properties:

Validator.SafeString=[A-Za-z0-9]{0,1024}$ 

Java class:

 ESAPI.validator().isValidInput("Name","darthvader", "SafeString", 255, false) 

Hibernate Validator / Spring MVC Route

Hibernate includes annotation of your bean with various constraint annotations (@NotNull, @Size, @Min, @Pattern, @Valid, etc.). And Spring MVC integration for validation rules.

 @RequestMapping(value = "/appointments", method = RequestMethod.POST) public String add(@Valid User user, BindingResult result) { .... } 

It seems that using Hibernate Validator / Spring MVC provides similar functionality using regex, etc. Are there any advantages to using the ESAPI library over the Hibernate validator api? Maybe for SQL injection / XSS or something like that? XSS / SQL implementation protection provided out of the box to validate ESAPI input? Any real advantages over using one or the other. Thanks in advance.

Answer my own question: I think I have come to my decision on this post. Using Hibernate / Spring MVC allows for quite robust w810 validation functionality. And Hibernate provides secure annotations like @SafeHtml, @Pattern, etc. Basically, we can set up a composite set of annotations that provide bean validation. http://docs.jboss.org/hibernate/validator/5.0/reference/en-US/html_single/

Answer 1

Are there any advantages of using ESAPI library over Hibernate api validator?

I am a security guy, so the first thing I will say is that before worrying about validating the input, make sure you have contextual screening before science in the background, before you ALWAYS worry about validating the security level. If the data arrives in the database, make sure that you avoid it for the query (or prepared statements OR stored procedures), and when processing this data, avoid it properly to send it to the downstream web service / command line / etc or re-submit these user data (html / javascript / actionscript / etc)

Now that I have the required part, both libraries are used for a variety of things. The main goal of the ESAPI project is that it is designed to protect applications that were unsuccessful in order to be developed without security mechanisms from the very beginning. For example, these are pre-packaging methods encoding data for SQL injection, which, possibly, cannot be immediately rewritten as parameterized queries or stored procedures due to complexity / time constraints / etc. However, Hibernate was designed as an implementation of JPA (as you pointed out), and the link to the specification is why output escaping is 100 times more important than input filtering.

Answering your first question:

Are there any advantages of using the ESAPI library over the Hibernate api validator?

• First of all, "@SafeHtml" in Hibernate is not part of JSR 303, so using it you bind your JPA implementation directly in Hibernate. This is detrimental to maintenance.
• The ESAPI validator gives you the ability to modify validations through validator.properties , which means that you can do business problems in production without having to go into development to create a completely new assembly, as is currently happening in the annotated model.
• ESAPI authentication has been designed, written and tested by security experts.
• This is the most important thing: ESAPI gives you ESAPI.encoder().canonicalize() , which is used implicitly in any of the ESAPI calls Validator.getValidHtml(args...) . This method alone allows you to determine if someone is attempting a multiple encoding attack against your application. A similar call does not exist in any other Java security library that I know of, definitely not in the implementation of the Hibernate validator - and I would never expect Hibernate to receive this call from its domain library.

4 cannot be overestimated in importance, since multiple coding attacks are how most XSS is injected into applications in the wild. This forces the entire input to be encoded in a single URL and allows you to immediately identify the user trying to enter such input into the application.

ESAPI really has a big flaw. As of the fall of 2014, he lost his flagship status at OWASP due to stagnant community development. Time will tell if the ball will start with ESAPI 3.0.

Answer 2

Just for information, I created a set of annotations based on the Hibernate Validator designed to validate input:

https://github.com/righettod/hibernate-validator-security-contribs

Hope this can help :)