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

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



I think we've about said it all on this thread,
but I'll throw in one more comment to commemorate
the 4th of July:

On Fri, Jul 4, 2008 at 1:41 AM, Martin O'Neal <martin.oneal@xxxxxxxxxxxx> wrote:
>
>> Martin, I am assuming that the WAF
>> you were going against had one or
>> both of these problems.
>
> Yes, definitely.  But a WAF (even when correctly deployed) is also being
> used to fix a problem that just doesn't exist.

Actually, statistically speaking: we do know the problem exists Martin.

I think every website has an average of 7 vulns.

We just don't know WHERE or WHAT vulns until we look.

Absolutely agreed that our fundamental problem with
Syntax security issues in web code is the inability of
modern implementation level languages to provide
meaningful controls to enforce a boundary between
data and function. In this way syntax attacks (XSS,
SQLi) aren't any different than buffer overflows.

So sure, we're not fixing the code. WAFs are a
mitigation strategy. That's all. The only question
is whether they can mitigate.

So begging the question on syntax issues...
(assuming we all understand WAFs can either
blacklist syntax arguments, or whitelist input,
to solve the data/function boundary problem)

Now this gets more interesting when we get
into Semantic arguments. Out of the box
WAFs do not tend to do well here. I know
one large Imperva customer that has
completely given up on locking down simple
integers in name=value pairs. And
Imperva is not alone in facing challenge
here -- it's just that Imperva and Citrix
(Teros) make all these magic claims
in this department they can't support.

What a shame. This customer, like many
I've met, knows that integer rotations are
main attack threat to many of his authorization
weaknesses (all controlled by INTs).

Now how much easier would it be if you
could just identify which INTs are actually
related to authorization, or authentication,
or CSRF workflow protection, and then
just lock down *those*?

Semantically, you shouldn't expect to
break anything. You are simply enforcing
the expected (intended) user dialogue
with the application.

This should be the *easiest* thing for
WAFs to solve, and yet out in the real
world, this is the thing they are farthest
from actually doing.

Why is this?

Clearly we know how to do this, and the
mitigation should be effective, and have
huge benefit to business owners (auth
issues aren't usually things to be trifled
with in terms of immediate importance).

I'll tell you why I think it is:

It's the WAF marketing. They can't sell
their widget unless they promise the
customer that it comes with a magic
auto-learning elf inside.

Imperva recently told a customer of
mine that they'd be up and running in
from of all their applications (dozens)
providing protection in "2 hours".

They still aren't doing anything useful
today, months later, unless you count
locking down things like GET to POST.

I think the technology is fundamentally
sound, if properly applied, as both detection
and response technology, or as short
term mitigation technology whilst the
business owner figures out what it is
that they want to do.

I mean -- why are we assuming that
we know what's best for the business
owner? That's fundamental security
fallacy 101. Maybe they want to deprecate
the entire app. Maybe they want to fix
just the international wires part.
Entirely their call.

I hate biological analogies, but I will
say that when I go to the doctor I have
yet to have them give me the "get well
pill" and wrap my whole body in a sheathe.

That, in essence, is what most of the
WAF-peddlers are bamboozling their
prospects with today conceptually.


By the way -- if you think WAFs don't
make any sense at all, keep in mind:

The average time to close a vuln is
over 100 days.

That ain't in short reach of "implement
output encoding library this afternoon"
or "fix all our auth spaghetti code".

I think a WAF is worth 100 days of
breathing room, especially when
I have clients that get attacked in
sub-18 days of pushing a defect
to production code.

Whew.

So how's that for "one more comment"?

Now Martin, I have to go shoot off some
guns and fireworks and celebrate my
freedom from those oppressive Brits! :)

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



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