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

Tue Sep 2 18:38:53 UTC 2014

It looks like validation is happening before /*and after*/ 
cannonicalization if you enable cannonicalization.

public String getValid( String context, String input ) throws ValidationException
	{
		String data = null;

		// checks on input itself

		// check for empty/null
		if(checkEmpty(context, input) == null)
			return null;

		if (validateInputAndCanonical)
		{
			//first validate pre-canonicalized data

			// check length
			checkLength(context, input);

			// check whitelist patterns
			checkWhitelist(context, input);

			// check blacklist patterns
			checkBlacklist(context, input);

			// canonicalize
			data = encoder.canonicalize( input );

		} else {

			//skip canonicalization
			data = input;			
		}

		// check for empty/null
		if(checkEmpty(context, data, input) == null)
			return null;

		// check length
		checkLength(context, data, input);

		// check whitelist patterns
		checkWhitelist(context, data, input);

		// check blacklist patterns
		checkBlacklist(context, data, input);

		// validation passed
		return data;
	}

There is also an option to disable strict mode (ESAPI throws 
IntrusionDetection if anything is double-encoded right now).

Although ESAPI is able to canonicalize multiple, mixed, or nested 
encoding, it's safer to not accept this stuff in the first place. In 
ESAPI, the default is "strict" mode that throws an IntrusionException if 
it receives anything not single-encoded with a single scheme. This is 
configurable in ESAPI.properties using the properties:

  Encoder.AllowMultipleEncoding=false
  Encoder.AllowMixedEncoding=false

What I'm looking for is a STRICTER mode that throws an intrusion detection anytime **anything** is encoded. It looks easy to build as a utility on my own, I'm all set.

Aloha,
Jim

On 8/30/14, 9:10 PM, Bedirhan Urgun wrote:
> the inner getValid reference method applies length, whitelist and 
> blacklist patterns on the "pre-canonicalized" input if the developer 
> wants canonicalization, however, that's not the end. As the method 
> continues, same controls also get applied on the canonicalized input 
> and then the method returns the validated data. That being said, I 
> don't know why it is implemented this way, but defence in depth seems 
> to be a reasonable principle for the security perspective.
>
> http://owasp-esapi-java.googlecode.com/svn/trunk/src/main/java/org/owasp/esapi/reference/validation/StringValidationRule.java
>
>
>
> 2014-08-29 19:26 GMT+03:00 Matt Seil <mseil at acm.org 
> <mailto:mseil at acm.org>>:
>
>     In the context of your question Jim, I think it makes more sense
>     to canonicalize BEFORE you validate--not the other way around.  I
>     noticed too, that all the "getValidInput" methods call
>     Encoder.canonicalize() /after/ validation and meant to ask why we
>     would want that approach.
>
>
>
>
>
>     On Wed, Aug 27, 2014 at 6:51 PM, Jim Manico <jim.manico at owasp.org
>     <mailto:jim.manico at owasp.org>> wrote:
>
>         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*_)|
>
>
>         _______________________________________________
>         Esapi-dev mailing list
>         Esapi-dev at lists.owasp.org <mailto:Esapi-dev at lists.owasp.org>
>         https://lists.owasp.org/mailman/listinfo/esapi-dev
>
>
>
>
>     -- 
>     Matt Seil
>     Software Engineer
>     ACM/IEEE
>
>     _______________________________________________
>     Esapi-dev mailing list
>     Esapi-dev at lists.owasp.org <mailto:Esapi-dev at lists.owasp.org>
>     https://lists.owasp.org/mailman/listinfo/esapi-dev
>
>
>
>
> -- 
>
> bedirhan urgun

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