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

[Dinis Cruz <dinis () ddplus net>]

Achim Hoffmann wrote:
> !! 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.
>   
If by simple jobs you mean basic SQL Injection and XSS, then they 
already do that today
> Agreed. But application logic (your words: layer 7.5) is not part of layer 7.
>   
ok, so what is it part of?

Layer 8 is the User, so you can go there.

Where will you put that request?

Also how do you define Application Logic? Some WAFs are able to handle 
some types of application logic (namely the ones you can match to a 
signature)

So what you need is to find a name (or layer) for 'Application Logic not 
picked up by the WAFs that sits between Layer 7 and Layer 8'

:)

> !! > 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?
>   
You do what:

   a) mitigates the vulnerability that existed on that form field, and

   b) is compatible with the business requirement for the affected 
functionality (i.e. doesn't break functionality and user experience)
  
   c) is more cost effective to resolve
> Also, configuering a WAF that way could not be done by a knowledgable
> consultant, except (s)he knows all the details of the application. 
If you are applying a 'patch', then you only need to know the details of 
the affected page(s). That is the beauty of the solution that I am 
proposing: Maximum Security Impact with Minimum Business side effects
> 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.
>   
I am not sure about this, it helps to have access to the developers, but 
these patches can be created and deployed without them. In fact, in this 
case, the Testers could even be more important than the developers since 
regression testing will need to be done on those 'patches'.
> !! 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.
Liking or not Linking is not the question here :), I personally want to 
have the option to make the WAF change the data dynamically.
>  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.
>   
This only works in clear scenarios, where you have 100% certainty that 
what you are seeing is an attack.

What about when you are not sure? Maybe you only have 80% certainty that 
what you are seeing is an attack. what do you do in these scenarios?
> !! 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. 
What do you mean by '... then it could be encrypted'?

If the secret data is going out on a http response (to a valid http 
request),  then you have two choices:

      a) block the request
      b) modify the content in real time and remove/protect the secret data
> 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."
>   
yes, but I never said that the WAFs had to support the entire WAFEC? I 
just want to know their responses to it.
> 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 :)
>   
What vendors? By the number of responses so far it seems that no vendor 
is interested in debating these points on a public forum

Best regards

Dinis Cruz
Owasp .Net Project
www.owasp.net






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