I will note that many vendors try to get you to sign restrictive
NDAs when
you go into an eval so that you can't share your experiences as a
customer.
We push back on those kinds of requirements and generally try to
keep them
scoped to just truly proprietary info like business plans and
technical
secret sauce, not "we loaded it up and it sucked," but that
probably makes
lots of organiztions reluctant to share their findings (plus general
security paranoia, as if someone can't find out what WAF you're using
easily.)
Ernest
______________________
UN-altered REPRODUCTION and DISSEMINATION of
this IMPORTANT information is ENCOURAGED.
"Arshan
Dabirsiaghi"
<arshan.dabirsiag To
hi@aspectsecurity "Achim" <kirke12@xxxxxxxxxxxx>
.com>
cc
"Ernest Mueller"
07/07/2008 04:24 <Ernest.Mueller@xxxxxx>,
"Martin
PM O'Neal"
<martin.oneal@xxxxxxxxxxxx>,
<websecurity@xxxxxxxxxxxxx>
Subject
RE: [WEB SECURITY] RE:
[Webappsec]
[WEB SECURITY] Re:
Comparisons of
Web ApplicationFirewalls
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.
=]
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:
a) figure out how to make better WAFs
b) give better advice to our clients
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. =]
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.
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).
Cheers,
Arshan
From: Achim [mailto:kirke12@xxxxxxxxxxxx]
Sent: Mon 7/7/2008 4:59 PM
To: Arshan Dabirsiaghi
Cc: Ernest Mueller; Martin O'Neal; websecurity@xxxxxxxxxxxxx
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.
!!
!! 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
----------------------------------------------------------------------
------
Join us on IRC: irc.freenode.net #webappsec
Have a question? Search The Web Security Mailing List Archives:
http://www.webappsec.org/lists/websecurity/archive/
Subscribe via RSS:
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA