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

Fri Jul 4 07:55:52 EDT 2008

Hi,

after following this thread and it's discussions in various ways, I'll try
to shed some light on the initial question:
   "where I can find comparisons of WAFs"
It sounds like a simple question, where you usually respond with a bunch of
links. But looking deeper -as some posted comments do- will show that it's 
not that easy.
Well, I've to admit that I don't know of such a paper either, just what the
other posters already mentiond, see [1] and [2].

Said this, I'll start with Ory's comment 
	> I am simply amazed by the fact
	> that no serious public WAF evaluation has been published (at least
	> not to my knowing). I've seen great evaluation done for scanners, but
	> not for WAFs. Weird...

As I can't give an answer to "why WAF evaluation does not exists", I'd first  
point you to the fact that scanners -wether web application security scanners
or source code analyzers- are more like a passive security component, WAFs are
an active security device. While passive scanners identify some amount of
vulberabilities, threats and risks, active devices should/must protect against
these. Active components impact your network topology, infrastruture, and some
more. Passive scanners don't do that, they are just an add-on to your overall
security.
Conclusion: false positives and false negatives are acceptable for scanners,
somehow; but a huge amount of false positive in a productive WAF are a severe
problem. If you even find false negatives, you're in real trouble.
You see: running a WAF impacts your application, probably your business, using
a scanner doesn't harm anything (except the ego of your developers:).
Note: I'm not telling you that scanners a not usefull, but they are not the
topic in this question, hence no more comments about them here.

So we arrived in the real world, seeing the different purpose of WAFs and
scanners. Unfortunatelly the F -firewall- in WAF implies a similar functionality
to these devises as provided by traditional network firewalls. That's not the
case. Application level protection is much much more complicated. This is not
new, and discussed several times elswhere, but I repeat it here so that you
get used to it. 
May be the currently common acronym WAF is not well chosen, there have been
a couple of other terms around, see [4], but it's there and we probably can't
change it anymore. So, don't stress the F.

It's a complex world and the WAFEC [1] was the first attempt to get some things
ordered, we wait for WAFEC v2 comming soon.
Next step can be the WAF Best Practices Guide (available at OWASP [3]), which 
can guide you to evaluate the need and benefit of a WAF (english version is on 
work and comming soon, please check at owasp.org). This paper was presented on
OWASP AppSec 2008 in Belgium.
Beside [4], Ivan wrote another good "WAF beginner's guide" [5].

Now going more into the details how to use WAFs, we first need to know where
it is placed. A coomon web application is a n-tier environment like:

  -(1)- firewall -(2)- proxy/cache -(3)- web server -(4)- app. server -(5)- database

this may differ in various ways, adding load-balancers, switches, etc., but
that's not that important here.
The classical aproach is to "insert" the WAF at position (3). If we look at 
more sophisticated attacks like HRS -HTTP Re[quest|ponse] S[plitt|muggl]ing-
we see that (2) or even (1) would be a better place. Which one is the best?
Anybody out there to give the bullet prove solution? I doubt that it exists.
IMHO you better insert a single WAF at all positions: (1) til (5).

Why is this so difficult?
Well, lets explain with some of the complains about the incapabality of WAFs,
a comment which stands for a lot of such things:
	> Simple double-encoding will defeat most WAFs,

If you look at the picture above, it will defeat the WAF at (1), (2) and (3).
But a well configured WAF at (4) should detect it. Now think of some
obfuscated SQL injection. It may smoothly pass a WAF at (1) til (4), but
should be detected at (5).

Conclusion:
  it's not the fault of the WAF if it does not detect multi-encoding, most
  WAFs can, but you need to configure it properly *and* at the right place.

We can play the game on the business level again: due to whatever reason
someone decides to remove the web server as most application servers can do
that job too (even they where never designed for that). If your WAF was
configured for some kind of decoding, it most likely fails to protect the new
topology then.
Is that the WAF's fault? Most likely no.
Quoting Arian's comment:
	> ..  but most analysts are not experienced
	> enough (yet) to evaluate the intricacies of these features.
I'd amand that not just analysts are missing experiance but also the admins
responsible for configuering the WAF. It's a shame.
We can't blame the admins either, if they have not been informed about the
overall change in the n-tier environment.

It's a complex world ...

Having all this in mind, I slighly disagree with
	> The quality of WAFs varies greatly.
if said without knowing the context where and how a WAF is used.
IMHO it would be more accurate to say
	The features provided by todays WAFs vary greatly depending on the
	user's particular requirements.
In other words: each WAF has it's strength and weakness, but that highly
depends on it's intended use.
If you ever tried to protect a legacy application, you know why to use
product F and not product A. On the other hand, if you want something secure
like URL encryption you use product A and never think about F. We might
continue with examples for product H, I, J, M, N, W, etc. etc. etc.

To get rid of all the oddities, make your application secure.

Finally, there is no high quality comparsion of WAFs, and if you look at those
more or less half-hearted ones [6], you first have to remove some advertising
rant there. Then, second, you realize that they do not compare most common WAFS,
some are mentioned always, some never, and some are compared even they are not
real WAFs (but something like pimped network firewalls or IDS).
WAFs cannot be compared like scanners or network firewalls by just counting
their features. That's because they are used in a much more complex environment
*and* 'cause they impact your business.
Beside critical voices like [7], you can walk through webappsec mailing list
archive to find more complains (no offence meant, Arian;-)

It ends up in the same message (we all know):
  security is a process, not a product

Hope this helps to answer such a simple question (see subject).
{-: Achim

[1] http://www.webappsec.org/projects/wafec/
[2] http://searchsecurity.techtarget.com/magazineFeature/0,296894,sid14_gci1303838,00.html
[3] http://www.owasp.org/images/1/1b/Best_Practices_Guide_WAF.pdf
[4] http://www.thinkingstone.com/talks/Web_Application_Firewalls_-_When_Are_They_Useful.pdf
[5] http://www.net-security.org/dl/insecure/INSECURE-Mag-5.pdf
[6] http://www.networkcomputing.com/channels/security/showArticle.jhtml?articleID=185303795
    http://www.networkcomputing.com/channels/security/showArticle.jhtml?articleID=185303650
    http://www.nwc.com/1404/1404f42.html
[7] http://www.tssci-security.com/archives/2008/06/15/what-web-application-security-really-is

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