[WEB SECURITY] Re: The Great WAF Debate --was--> XSS/injection/... evading technique

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

This WAF debates on this list lately go me thinking.
They strike me as being largely academic and
lacking hands-on pragmatism by and large.

I wonder how big our WASC list is now? What is
the total list-membership? No doubt it is large.

For folks new to the list -- you'll notice the debates
lately seem to come from the following three crowds:

1. A little bit of knowledge is dangerous Camp
2. Pragmatic, Enterprise experiences Camp
3. Academic Theoretical Speculation Camp


1. Folks who appear to have tried to use a WAF
on one specific application they know, that does
not change much, so they can use the positive
security model policies effectively. Which, while
valid, is very a limited use-case for WAFs IMO.


2. Folks that put these in the average enterprise,
with 20+ (or 200+) internet-facing web applications
that either push code all the time (3x + per week)
or do not go through predictable change control
(whether they think they do or not).

I'm in the #2 camp. I have deployed numerous
WAFs including designing and implementing
my own WAFs ranging from filters to stats
analysis to tripwire style checksum engines.

I have deployed Appshield from its start as a
linux proxy to it's final dying Windows version.
I have deployed Web Cohort now Imperva as
everything from an IDS with TCP-resets to
the largest WAF deployments in the world
(at the time) on load-balanced Crossbeam
HA chassis. I've used XML gateways and
was testing 9 WAFs in front of production
sites simultaneously in 2005.

Overall I highly disliked WAFs, but this was
in large part due to their marketing message
(and blatant dishonesty). This, unfortunately,
still remains the case today. But at least the
technology and approaches are maturing.

I think a number of folks reject WAFs because
the WAF industry has largely shot itself in
the foot by lying so much. Or perhaps better
said -- they stretched the rubber band between
marketing and technical reality to the limits.
Now people are skeptical and critical of them,
and rightly so.

This doesn't change the fact that they are
a compensating control with a lot of operational
promise. Companies around the world are
actively and heavily investigating large purchases
and deployments of WAFs this year (2008).

You can bitch about this all you want, wag
your finger, shake your tail, spout how rewriting
all our source code is the only answer, or
whatever other religious truth you want to cling
to, but the fact remains that right now organizations
are starting to purchase WAFs just like
firewalls and NIDS.

Now I understand the hesitation regarding
some of these vendors. The Citrix Teros people
humiliated me in front of clients (I literally
had to sneak out of a room in a meeting once
at DST because I didn't want to be seen
associated with the nonsense that was spewing).

Yes...we all know: these things were mostly
crap back in the day, and largely failed to:

(A) run reliably at all
(B) solve customers' real webappsec problems

My current stance of WAF-acceptance (yikes!)
is not simply due to some vendor solution bias,
though a few folks have accused me of this on
their blogs. And that's fair.

My stance is based on WAF vendors finally
exploring approaches that seem to work, and
which I suggested many years ago (and so did
many others like Dinis Cruz at this time). I wrote
a WAF and XML Gateway guide back in 2003/4
at FishNet Security and you will find that it is
recommending the same approaches to "virtual
patching" that I recommend today. Some of
you in the aerospace industry will no doubt
remember this document if you worked with
me on WAF/XML gateway testing.

FishNet never let me publicly release it because
it was too acidic and included not so pleasant
details about certain vendors technical support
practices with their clients. (due to immature
technology, I believed vendor support was just
as essential to success with a WAF as the
core technology alone)

That guide is 2+ years outdated material or I'd
throw it on Joe's site today.

And that brings me to...let us not forget....we
have this third group with us too:

3. The Academic Theorist Camp. This third
group that adds to our collective dialoge and
debate consists of folks with interesting ideas
that usually lack field-testing or proof and
evidence that they work, yet are bandied about
with absolute certainty they will solve.

In this camp you will find some of WAF vendors,
the software security purists, many of the
academics, and my favorite: the always-amusing
arm-chair quarterbacks that randomly jump in
and provide uninformed responses on the list.

This third camp clearly has interesting ideas
and I would like to see many of them tested,
but overall I just do not relate to folks that
talk about technology for technology's sake,
or security for security's sake.

I really like ideas that help somebody in the
real world solve a real problem. My customers
have problems, and my lifeblood is helping
them identify their problems and solve them.

