Input Validation using Hibernate Validator(JSR 303) vs other Frameworks (ESAPI, Apache Commons etc)

Question

I've looked at various frameworks for input validations, including Hibernate Validator impl for JSR 303 bean validations, as well as ESAPI validator interface and its DefaultValidator implementation.

ESAPI input validation revolves around regex pattern matching through 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 involves annotating your bean with various constraint annotations (@NotNull, @Size, @Min, @Pattern, @Valid etc). And integrating Spring MVC for validations rules.

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

It seems like using Hibernate Validator/Spring MVC provide similar functionality with regex matching etc. Are there any advantages of using ESAPI library over Hibernate validator api? Maybe for SQL injections/XSS or anything of that nature? Security against XSS/SQL injection provided out of box for ESAPI input validation framework? Any real advantages over using one or the other. Thanks in advance.

Answer to my own question: I think I came to my own solution for the post. Using Hibernate/Spring MVC allows pretty robust bean validation functionality. And Hibernate provides secure annotations such as @SafeHtml, @Pattern, etc. Basically we can set a composite set of annotations that provide the 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 validator api?

I'm a security guy so the first thing I'm going to say is that before you worry about input validation, make sure you've got context-escaping down to a science on the back end before you EVER worry about security-level input validation. If the data is going to the database, make sure you're escaping it for a query (or prepared statements OR stored procs) and when handling that data, escape it properly for being sent to a downstream web service/command line/etc or when re-presenting that data to a user (html/javascript/actionscript/etc)

Now that I have the obligatory piece out of the way, both libraries are used for very different things. A major design goal for ESAPI is that it is designed to help secure applications that were unlucky enough to be designed without security mechanisms from the very beginning. For example it pre-packages techniques encoding data for SQL injection, that perhaps can't be immediately rewritten as parameterized queries or stored procedures due to complexity/time constraints/etc. Hibernate however was designed as a JPA implementation (as you indicated), and reference to the JSR specification will shine some light on Hibernate's implementation:

Validating data is a common task that occurs throughout an application, from the presentation layer to the persistence layer. Often the same validation logic is implemented in each layer, proving to be time consuming and error-prone. To avoid duplication of these validations in each layer, developers often bundle validation logic directly into the domain model, cluttering domain classes with validation code that is, in fact, metadata about the class itself.

This is clearly for handling domain-layer validation, and I get the sneaky suspicion that Hibernate is really providing some convenience methods at the wrong layer of the application--possibly where a bad application design is passing domain objects all the way from the Dao layer to the presentation layer. You shouldn't be cleaning or punting possible HTML in your Domain model. You should be punting it at the Controller/Service layer where you're initially pulling data from the HttpRequest object. Once the data is validated, transform the data into a Domain object where you're going to pass it to the back end. Also, even with Hibernate @SafeHtml doesn't protect you against javascript attacks if/when that data is legal javascript but not legal HTML. This is why output escaping is 100x more important than input filtering.

Answering your first question:

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

1. First and foremost, "@SafeHtml" in Hibernate isn't part of the JSR 303 specification, so by using it you're tying your JPA implementation directly to Hibernate. This harms maintenance.
2. ESAPI's validator provides you with the ability to alter validations via validator.properties which means that you can handle business problems in production without having to go to development to create a whole new build as currently happens in the annotation-driven model.
3. ESAPI's validator was designed, written, and tested by security experts.
4. This is the most important thing: ESAPI gives you the ESAPI.encoder().canonicalize() method which is used implicitly in any of ESAPI's Validator.getValidHtml(args...) calls. This method by itself allows you to determine whether or not someone is trying a multiple-encoding attack against your application. A similar call does not exist in any other Java security library I am aware of, definitely not in Hibernate's validator implementation--and I would never expect Hibernate to have that call since its a Domain library.

4 cannot be overstated in importance since multiple encoding attacks is how most XSS gets injected into applications in the wild. This forces all input to at most, be singly-URL encoded, and allows you to identify immediately a user attempting to enter such input into the application.

ESAPI does have a major drawback. As of fall 2014 it lost flagship status at OWASP due to stagnant community development. Time will tell if the ball starts rolling with ESAPI 3.0.