<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>As I indicated, any kind of multiple encoding, whether it is the same encoding applied more than once, more than one encoding scheme, or any nested encoding clearly indicates an attack (or possibly a bad user mistake not worth processing).</div><div><br></div><div>Of course if you expect encoded data, then don't canonicalize. That's why there's a way to override the default behavior.<br><br>--Jeff<div><br></div></div><div><br>On Aug 30, 2014, at 12:39 PM, Jim Manico <<a href="mailto:jim.manico@owasp.org">jim.manico@owasp.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>So what is the line drawn between an attack and acceptably encoded data in ESAPI?</div><div><br></div><div>Canonicalization also "breaks" some input types (html, json, etc) so canonicalization of •all• input is equally idiotic. (which is why all of ESAPI's IV functions can disable canonicalization)</div>
<div><br></div><div><div>--</div><div>Jim Manico</div><div>@Manicode</div><div>(808) 652-3805</div></div><div><br>On Aug 30, 2014, at 5:07 AM, Jeff Williams <<a href="mailto:jeff.williams@aspectsecurity.com">jeff.williams@aspectsecurity.com</a>> wrote:<br>
<br></div><blockquote type="cite"><div>

<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">


<div>There are many situations in which apps get encoded data that does not represent an attack. However, any kind of multiply encoded data is clearly an attack.  So the line we drew in ESAPI is, I think, the right one. We only throw an intrusion detection
 whenever there is absolutely a clear attack.  Otherwise we clean up and try to make the data work.</div>
<div><br>
</div>
<div>Turning off canonicalization, for the vast majority of inputs would be idiotic.  You simply can't reliably validate encoded data. If you follow this plan, the only CVE you will need to worry about is "Canonicalize, Validate, Escape"<br>

<br>
--Jeff
<div><br>
</div>
</div>
<div><br>
On Aug 30, 2014, at 3:22 AM, "Fabio Cerullo" <<a href="mailto:fcerullo@gmail.com">fcerullo@gmail.com</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>Hi
<div><br>
</div>
<div>What about someone who "needs" encoded data to be accepted by the webapp?</div>
<div><br>
</div>
<div>For example, a web form with a field that is used for completion percentage of something. So in that field you could input "80% complete". </div>
<div><br>
</div>
<div>That would be a legit case of canonicalise first, and then validate because that value needs to be stored as it is.</div>
<div><br>
</div>
<div>I believe the approach taken by ESAPI is: treat everything as potentially malicious, canonicalise just in case, and then validate  all entries.</div>
<div><br>
</div>
<div>Otherwise, how would you differentiate between an attack and a valid entry in example above? </div>
<div><br>
</div>
<div>Fabio<span></span><br>
<br>
On Friday, August 29, 2014, Jim Manico <<a href="mailto:jim.manico@owasp.org">jim.manico@owasp.org</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto">
<div>Or even better, if encoded data is detected, even if things like %80 get rejected, I prefer to reject right then and there. Pretty sure we Cannonicalize before we validate though, what code are you looking at?</div>

<div><br>
</div>
<div>Aloha,<br>
<div>--</div>
<div>Jim Manico</div>
<div>@Manicode</div>
<div>(808) 652-3805</div>
</div>
<div><br>
On Aug 29, 2014, at 6:26 AM, Matt Seil <<a href="javascript:_e(%7B%7D,'cvml','mseil@acm.org');" target="_blank">mseil@acm.org</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">
<div>
<div>
<div>
<div>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()
<i>after</i> validation and meant to ask why we would want that approach.  <br>
</div>
<div><br>
</div>
</div>
</div>
<br>
</div>
<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Aug 27, 2014 at 6:51 PM, Jim Manico <span dir="ltr">
<<a href="javascript:_e(%7B%7D,'cvml','jim.manico@owasp.org');" target="_blank">jim.manico@owasp.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">ESAPI community,<br>
<br>
I am very concerned about the design of the ESAPI validation layer and how it handles canonicalization for API's like:<br>
<br>
<code style="color:rgb(0,0,0);font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255)"><b><a href="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" target="_blank">isValidInput</a></b>(java.lang.String context,
 java.lang.String input, java.lang.String type, int maxLength, boolean allowNull)</code><span style="color:rgb(0,0,0);font-family:Times;font-size:medium;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;display:inline!important;float:none;background-color:rgb(255,255,255)"><span>
</span></span><br>
<br>
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.
<a href="http://owasp-esapi-java.googlecode.com/svn/trunk/src/main/java/org/owasp/esapi/reference/validation/StringValidationRule.java" target="_blank">
http://owasp-esapi-java.googlecode.com/svn/trunk/src/main/java/org/owasp/esapi/reference/validation/StringValidationRule.java</a><br>
<br>
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?<br>
<br>
Aloha,<br>
Jim<br>
<br>
PS: You certainly can disable canonicalization as it stands today via:<br>
<br>
  <code style="color:rgb(0,0,0);font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255)">
<b><a href="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" target="_blank">isValidInput</a></b>(java.lang.String context,
 java.lang.String input, java.lang.String type, int maxLength, boolean allowNull,
<u><b>boolean canonicalize</b></u>)</code><span style="color:rgb(0,0,0);font-family:Times;font-size:medium;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;display:inline!important;float:none;background-color:rgb(255,255,255)"><span>
</span></span><br>
<br>
</div>
<br>
_______________________________________________<br>
Esapi-dev mailing list<br>
<a href="javascript:_e(%7B%7D,'cvml','Esapi-dev@lists.owasp.org');" target="_blank">Esapi-dev@lists.owasp.org</a><br>
<a href="https://lists.owasp.org/mailman/listinfo/esapi-dev" target="_blank">https://lists.owasp.org/mailman/listinfo/esapi-dev</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<div dir="ltr">
<div>Matt Seil<br>
Software Engineer<br>
</div>
ACM/IEEE<br>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>Esapi-user mailing list</span><br>
<span><a href="mailto:Esapi-user@lists.owasp.org">Esapi-user@lists.owasp.org</a></span><br>
<span><a href="https://lists.owasp.org/mailman/listinfo/esapi-user">https://lists.owasp.org/mailman/listinfo/esapi-user</a></span><br>
</div>
</blockquote>


</div></blockquote>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Esapi-dev mailing list</span><br><span><a href="mailto:Esapi-dev@lists.owasp.org">Esapi-dev@lists.owasp.org</a></span><br><span><a href="https://lists.owasp.org/mailman/listinfo/esapi-dev">https://lists.owasp.org/mailman/listinfo/esapi-dev</a></span><br></div></blockquote></body></html>