I have been asked to add some input validation in all of our REST endpoints. We have two custom validation constraints in our system, wrapping around the ESAPI library; one for String, wrapping #isValidInput and one for Long, wrapping #isValidNumber.
ESAPI's #isValidNumber seems to simply check the number's min and max value (something that I can simply do with JSR-303 @Min / @Max). Are there any added benefits for using the ESAPI library or can I simply remove the custom constraint and add the bean validation annotations?
I do agree that we need the String canonicalization provided by ESAPI, but for the numbers I'm a bit sceptical.
Are there any added benefits for using the ESAPI library or can I simply remove the custom constraint and add the bean validation annotations?
In short, yes. If you notice the last parameter in the call to #isValidInput you linked is whether to turn canonicalization on or off. If your application turned it off, the only benefit ESAPI will give you is to outsource your validation regex into validation.properties, where if a prod issue arose, you could change the value and restart the server, saving an application build and deployment. JSR-303 will require a recompile and a deployment.
If however you've left canonicalization on, ESAPI provides one thing that I haven't found in another Java security library to date, which is the ability to detect mixed encoding and multiple encoding on a given input string. From a forensics and incident response perspective, this is ultra-useful as we can tell if our web application is being attacked in real-time, as well as record and audit information about the user performing it.
^^^You seem to know all of this by your last statement. I haven't seen a web container that didn't pass in Strings
for numbers. My guess is that you're pulling it from request.getParameter("foo");
which means its a string and you still want the defense provided by canonicalize. Even if it might get caught by a parse exception on the conversion to Integer
or Long
, there's also the risk of overflow or underflow which could perturb your application in a different way.