So that's me. If you see me square off and
disagree with the academic or purist crowd,
it is because I often think they are nuts, err,
well, it is because we differ philosophically
and have different epistemological views.
Or something.


I used to do scanner bakeoffs in widely varied
setups in my home lab and at FishNet Security.
I ran against test widgets, sample apps, and
many real-world production websites. Benchmarking
automation properly is very hard work; I completely
underestimated it in the beginning. Yet is is
highly educational on many levels and then
the raw data is also fascinating.

(This is a sales pitch to recruit you to dig into the
Art of Benchmarking Things)

Joe made a great community resource for us to publish
this kind of info on WAFs....

http://www.wafreviews.com

It sure would be nice to see some of the smart
minds on here start putting these things through
their paces and make the data public.

WAFs are a business reality. They look like
they are hear to stay. They help us operationalize
software security issues if combined with the
right discovery and analysis technology. So
get over it already.

And if the WAF vendors screw up and fail to
execute, the IDS/IPS guys will give us the
same solutions once they wake up.

It would be a lot more productive for us all to
pick these things apart, publicly test and document
all their defects and deficiencies, and use this
data to help the most co-operative vendors
improve their solutions until we have something
that really works.

(I do not expect this to happen, by the way.
I think at the end of the day efforts here will
wind up driven by vendors like my employeer.)

(Note that the product review industry is dead.
It was part of the print media dinosaur and
shoddy Internet security-product-reviews driven
by vendor click-through ads have replaced it.
We won't get help from the analyst groups
right now either. They are mostly paid off or
clueless when it comes to webappsec. So
we are all on our own.)

Alternately we could all sit back and throw
stones and talk about all sorts of academic
trivia on Why WAFs Won't Work, and do
nothing about it. But then at the end of the
day we would all look sort of foolish.

...

I'm all for WAF-bashing. Don't get me wrong.

I just happen to be doing something to help
improve them, too.

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




On Fri, Jul 25, 2008 at 6:40 AM, Ivan Ristic <ivan.ristic@xxxxxxxxx> wrote:
> On Fri, Jul 25, 2008 at 2:28 PM, Arshan Dabirsiaghi
> <arshan.dabirsiaghi@xxxxxxxxxxxxxxxxxx> wrote:
>> Inline:
>>
>>>> which are often
>>>> legitimate (for example, they're used to wrap JSON objects).
>>>
>>>> While that may be true, why on earth would untrusted users be allowed to
>>>> be
>>>> submitting HTML comments or submitting JSON objects that need to be
>>>> depantsed before processing? As an author of a rich content validation
>>>> tool,
>>>> I can say that this is categorically a bad idea. Consider the IE5+ XSS
>>>> vector:
>>
>>> On the other hand, consider a content management system where users
>>> are allowed to edit HTML templates in a browser. HTML comments,
>>> including IE's conditional comments, are legitimate content in that
>>> situation.
>>
>> Why would you have a WAF to protect this functionality? It's bound to set
>> off red alerts 24/7, and if users are trusted to send in malicious content,
>> same question?
>
> A few reasons:
>
> 1) Our users don't know in advance what their applications are using
> underneath. Hence we have to be able everything, including the corner
> cases.
>
> 2) If you really have to tell a WAF what to do and what not to do then
> your life's going to be very difficult. Plus it's a waste of time. If
> a technology is not easy to use people just won't use it.
>
> 3) Why not have a WAF protect that? That's the whole point of having a
> WAF in the first place :)
>
>
>>>> It's definitely going to be slower than simple pattern matching, but
>>>> that still doesn't mean that it's going to slow, because what's slow
>>>> for one deployment might not be slow for another. Either way, I think
>>>> we should first focus on how to secure things and then (if we need to)
>>>> how to scale the security measures.
>>
>> Well, if you know what the rules are for a parameter, it's pretty easy to
>> secure it. In the case of all the original emailer where the rule for the
>> parameter appeared to be "any printable character" the right choice would've
>> been to apply that rule simply output encode all non-alphanumeric in their
>> data on the way out (assuming it didn't end up inside an event handler,
>> <script> tag or CSS definition).
>
> --
> Ivan Ristic
>

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