[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [WEB SECURITY] XSS/injection/... evading technique
- From: "Arshan Dabirsiaghi" <arshan.dabirsiaghi@xxxxxxxxxxxxxxxxxx>
- Subject: RE: [WEB SECURITY] XSS/injection/... evading technique
- Date: Thu, 24 Jul 2008 18:42:43 -0400
------_=_NextPart_001_01C8EDDE.95B13380
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
I agree with a lot of what you both are saying. Just a few notes. First, =
ColdFusion and HTML comments are not identical:
=20
HTML =3D <!-- comment -->
CFML =3D <!--- comment --->
=20
Though I guess it could be said accurately that all CFML comments can =
be, pattern-matching wise, considered subsets of the HTML comments.
=20
> which are often
> legitimate (for example, they're used to wrap JSON objects).
=20
While that may be true, why on earth would untrusted users be allowed to =
be submitting HTML comments or submitting JSON objects that need to be =
depantsed before processing? As an author of a rich content validation =
tool, I can say that this is categorically a bad idea. Consider the IE5+ =
XSS vector:=20
=20
<!--[if gte IE 4]>
<SCRIPT>alert('XSS');</SCRIPT>
<![endif]-->
=20
> The dumber and more broad-reaching a WAF filter is, the more likely =
it>
> is to cause problems with false positives, and subsequently be turned
> off.
=20
Agree 100%.
=20
> You don't need to execute it, but you certainly need to parse it to
> determine what will actually be interpreted as a comment and what
> won't.
=20
Disagree. Reliable parsing inevitably means slow execution time and =
still not 100% security, sounds like a non-starter for a WAF.
=20
My question is this: are the WAF people paying attention to PHPIDS's =
Centrifuge (obligatory comment about how nothing is 100% reliable)? I =
think that's the direction WAFs should be headed, and who knows, maybe =
they're already there. I fully expect that they already claim to be. =
=3D)
=20
Cheers,
Arshan
________________________________
From: Jon McClintock [mailto:jammer@weak.org]
Sent: Thu 7/24/2008 4:59 PM
To: Arian J. Evans
Cc: Nick Gearls; websecurity@webappsec.org
Subject: Re: [WEB SECURITY] XSS/injection/... evading technique
On Thu, Jul 24, 2008 at 01:35:02PM -0700, Arian J. Evans wrote:
> On Thu, Jul 24, 2008 at 10:19 AM, Jon McClintock <jammer@weak.org> =
wrote:
> > This is a challenging problem to solve, and you're not going to be =
able
> > to address it with any pattern-based engine. To do it properly, you =
need
> > to actually parse the input in the same manner that it will be =
consumed.
>
> Why? Please support this contention.
>
> I see a p@/**<!-->**/attern here. Or two. Or three.
Nesting, linearity, unintended consequences. One consumer's perfectly
valid string is dangerous and unsafe in another.
output=3D"sc/*";benign=3Dtrue;foo=3D"*/ript";
Your WAF doesn't know all of the contexts the data will be used in. If
you blindly remove all things that look like comments in all
environments, you're going to break a lot of cases where something that
looks like a comment is a valid input.
message=3D"Meet me@noon"
The dumber and more broad-reaching a WAF filter is, the more likely it
is to cause problems with false positives, and subsequently be turned
off.
> > Further, you'd be best served by using the same parsing engine that =
your
> > application is using, otherwise you'll likely run into edge cases.
>
> Why? We do not need to successfully execute the code or interpret it
> to block it.
You don't need to execute it, but you certainly need to parse it to
determine what will actually be interpreted as a comment and what
won't.
> > For XML data, this is straightforward, as most WAFs implement XML
> > validation, translation and filtering. For things like JavaScript or
> > (worse) ColdFusion, you're running far beyond the bounds of what a
> > WAF's parser can reasonably implement.
>
> Why?
>
> And how is ColdFusion worse than Javascript in terms of WAF-able
> issues? You lost me on that last bit.
ColdFusion comments are identical to HTML comments. Which are often
legitimate (for example, they're used to wrap JSON objects).
-Jon
------_=_NextPart_001_01C8EDDE.95B13380
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<HTML dir=3Dltr><HEAD><TITLE>Re: [WEB SECURITY] XSS/injection/... =
evading technique</TITLE>=0A=
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dunicode">=0A=
<META content=3D"MSHTML 6.00.6001.18063" name=3DGENERATOR></HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText96673 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>I agree with =
a lot of what you both are saying. Just a few notes. First, ColdFusion =
and HTML comments are not identical:</FONT></DIV></DIV>=0A=
<DIV dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT> </DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>HTML =3D <!-- comment =
--></FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>CFML =3D <!--- comment =
---></FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT> </DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Though I guess it could be =
said accurately that all CFML comments can be, pattern-matching wise, =
considered subsets of the HTML comments.</FONT></DIV>=0A=
<DIV dir=3Dltr> </DIV>=0A=
<DIV dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT size=3D2>> which are often</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT size=3D2>> legitimate (for example, they're used =
to wrap JSON objects).</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT size=3D2></FONT> </DIV></DIV></DIV>=0A=
<DIV dir=3Dltr>While that may be true, why on earth would untrusted =
users be allowed to be submitting HTML comments or submitting JSON =
objects that need to be depantsed before processing? As an author of a =
rich content validation tool, I can say that this is categorically a bad =
idea. Consider the IE5+ XSS vector: </DIV>=0A=
<DIV dir=3Dltr> </DIV>=0A=
<DIV dir=3Dltr><!--[if gte IE =
4]><BR><SCRIPT>alert('XSS');</SCRIPT><BR><![endif]-->=
;</DIV>=0A=
<DIV dir=3Dltr> </DIV>=0A=
<DIV dir=3Dltr><FONT size=3D2>> The dumber and more broad-reaching a =
WAF filter is, the more likely it><BR>> is to cause problems with =
false positives, and subsequently be turned<BR>> off.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT size=3D2></FONT> </DIV>=0A=
<DIV dir=3Dltr><FONT size=3D2>Agree 100%.</FONT></DIV>=0A=
<DIV dir=3Dltr> </DIV>=0A=
<DIV dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT size=3D2>> You don't need to execute it, but you =
certainly need to parse it to<BR>> determine what will actually be =
interpreted as a comment and what<BR>> won't.</FONT></DIV><FONT =
size=3D2></FONT></DIV>=0A=
<DIV dir=3Dltr><FONT size=3D2></FONT><FONT size=3D2></FONT> </DIV>=0A=
<DIV dir=3Dltr><FONT size=3D2>Disagree. Reliable parsing inevitably =
means slow execution time and still not 100% security, sounds like a =
non-starter for a WAF.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT size=3D2></FONT> </DIV>=0A=
<DIV dir=3Dltr><FONT size=3D2>My question is this: are the WAF people =
paying attention to PHPIDS's Centrifuge (obligatory comment about how =
nothing is 100% reliable)? I think that's the direction WAFs should be =
headed, and who knows, maybe they're already there. I fully expect that =
they already claim to be. =3D)</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT size=3D2></FONT> </DIV>=0A=
<DIV dir=3Dltr><FONT size=3D2>Cheers,</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT size=3D2>Arshan</FONT></DIV>=0A=
<DIV dir=3Dltr><BR></DIV>=0A=
<DIV dir=3Dltr>=0A=
<HR tabIndex=3D-1>=0A=
</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DTahoma size=3D2><B>From:</B> Jon McClintock =
[mailto:jammer@weak.org]<BR><B>Sent:</B> Thu 7/24/2008 4:59 =
PM<BR><B>To:</B> Arian J. Evans<BR><B>Cc:</B> Nick Gearls; =
websecurity@webappsec.org<BR><B>Subject:</B> Re: [WEB SECURITY] =
XSS/injection/... evading technique<BR></FONT><BR></DIV>=0A=
<DIV>=0A=
<P><FONT size=3D2>On Thu, Jul 24, 2008 at 01:35:02PM -0700, Arian J. =
Evans wrote:<BR>> On Thu, Jul 24, 2008 at 10:19 AM, Jon McClintock =
<jammer@weak.org> wrote:<BR>> > This is a challenging =
problem to solve, and you're not going to be able<BR>> > to =
address it with any pattern-based engine. To do it properly, you =
need<BR>> > to actually parse the input in the same manner that it =
will be consumed.<BR>><BR>> Why? Please support this =
contention.<BR>><BR>> I see a p@/**<!-->**/attern here. Or =
two. Or three.<BR><BR>Nesting, linearity, unintended consequences. One =
consumer's perfectly<BR>valid string is dangerous and unsafe in =
another.<BR><BR> =
output=3D"sc/*";benign=3Dtrue;foo=3D"*/ript";<BR><BR>Your WAF doesn't =
know all of the contexts the data will be used in. If<BR>you blindly =
remove all things that look like comments in all<BR>environments, you're =
going to break a lot of cases where something that<BR>looks like a =
comment is a valid input.<BR><BR> message=3D"Meet =
me@noon"<BR><BR>The dumber and more broad-reaching a WAF filter is, the =
more likely it<BR>is to cause problems with false positives, and =
subsequently be turned<BR>off.<BR><BR>> > Further, you'd be best =
served by using the same parsing engine that your<BR>> > =
application is using, otherwise you'll likely run into edge =
cases.<BR>><BR>> Why? We do not need to successfully execute the =
code or interpret it<BR>> to block it.<BR><BR>You don't need to =
execute it, but you certainly need to parse it to<BR>determine what will =
actually be interpreted as a comment and what<BR>won't.<BR><BR>> > =
For XML data, this is straightforward, as most WAFs implement =
XML<BR>> > validation, translation and filtering. For things like =
JavaScript or<BR>> > (worse) ColdFusion, you're running far beyond =
the bounds of what a<BR>> > WAF's parser can reasonably =
implement.<BR>><BR>> Why?<BR>><BR>> And how is ColdFusion =
worse than Javascript in terms of WAF-able<BR>> issues? You lost me =
on that last bit.<BR><BR>ColdFusion comments are identical to HTML =
comments. Which are often<BR>legitimate (for example, they're used to =
wrap JSON =
objects).<BR><BR>-Jon<BR></FONT></P></DIV></BODY><!--[object_id=3D#aspect=
security.com#]--></HTML>
------_=_NextPart_001_01C8EDDE.95B13380--
Brought to you by http://www.webappsec.org
Search this site
|