[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [WEB SECURITY] False Positives with .NET's Request Validation?
- From: "Arian J. Evans" <arian.evans@xxxxxxxxxxxxxx>
- Subject: Re: [WEB SECURITY] False Positives with .NET's Request Validation?
- Date: Tue, 31 Jul 2007 12:49:07 -0700
------=_Part_40625_24449663.1185911347641
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Nah; that's really not a good example at all.
For instance -- it commonly won't trigger on those unless there is a leading
double-quote.
It's best to get some hands-on with this stuff to really understand it.
See my previous post for some other ideas on how to *measure* this.
-ae
On 7/31/07, James Landis <jcl24@cornell.edu> wrote:
>
> A common example of an app with false positives (sorry, I have no
> statistics) would be a financial application that is accepting custom
> business rules from the client (e.g. "less than" interpretation of
> "<"). Fortunately, it's possible to turn off the validator on a
> per-page or per-service basis. However, I agree that it's pretty rare
> to run into a false positive.
>
> -j
>
> On 7/30/07, Arian J. Evans <arian.evans@anachronic.com> wrote:
> > 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
> > >
> > >
> >
> >
>
--
Arian Evans
software security stuff
------=_Part_40625_24449663.1185911347641
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
<div>Nah; that's really not a good example at all.</div>
<div> </div>
<div>For instance -- it commonly won't trigger on those unless there is a leading double-quote.</div>
<div> </div>
<div>It's best to get some hands-on with this stuff to really understand it.</div>
<div> </div>
<div>See my previous post for some other ideas on how to *measure* this.</div>
<div> </div>
<div>-ae<br><br> </div>
<div><span class="gmail_quote">On 7/31/07, <b class="gmail_sendername">James Landis</b> <<a href="mailto:jcl24@cornell.edu";>jcl24@cornell.edu</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">A common example of an app with false positives (sorry, I have no<br>statistics) would be a financial application that is accepting custom
<br>business rules from the client (e.g. "less than" interpretation of<br>"<"). Fortunately, it's possible to turn off the validator on a<br>per-page or per-service basis. However, I agree that it's pretty rare
<br>to run into a false positive.<br><br>-j<br><br>On 7/30/07, Arian J. Evans <<a href="mailto:arian.evans@anachronic.com";>arian.evans@anachronic.com</a>> wrote:<br>> Hey David -- It's basically a big, bad, massive black-list.
<br>><br>> It'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'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'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>><br>> On 7/30/07, David Felio <<a href="mailto:david@ark.org";>david@ark.org</a>> wrote:
<br>> > After years of being in the LAMP stack, I'm now having to turn my<br>> > attention to some .NET development. One of the items I am looking at<br>> > is .NET'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't think of an instance where a < or a > would be
<br>> > supplied during intended use. HTML entities, however, will be<br>> > submitted.)<br>> ><br>> > Thanks.<br>> ><br>> > David<br>> ><br>> ><br>><br>><br></blockquote>
</div><br><br clear="all"><br>-- <br>Arian Evans<br>software security stuff
------=_Part_40625_24449663.1185911347641--
Brought to you by http://www.webappsec.org
Search this site
|