Re: [WEB SECURITY] Review of Owasp-London Chapter meeting on WAF (Web Application Firewalls)

[Achim Hoffmann <kirke11 () securenet de>]

{-: Achim

On Mon, 1 May 2006, Dinis Cruz wrote:

!! But that is not my point. My point is that these guys build WAF for a
!! living, and I was expecting a more sophisticated method to automatically
!! test these issues.

OK, then we wait for the vendors' comments on this :)

!! Exactly, and because that is a complex task, the WAF's vendors don't do
!! it today (but in my point of view will need to do it in the future)

Good requirement. But I'd like to see WAFs first which fit into existing
environemnts and do simple jobs there, before they claim to do something
sophisticated.

!! That said, If the bottom line is that (for now) WAFs can only handle
!! simple attacks, then somebody needs to update they marketing material:

Requirement to the vendors, not something to be discussed in the list,
isn't it?

!! Here is a good one:

That depends on your definition of "good" :)

!!
!! "What is a Web Application Firewall?
!! An intermediary device, sitting between a web-client and a web server,
!! analyzing OSI Layer-7 messages for violations in the programmed security
!! policy. A web application firewall is used as a security device
!! protecting the web server from attack."
!! (http://www.cgisecurity.com/questions/webappfirewall.shtml)

This definition talks about "protecting" not substituting.

!! So unless you want to start dividing Layer 7 traffic into multiple
!! sub-layers (Data Validation basic, Data Validation advanced,
!! Authentication, Strong Authentication, Authorization, Deep Authorization
!! (I made up this last one :), etc...)

!! I would argue that Web Application
!! Firewalls are layer 7 firewalls, and should be able to protect against
!! all attacks deployed via that layer.

Agreed. But application logic (your words: layer 7.5) is not part of layer 7.
Anyway, would be nice to have a WAF doing that ...

!! > It's dangerous that a WAF has its own idea how to sort data out ..
!! Why? Remember that I defend that the point where WAFs are most effective
!! and valuable is when they are being configured by an experienced and
!! knowledgeable security consultant (preferably not the one that found the
!! vulnerability).

See my example: O'Connor
Do you configure to substitute for XSS or SQL injection?
Also, configuering a WAF that way could not be done by a knowledgable
consultant, except (s)he knows all the details of the application. But then,
with that knowledge, the consultant could fix the application code also.
I'm not saying that knowledgeable security consultant are not able to
configure WAFs, but they need to know the application including its logic,
usually not possible without having the developer aside.

!! What I am defending is that If I (the client) know that a certain
!! vulnerability exist (discovered by a security consultant or by analyzing
!! the logs of a 'live' attack (occurring at that moment)), then what I
!! (the client) want, is to be able to as quickly as possible (and with the
!! least amount of side effects) deploy a 'patch' to my application which
!! will a) mitigate the vulnerability and b) have zero or minimal impact on
!! my normal user's session experience.

Good idea, for a quick&dirty workaround.
Not sure if mod_security 2.x  can do that.

!! Do you still disagree with me that sometimes you NEED to be able to
!! dynamically change the contents of an HTTP request (namely Form values)

Agree or disagree is not the question here. I personally don't like the
idea that the WAF changes data. It's purpose is to allow or to reject.
The main reason for this strict behaviour is that you never know if the
changed data cause problems elsewhere, or an other attack is possible with
the changed data.
My favorite rule: reject anything you don't know or you don't expect.

!! But what about when secret data is sent on a response? Shouldn't we be
!! able to stop that?

If it is in a form, and read only, then it could be encrypted. If it is
content, then I guess that such secret data is the purpose of the
application, otherwise most WAFs are able to cloak the output.

!! If isolation administration hosts worked in large corporate
!! environments.... :)

It should.
But I forgot that second order code injection came into question too ...

!! I had read the WAFEC document before, and just to make sure I didn't
!! miss any thing major I just re-read those first the paragraphs
!! (http://www.webappsec.org/projects/wafec/v1/wasc-wafec-v1.0.html), and I
!! don't understand your question. What is there in these 3 paragraphs that
!! I should be aware of?

Cite:
  "However, our aim is not to document the
   features that must be supported in order for a product to be called a
   web application firewall. Web application firewalls are simply too
   complex to be treated like this."

Also, someone in the list posted an excel sheet with all those criterias,
probably that's something you're looking for.

!! Note that all that I am asking for is for the WAF vendors to publicly
!! disclose their WAFEC results.

Hmm, if all your questions addressed the vendors only, but have not been
addressed to the readers of the mailing list, then my comments could have
been avoided :)

{-: Achim


-------------------------------------------------------------------------
Sponsored by: Watchfire

The Twelve Most Common Application-level Hack Attacks
Hackers continue to add billions to the cost of doing business online 
despite security executives' efforts to prevent malicious attacks. This 
whitepaper identifies the most common methods of attacks that we have seen, 
and outlines a guideline for developing secure web applications. 
Download this whitepaper today!

https://www.watchfire.com/securearea/whitepapers.aspx?id=701300000007t9r
--------------------------------------------------------------------------