[Esapi-user] Canonicalization and ESAPI's Input Validation Layer

Jim Manico jim.manico at owasp.org
Wed Aug 27 23:51:46 UTC 2014


ESAPI community,

I am very concerned about the design of the ESAPI validation layer and 
how it handles canonicalization for API's like:

|*isValidInput 
<https://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/reference/DefaultValidator.html#isValidInput%28java.lang.String,%20java.lang.String,%20java.lang.String,%20int,%20boolean%29>*(java.lang.String context, 
java.lang.String input, java.lang.String type, int maxLength, 
boolean allowNull)|

Right now, before validation, ESAPI will try to decode user input to 
it's normalized form and THEN it will try to validate the input. 
http://owasp-esapi-java.googlecode.com/svn/trunk/src/main/java/org/owasp/esapi/reference/validation/StringValidationRule.java

This seems rather dangerous in that encoded attacks will be "fixed" and 
will not alert of potential malicious input. If input is detected to be 
encoded, then I would suggest that we throw an 
IntrusionDetectionException and stop processing. Why do we "clean up" 
encoded data and then validate in these API's?

Aloha,
Jim

PS: You certainly can disable canonicalization as it stands today via:

|*isValidInput 
<https://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/reference/DefaultValidator.html#isValidInput%28java.lang.String,%20java.lang.String,%20java.lang.String,%20int,%20boolean,%20boolean%29>*(java.lang.String context, 
java.lang.String input, java.lang.String type, int maxLength, 
boolean allowNull, _*boolean canonicalize*_)|

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/esapi-user/attachments/20140827/036b54d3/attachment.html>


More information about the Esapi-user mailing list