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

Re: [WEB SECURITY] Re: [Webappsec] Comparisons of Web Application Firewalls



Martin -- agreed below on weak attack vector detection.
But that is changing (for the better).

I remember spending 3-4 months with one WAF
(insert name) while they futzed with their rules
through one after another after another attack
vector bypassed.

Here is what I think the problem is:

They use mushmouth, milk toast rules that can
be safely used in the manner of:

insert --> Global, Protect(all), ButDon'tBreak(anything)

Some, like HIVE, had this notion of Low/Med/High
protection (for things like XSS) which is also doomed
to fail, IMO. WTF does "med protection" mean?
Is that measurably better than low? (????)

In the case of F5, I've seen their rules, and know
they have created far more robust and aggressive
rules that work differently than the "block the latest
attack vector" game.

They won't, however, work in "global magic rules"
mode which about the best that the box-pusher
VARs can usually manage to deploy them.


The new approach works like: Hey, this input
here (n=v pair, whatever) is known vulnerable
to XSS attacks, or this param is weak to tampering,

insert MassiveLockdownMode(onlyHere)

We're finding these type of arguments hold up
well under testing, impact performance less
than InsaneGlobalRule mode, and have
measurable benefits.

It has, to be fair, been an uphill battle with
most WAF vendors to get them to go down
this path. They are scared to death of aggressive
rules that break things.

They are more likely to get kicked out of a
bakeoff or analyst report for aggressive rules
that break something, than weak attack
vector blocking that most don't understand.

Again, I think the whole approach is changing.

F5 is definitely making strong new strides.

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





On Thu, Jul 3, 2008 at 1:31 PM, Martin O'Neal <martin.oneal@xxxxxxxxxxxx> wrote:
>
>> I don't want to start a flame
>> war here - but there is not
>> a single, competent review of
>> WAFs for public consumption as
>> of today.
>
> My own personal experience of assessing many of applications protected
> by all the major WAF vendors is that in practice (like IDS/IPS) they
> offer very little real-world value.  Most are installed by the
> vendor/tin-pimp as out-of-the-box, and the ones that aren't are
> generally in log-only mode and unmonitored.
>
> One recent project had a broken app protected by an F5 WAF.  The client
> (against our advice) decided that they would fix the problems using the
> F5 (whilst waiting for the app vendor to refactor).  The general process
> for this is that the F5 pimp analyses the last set of successful vectors
> we used, tinkers with the WAF rules, says it is fixed, then we come back
> and vary the attacks just enough to bypass the rules.  All a complete
> waste of money and time.  I think we are on fourth of fifth re-test now,
> and no end is in site.
>
> WAF does have some merit as a dynamic patch for quick and dirty fixes,
> but they do very little (if anything) to protect a broken application
> from a skilled attacker.
>
> Martin...

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



Brought to you by http://www.webappsec.org
Search this site