[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [WEB SECURITY] RE: [Webappsec] [WEB SECURITY] Re: Comparisons of Web ApplicationFirewalls

------_=_NextPart_001_01C8E077.C8B0B2D4
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Don't worry - no offense taken at all. I don't think there are many =
(any?) people out there that know many (all?) of the WAFs to that level =
of detail. =3D]
=20
The primary reason we don't have an across-the-board comparison to =
provide that kind of information is because the customers out there who =
have performed real bakeoffs have not shared their experiences as a =
group. That's a shame, too. I'm sure if they did we could:
=20
a) figure out how to make better WAFs
b) give better advice to our clients
=20
Being a security consultant, I bump into WAFs here and again but have =
never had the opportunity to compare even a few side by side in a real =
environment. Jumping from one vendor booth to another does not count. =
=3D]
=20
It seemed to me to be very silly not to have this level of support when =
I was looking at the rule creation for one of the WAFs given that I know =
for a fact PCRE is available in the framework it was written in. =
Regardless, I would hope its in the minority. Hell, it could have the =
ability to create the advanced rule, just in the interfaces I saw.
=20
Anyway, the WAF/PCRE point was tangential to my comment, though. I just =
wanted the author of the previous message to know that you can =
effectively whitelist UTF-8 using the Unicode keywords. It's not as =
simple as [a-zA-Z0-9] but it's not that much more difficult (in that =
case, [\p{L}\p{N}] is only 1 byte longer).
=20
Cheers,
Arshan
=20

________________________________

From: Achim [mailto:kirke12@securenet.de]
Sent: Mon 7/7/2008 4:59 PM
To: Arshan Dabirsiaghi
Cc: Ernest Mueller; Martin O'Neal; websecurity@webappsec.org
Subject: Re: [WEB SECURITY] RE: [Webappsec] [WEB SECURITY] Re: =
Comparisons of Web ApplicationFirewalls



On Mon, 7 Jul 2008, Arshan Dabirsiaghi wrote:

!! 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).

hmm, sounds like you have not seen much WAFs (no offence meant;-)
Most (all*) WAFs claim to support PCRE (I use "claim" as I didn't prove =
it),
and PCRE supports unicode properties, blocks and scripts very well.
On the other hand TCL does not support unicode properties, IIRC. So we =
can
imagine which WAF does not support such simple matches.

Conclusion: i18n or whatever character set is no reason to blame regex =
in WAFs,
I don't see a better way to handle interantional languages/characters =
than
with simple Unicode properties, scripts, blocks.

{-: Achim




------_=_NextPart_001_01C8E077.C8B0B2D4
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML dir=3Dltr><HEAD><TITLE>Re: [WEB SECURITY] 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=3DidOWAReplyText7732 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Don't worry - =
no offense taken at all. I don't think there are many (any?) people out =
there that know many (all?) of the WAFs to that level of detail. =
=3D]</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 =
size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>The primary =
reason we don't have an across-the-board comparison to provide that kind =
of information is because the customers out there who have performed =
real bakeoffs have not shared their experiences as a group. That's a =
shame, too.&nbsp;I'm sure if they did we could:</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 =
size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>a) figure out =
how to make better WAFs</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>b) give =
better advice to our clients</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Being a =
security consultant, I bump into WAFs here and again but have never had =
the opportunity to compare even a few side by side in a real =
environment. Jumping from one vendor booth&nbsp;to another does not =
count. =3D]</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>It seemed to me to be very =
silly not to have this level of support when I was looking at the rule =
creation for one of the WAFs given that I know for a fact PCRE is =
available in the framework it was written in. Regardless, I would hope =
its in the minority. Hell, it could have the ability to create the =
advanced rule, just in the interfaces I saw.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Anyway, the WAF/PCRE point =
was tangential to my comment, though. I just wanted the author of the =
previous message to know that you can effectively whitelist UTF-8 using =
the Unicode keywords. It's not as simple as [a-zA-Z0-9] but it's not =
that much more difficult (in that case, [\p{L}\p{N}] is only 1 byte =
longer).</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</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>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>From:</B> Achim =
[mailto:kirke12@securenet.de]<BR><B>Sent:</B> Mon 7/7/2008 4:59 =
PM<BR><B>To:</B> Arshan Dabirsiaghi<BR><B>Cc:</B> Ernest Mueller; Martin =
O'Neal; websecurity@webappsec.org<BR><B>Subject:</B> Re: [WEB SECURITY] =
RE: [Webappsec] [WEB SECURITY] Re: Comparisons of Web =
ApplicationFirewalls<BR></FONT><BR></DIV></DIV>=0A=
<DIV>=0A=
<P><FONT size=3D2>On Mon, 7 Jul 2008, Arshan Dabirsiaghi =
wrote:<BR><BR>!! 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.<BR>!!&nbsp;<BR>!! I can't say whether or not any WAF out there =
has this kind of capability (the few I've seen do not).<BR><BR>hmm, =
sounds like you have not seen much WAFs (no offence meant;-)<BR>Most =
(all*) WAFs claim to support PCRE (I use "claim" as I didn't prove =
it),<BR>and PCRE supports unicode properties, blocks and scripts very =
well.<BR>On the other hand TCL does not support unicode properties, =
IIRC. So we can<BR>imagine which WAF does not support such simple =
matches.<BR><BR>Conclusion: i18n or whatever character set is no reason =
to blame regex in WAFs,<BR>I don't see a better way to handle =
interantional languages/characters than<BR>with simple Unicode =
properties, scripts, blocks.<BR><BR>{-: =
Achim<BR><BR></FONT></P></DIV></BODY><!--[object_id=3D#aspectsecurity.com=
#]--></HTML>
------_=_NextPart_001_01C8E077.C8B0B2D4--
Brought to you by http://www.webappsec.org
Search this site