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

["Arian J. Evans" <arian.evans@xxxxxxxxxxxxxx>]

<inline>

On Mon, Jul 7, 2008 at 9:30 AM, Arshan Dabirsiaghi
<arshan.dabirsiaghi@xxxxxxxxxxxxxxxxxx> wrote:
> Ernest,
>
> In the interest of making things clear, I'm going to seperate the two issues
> you have with WAFs:
>
> 1) The WAF doesn't work (crashes, doesn't block anything, etc.)
> 2) Lack of i18n in whitelisting rules
>
> Considering #1, this is pretty inexcusable for a WAF product that should be
> relatively mature by this point.


Most of them still crash intermittently, I hear from everyone
I talk to testing them. Doing deep blackbox parsing of websites
and attempting to globally, automagically wrap them up in a
transparent condom of safety rules is a tough job.

At WhiteHat we've been working with some of the vendors to
tighten up their lists and rules. As I said before, if you target
known weak areas exclusively, you can be much more
(justifiably) aggressive than when in GlobalMagicCondom mode.

The WAF vendors have to be careful with their story here,
though. If they embrace attack vector blocking, and don't
provide much else in terms of functionality, there is a chance
the IPS vendors will wake up one day and crush them.

Luckily, today, the IPS/IDP vendors are sound asleep on
the subject of web application security. That could change.
Attack-vector detection in URIs and Postdata could be done
without a complex autolearning WAF.


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


iSec Partners has a decent presentation on this from BH a year or two
ago, and maybe a paper on their site. I have some material about
transcoding issues in code pages like Hebrew Unicode I'll be
blabbing about at BlackHat this year.

Nice suggestions below.

-ae

> 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.
>
> 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).
>
> Regarding the backwards languages - won't the attacks have to be in the
> normal direction to work anyway? =]
>
> Cheers,
> Arshan
>
> [1] http://unicode.org/unicode/reports/tr18/
>
>
> ________________________________
> From: webappsec-bounces@xxxxxxxxxxxxxxx on behalf of Ernest Mueller
> Sent: Mon 7/7/2008 11:29 AM
> To: Martin O'Neal
> Cc: websecurity@xxxxxxxxxxxxx; webappsec @OWASP;
> webappsec-bounces@xxxxxxxxxxxxxxx
> 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.
>
>
>
>
>              "Martin O'Neal"
>              <martin.oneal@cor
>              saire.com>                                                 To
>              Sent by:                  "Arian J. Evans"
>              webappsec-bounces         <arian.evans@xxxxxxxxxxxxxx>
>              @lists.owasp.org                                           cc
>                                        "webappsec @OWASP"
>                                        <webappsec@xxxxxxxxxxxxxxx>,
>              07/07/2008 05:28          websecurity@xxxxxxxxxxxxx
>              AM                                                    Subject
>                                        Re: [Webappsec] [WEB SECURITY] Re:
>                                        Comparisons of Web Application
>                                        Firewalls
>
>
>
>
>
>
>
>
>
>
>
>> 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@xxxxxxxxxxxxxxx
> https://lists.owasp.org/mailman/listinfo/webappsec
>
>
> _______________________________________________
> Webappsec mailing list
> Webappsec@xxxxxxxxxxxxxxx
> https://lists.owasp.org/mailman/listinfo/webappsec
>
> _______________________________________________
> Webappsec mailing list
> Webappsec@xxxxxxxxxxxxxxx
> https://lists.owasp.org/mailman/listinfo/webappsec
>
>



-- 
-- 
Arian J. Evans.
Software. Security. Stuff.

----------------------------------------------------------------------------
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