Re: [WEB SECURITY] False Positives with .NET's Request Validation?

["Arian J. Evans" <arian.evans@xxxxxxxxxxxxxx>]

------=_Part_30743_4590862.1185845254483
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hey David -- It's basically a big, bad, massive black-list.

It's pretty well written. About the only blacklist outside of a few WAFs
that works *fairly* well, at least on the newest versions (.NET 3.0).

Due to this, the behavior shouldn't bork up *normal* data types.

However, if you have doubts, pull apart the code for the relevant parts
of the http.request name space using reflector and have a look for
yourself. That's how I found a couple of new ways to pad javascript
that could bypass the regex and still be parsed by IE:

http://www.aisto.com/roeder/dotnet/

Parts of it are a headache, for sure, but that should tell you what
you want to know *explicitly*.

-- 
Arian Evans
software security stuff

On 7/30/07, David Felio <david@ark.org> wrote:
>
> After years of being in the LAMP stack, I'm now having to turn my
> attention to some .NET development. One of the items I am looking at
> is .NET's built-in request validation. I know there have been several
> examples of how to bypass it and I have already told our developers
> to not rely on it, but I am now more interested in false positives
> than false negatives. Does anyone have any stats on how accurate the
> Request Validation is with regard to false positives? Is having it on
> going to end up being a thorn in my side, or is it tuned enough that
> false positives are exceedingly rare? (I realize this last question
> is dependent on the data expected. In the particular application I am
> concerned about at the moment, there should be no HTML, XML, JS, etc.
> In fact, I can't think of an instance where a < or a > would be
> supplied during intended use. HTML entities, however, will be
> submitted.)
>
> Thanks.
>
> David
>
>

------=_Part_30743_4590862.1185845254483
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hey David -- It&#39;s basically a big, bad, massive black-list.<br><br>It&#39;s pretty well written. About the only blacklist outside of a few WAFs<br>that works *fairly* well, at least on the newest versions (.NET 3.0).<br>
<br>Due to this, the behavior shouldn&#39;t bork up *normal* data types.<br><br>However, if you have doubts, pull apart the code for the relevant parts<br>of the http.request name space using reflector and have a look for
<br>yourself. That&#39;s how I found a couple of new ways to pad javascript<br>that could bypass the regex and still be parsed by IE:<br><br><a href="http://www.aisto.com/roeder/dotnet/";>http://www.aisto.com/roeder/dotnet/
</a><br><br>Parts of it are a headache, for sure, but that should tell you what<br>you want to know *explicitly*.<br><br>-- <br>Arian Evans<br>software security stuff
<br><br><div><span class="gmail_quote">On 7/30/07, <b class="gmail_sendername">David Felio</b> &lt;<a href="mailto:david@ark.org";>david@ark.org</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
After years of being in the LAMP stack, I&#39;m now having to turn my<br>attention to some .NET development. One of the items I am looking at<br>is .NET&#39;s built-in request validation. I know there have been several<br>
examples of how to bypass it and I have already told our developers<br>to not rely on it, but I am now more interested in false positives<br>than false negatives. Does anyone have any stats on how accurate the<br>Request Validation is with regard to false positives? Is having it on
<br>going to end up being a thorn in my side, or is it tuned enough that<br>false positives are exceedingly rare? (I realize this last question<br>is dependent on the data expected. In the particular application I am<br>concerned about at the moment, there should be no HTML, XML, JS, etc.
<br>In fact, I can&#39;t think of an instance where a &lt; or a &gt; would be<br>supplied during intended use. HTML entities, however, will be<br>submitted.)<br><br>Thanks.<br><br>David<br><br></blockquote></div><br>

------=_Part_30743_4590862.1185845254483--