[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[WEB SECURITY] RE: [Webappsec] [WEB SECURITY] Re: Comparisons of Web ApplicationFirewalls
- From: "Arshan Dabirsiaghi" <arshan.dabirsiaghi@xxxxxxxxxxxxxxxxxx>
- Subject: [WEB SECURITY] RE: [Webappsec] [WEB SECURITY] Re: Comparisons of Web ApplicationFirewalls
- Date: Mon, 7 Jul 2008 12:30:48 -0400
------_=_NextPart_001_01C8E04E.CFF55C76
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Ernest,
=20
In the interest of making things clear, I'm going to seperate the two =
issues you have with WAFs:
=20
1) The WAF doesn't work (crashes, doesn't block anything, etc.)
2) Lack of i18n in whitelisting rules
=20
Considering #1, this is pretty inexcusable for a WAF product that should =
be relatively mature by this point.
=20
However, I totally concur with you on #2, and its much bigger than =
people think. I also don't think there's any good documentation on this =
subject out there in the real world (besides the little post from Matt). =
=20
Being a guy that has shown a slide or 3 with the string "[a-zA-Z0-9]" on =
it, I realize it may not work for your company, but it's more the =
technique that we're trying to get across rather than any specific =
implementation.
=20
You should investigate standardized Unicode patterns like \p{L} and =
\p{N} which are extremely useful for doing cross-language input =
validation without getting deep into the weeds of Unicode character =
ranges [1]. You can also validate the data you're receiving against the =
locale you're receiving it from. For instance, \p{Greek} will tell you =
whether or not your letters are in the Greek character range.
=20
I can't say whether or not any WAF out there has this kind of capability =
(the few I've seen do not).
=20
Regarding the backwards languages - won't the attacks have to be in the =
normal direction to work anyway? =3D]
=20
Cheers,
Arshan
=20
[1] http://unicode.org/unicode/reports/tr18/
=20
=20
________________________________
From: webappsec-bounces@lists.owasp.org on behalf of Ernest Mueller
Sent: Mon 7/7/2008 11:29 AM
To: Martin O'Neal
Cc: websecurity@webappsec.org; webappsec @OWASP; =
webappsec-bounces@lists.owasp.org
Subject: Re: [Webappsec] [WEB SECURITY] Re: Comparisons of Web =
ApplicationFirewalls
Although I think WAFs do have an important role especially when =
confronted
by a mass of untrained/indifferent IT programmers tossing stuff on a Web
site (as in our case), I'd like to note that Martin brings out one =
severe
problem below - multiple locale support.
All of the security community "whitelisting is a best practice" business
pretty much hasn't kept up with the times; our site is available in =
eight
languages fully and has parts in others, including dual-byte and
"backwards" like Arabic and Hebrew. Every time some security guy does a
presentation at us that starts off with "regexps to include [a-zA-Z1-9]" =
I
think to myself "bah" and tune them out the rest of the time.
So note to WAF vendors, and people working on things like
Stinger/mod_security, the problem has become much more complex and your
products are only useful to the degree they don't lag behind how people =
are
using the Web nowadays.
Frankly, though I believe in the theoretical usefulness of a WAF, we =
don't
have one yet. We did one round of evals, where we basically decided to
pass at the time because nothing was compelling (this was before F5 and
Netscalar integrated theirs) and then we did another round of evals
recently, where we also decided to cancel the project and do it again in =
a
year hoping that the products would get better. Not naming names, but =
the
major dedicated product we evalled crashed all the time and the supplier
was unable to resolve that, and the other major product that was on a =
load
balancer didn't block jack (we tested with Watchfire). We decided with
the PCI push on our security money this year could more effectively be
spent in other areas.
Which is sad because we'd really like one to work. Our site has more =
than
a hundred Web applications on it. We work to harden the more important
ones, but no one is willing to take the time to manually characterize
inputs etc. on the lesser ones especially the 50% of apps that are not
under active feature development.
Ernest
______________________
UN-altered REPRODUCTION and DISSEMINATION of
this IMPORTANT information is ENCOURAGED.
=
=20
"Martin O'Neal" =
=20
<martin.oneal@cor =
=20
saire.com> =
To
Sent by: "Arian J. Evans" =
=20
webappsec-bounces <arian.evans@anachronic.com> =
=20
@lists.owasp.org =
cc
"webappsec @OWASP" =
=20
<webappsec@lists.owasp.org>, =
=20
07/07/2008 05:28 websecurity@webappsec.org =
=20
AM =
Subject
Re: [Webappsec] [WEB SECURITY] =
Re:=20
Comparisons of Web Application =
=20
Firewalls =
=20
=
=20
=
=20
=
=20
=
=20
=
=20
=
=20
> Actually, statistically speaking:
> we do know the problem exists Martin.
LOL; that's not what I meant! Because of where a WAF sits in the mix,
the only tool it has at its disposal is data validation. Which means
that when you apply it to the most emotive web app issues of the day,
SQL injection and XSS (which are encoding failures, not validation
failures) it is trying to solve a problem that simply doesn't exist.
A WAF can actually be very good at enforcing validation, when validation
is the problem. For example an application that fails creatively when
its session ID is tampered with. The session ID should be a
predictable, consistent format; safe territory for a WAF.
But (and it is a big BUTT) a WAF is generally not so useful for general
form fields in a site, where the usecase requires a non-alphanumeric
character set, like a name field. Add in multi-locale support etc, and
I would put money on it that (like my recent F5 project), it won't be
long before you have to cripple the user experience to stop the attack
you are trying to prevent.
> Now Martin, I have to go shoot off some
> guns and fireworks and celebrate my
> freedom from those oppressive Brits! :)
LOL2; we're much more reserved in our celebrations (being stuffy brits),
but trust me; it is a landmark occasion for us too. :)
Martin...
----------------------------------------------------------------------
CONFIDENTIALITY: This e-mail and any files transmitted with it are
confidential and intended solely for the use of the recipient(s) only.
Any review, retransmission, dissemination or other use of, or taking
any action in reliance upon this information by persons or entities
other than the intended recipient(s) is prohibited. If you have
received this e-mail in error please notify the sender immediately
and destroy the material whether stored on a computer or otherwise.
----------------------------------------------------------------------
DISCLAIMER: Any views or opinions presented within this e-mail are
solely those of the author and do not necessarily represent those
of Corsaire Limited, unless otherwise specifically stated.
----------------------------------------------------------------------
Corsaire Limited, registered in England No. 3338312. Registered
office: Portland House, Park Street, Bagshot, Surrey GU19 5PG.
Telephone: +44 (0)1483-746700
_______________________________________________
Webappsec mailing list
Webappsec@lists.owasp.org
https://lists.owasp.org/mailman/listinfo/webappsec
_______________________________________________
Webappsec mailing list
Webappsec@lists.owasp.org
https://lists.owasp.org/mailman/listinfo/webappsec
------_=_NextPart_001_01C8E04E.CFF55C76
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<HTML dir=3Dltr><HEAD><TITLE>Re: [Webappsec] [WEB SECURITY] Re: =
Comparisons of Web ApplicationFirewalls</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=3DidOWAReplyText81665 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 =
size=3D2>Ernest,</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT> </DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>In the =
interest of making things clear, I'm going to seperate the two =
issues you have with WAFs:</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT> </DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>1) The WAF doesn't work =
(crashes, doesn't block anything, etc.)</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>2) Lack of i18n in =
whitelisting rules</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT> </DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Considering #1, this is =
pretty inexcusable for a WAF product that should be relatively mature by =
this point.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT> </DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>However, I totally concur =
with you on #2, and its much bigger than people think. I also don't =
think there's any good documentation on this subject out there in the =
real world (besides the little post from Matt). </FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT> </DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Being a guy that has shown a =
slide or 3 with the string "[a-zA-Z0-9]" on it, I realize it may =
not work for your company, but it's more the technique that we're trying =
to get across rather than any specific implementation.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT> </DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>You should investigate =
standardized Unicode patterns like \p{L} and \p{N} which are extremely =
useful for doing cross-language input validation without getting deep =
into the weeds of Unicode character ranges [1]. You can also validate =
the data you're receiving against the locale you're receiving it from. =
For instance, \p{Greek} will tell you whether or not your letters are in =
the Greek character range.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT> </DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>I can't say whether or not =
any WAF out there has this kind of capability (the few I've seen do =
not).</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT> </DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Regarding the backwards =
languages - won't the attacks have to be in the normal direction to work =
anyway? =3D]</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT> </DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Cheers,</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Arshan</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT> </DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>[1] <A =
href=3D"http://unicode.org/unicode/reports/tr18/";>http://unicode.org/unic=
ode/reports/tr18/</A></FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT> </DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT> </DIV></DIV>=0A=
<DIV dir=3Dltr><BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>From:</B> =
webappsec-bounces@lists.owasp.org on behalf of Ernest =
Mueller<BR><B>Sent:</B> Mon 7/7/2008 11:29 AM<BR><B>To:</B> Martin =
O'Neal<BR><B>Cc:</B> websecurity@webappsec.org; webappsec @OWASP; =
webappsec-bounces@lists.owasp.org<BR><B>Subject:</B> Re: [Webappsec] =
[WEB SECURITY] Re: Comparisons of Web =
ApplicationFirewalls<BR></FONT><BR></DIV>=0A=
<DIV>=0A=
<P><FONT size=3D2>Although I think WAFs do have an important role =
especially when confronted<BR>by a mass of untrained/indifferent IT =
programmers tossing stuff on a Web<BR>site (as in our case), I'd like to =
note that Martin brings out one severe<BR>problem below - multiple =
locale support.<BR><BR>All of the security community "whitelisting is a =
best practice" business<BR>pretty much hasn't kept up with the times; =
our site is available in eight<BR>languages fully and has parts in =
others, including dual-byte and<BR>"backwards" like Arabic and =
Hebrew. Every time some security guy does a<BR>presentation at us =
that starts off with "regexps to include [a-zA-Z1-9]" I<BR>think to =
myself "bah" and tune them out the rest of the time.<BR><BR>So note to =
WAF vendors, and people working on things like<BR>Stinger/mod_security, =
the problem has become much more complex and your<BR>products are only =
useful to the degree they don't lag behind how people are<BR>using the =
Web nowadays.<BR><BR>Frankly, though I believe in the theoretical =
usefulness of a WAF, we don't<BR>have one yet. We did one round of =
evals, where we basically decided to<BR>pass at the time because nothing =
was compelling (this was before F5 and<BR>Netscalar integrated theirs) =
and then we did another round of evals<BR>recently, where we also =
decided to cancel the project and do it again in a<BR>year hoping that =
the products would get better. Not naming names, but the<BR>major =
dedicated product we evalled crashed all the time and the =
supplier<BR>was unable to resolve that, and the other major product that =
was on a load<BR>balancer didn't block jack (we tested with =
Watchfire). We decided with<BR>the PCI push on our security =
money this year could more effectively be<BR>spent in other =
areas.<BR><BR>Which is sad because we'd really like one to work. =
Our site has more than<BR>a hundred Web applications on it. We =
work to harden the more important<BR>ones, but no one is willing to take =
the time to manually characterize<BR>inputs etc. on the lesser ones =
especially the 50% of apps that are not<BR>under active feature =
development.<BR><BR>Ernest<BR>______________________<BR>UN-altered =
REPRODUCTION and DISSEMINATION of<BR>this IMPORTANT information is =
ENCOURAGED.<BR><BR><BR><BR> &nbs=
p;  =
; =
&=
nbsp; &n=
bsp; &nb=
sp; <BR> =
"Martin =
O'Neal" =
&=
nbsp; &n=
bsp; <BR> =
; =
<martin.oneal@cor  =
; =
&=
nbsp; <BR>&nbs=
p; =
saire.com> =
&=
nbsp; &n=
bsp; &nb=
sp; =
To<BR> &=
nbsp; Sent =
by: &nbs=
p; "Arian J. =
Evans" &=
nbsp; <BR> &nbs=
p; =
webappsec-bounces =
<arian.evans@anachronic.com> &nb=
sp;<BR> =
=
@lists.owasp.org &nb=
sp; &nbs=
p;  =
; =
cc<BR> &=
nbsp; &n=
bsp; &nb=
sp; "webappsec =
@OWASP" =
<BR> &nb=
sp; &nbs=
p;  =
; =
<webappsec@lists.owasp.org>, &nb=
sp;<BR> =
07/07/2008 =
05:28 =
websecurity@webappsec.org =
<BR> &nb=
sp; =
AM  =
; =
&=
nbsp; &n=
bsp; =
Subject<BR> &n=
bsp; &nb=
sp; &nbs=
p; Re: [Webappsec] [WEB SECURITY] =
Re: <BR> =
&=
nbsp; &n=
bsp; Comparisons of Web =
Application <BR> &nbs=
p;  =
; =
=
Firewalls &nbs=
p;  =
; <BR> &n=
bsp; &nb=
sp; &nbs=
p;  =
; =
&=
nbsp; <BR> &nbs=
p;  =
; =
&=
nbsp; &n=
bsp; &nb=
sp; <BR> =
&=
nbsp; &n=
bsp; &nb=
sp; &nbs=
p;  =
; <BR> &n=
bsp; &nb=
sp; &nbs=
p;  =
; =
&=
nbsp; <BR> &nbs=
p;  =
; =
&=
nbsp; &n=
bsp; &nb=
sp; <BR>=
&=
nbsp; &n=
bsp; &nb=
sp; &nbs=
p;  =
; =
<BR><BR><BR><BR><BR><BR>> Actually, statistically =
speaking:<BR>> we do know the problem exists Martin.<BR><BR>LOL; =
that's not what I meant! Because of where a WAF sits in the =
mix,<BR>the only tool it has at its disposal is data validation. =
Which means<BR>that when you apply it to the most emotive web app issues =
of the day,<BR>SQL injection and XSS (which are encoding failures, not =
validation<BR>failures) it is trying to solve a problem that simply =
doesn't exist.<BR><BR>A WAF can actually be very good at enforcing =
validation, when validation<BR>is the problem. For example an =
application that fails creatively when<BR>its session ID is tampered =
with. The session ID should be a<BR>predictable, consistent =
format; safe territory for a WAF.<BR><BR>But (and it is a big BUTT) a =
WAF is generally not so useful for general<BR>form fields in a site, =
where the usecase requires a non-alphanumeric<BR>character set, like a =
name field. Add in multi-locale support etc, and<BR>I would put =
money on it that (like my recent F5 project), it won't be<BR>long before =
you have to cripple the user experience to stop the attack<BR>you are =
trying to prevent.<BR><BR>> Now Martin, I have to go shoot off =
some<BR>> guns and fireworks and celebrate my<BR>> freedom from =
those oppressive Brits! :)<BR><BR>LOL2; we're much more reserved in our =
celebrations (being stuffy brits),<BR>but trust me; it is a landmark =
occasion for us too. =
:)<BR><BR>Martin...<BR><BR><BR>------------------------------------------=
----------------------------<BR>CONFIDENTIALITY: This e-mail and =
any files transmitted with it are<BR>confidential and intended solely =
for the use of the recipient(s) only.<BR>Any review, retransmission, =
dissemination or other use of, or taking<BR>any action in reliance upon =
this information by persons or entities<BR>other than the intended =
recipient(s) is prohibited. If you have<BR>received this e-mail in =
error please notify the sender immediately<BR>and destroy the material =
whether stored on a computer or =
otherwise.<BR>-----------------------------------------------------------=
-----------<BR>DISCLAIMER: Any views or opinions presented within =
this e-mail are<BR>solely those of the author and do not necessarily =
represent those<BR>of Corsaire Limited, unless otherwise specifically =
stated.<BR>--------------------------------------------------------------=
--------<BR>Corsaire Limited, registered in England No. 3338312. =
Registered<BR>office: Portland House, Park Street, Bagshot, Surrey GU19 =
5PG.<BR>Telephone: +44 =
(0)1483-746700<BR><BR>_______________________________________________<BR>=
Webappsec mailing list<BR>Webappsec@lists.owasp.org<BR><A =
href=3D"https://lists.owasp.org/mailman/listinfo/webappsec";>https://lists=
.owasp.org/mailman/listinfo/webappsec</A><BR><BR><BR>____________________=
___________________________<BR>Webappsec mailing =
list<BR>Webappsec@lists.owasp.org<BR><A =
href=3D"https://lists.owasp.org/mailman/listinfo/webappsec";>https://lists=
.owasp.org/mailman/listinfo/webappsec</A><BR></FONT></P></DIV></BODY><!--=
[object_id=3D#aspectsecurity.com#]--></HTML>
------_=_NextPart_001_01C8E04E.CFF55C76--
Brought to you by http://www.webappsec.org
Search this site
|