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

[Achim Hoffmann <kirke11 () securenet de>]

On Mon, 1 May 2006, Dinis Cruz wrote:

!!    5) Coming back to the WAF Appliance presentations, there are a couple
!! of comments that I have to make:
!!
!!         a) The presentations were all very BASIC (as in Simplistic).
!! Come on!!!! ...
!! Remember that the
!! WAF's must be able to detect ALL (or most) types of SQL Injections (not
!! only the ones with a quote). Think of the problems that IDS have in
!! detecting RPC traffic, the WAF will have exactly the same types of issues.

hmm, does this mean that nobody is able to configure WebProxy to test ALL
(known) vulnerabilities of a categorie? Come on ;-)

!!         b) I might be wrong on this one, but I do get the feeling that
!! these WAF vendors have a good understanding of 'data validation' attacks
!! ( SQL Injection, XSS, Cookies, etc) but fail to grasp the security
!! implications of (for example) application logic attacks (like the one in
!! Hacme Bank where user A is able to access data from user B). More
!! worryingly, they seem happy with this situation since (from their point
!! of view) their clients don't need that functionality.

I guess that the majority of cases in the logical and semantical layer could
not be detected by a WAF. That would require that the WAF knows the business
logic of all applications it protects.
Let the WAF detect the simplistic attacks, that's currently still a challenge.

!!        d) another area which I still think the WAF don't get it, is the
!! fact that no solution allows for the easy manipulation of the data being
!! analyzed (both at input and at output). At the moment you only have two
!! choices: 1) let the request go, 2) block the request and either show a
!! custom error page or logout the user. This is to radical.

hmm, the F in WAF stands for firewall and not for (substituting) filter.
Do you know of any network firewall which behaves this way?
It's dangerous that a WAF has its own idea how to sort data out (even if
configuerable). Just an example: the username comes as O'Reilly and your
smart WAF replaces the '. Does it replace for SQL injection or for XSS?
Which one would you prefer if the application needs both?
Input data validation has to be done by each application for each value
and this validation is bound to the destination of the data. Something
a WAF usually does not know.

!! We need the
!! ability to change the contents of form fields (or page contents)
!! dynamically. This will be the only way that some vulnerabilities can be
!! effectively managed and mitigated (while limiting the damage cause by
!! false positives). Note: same WAFs have the functionality to replace
!! cookies with their own (WAF controlled value)

Don't know what you mean here. If you mean values of input fields, see above.
If you mean values of fields in output (response), then there're still a
couple of WAFs which could encrypt values in responses and check if the
correct value comes back in the next request.

!!        e) Why don't they use their WAFs to protect the WAF's web
!! interface? Clearly a great test for the usability of a WAF product is to
!! use it to protect the complex GUIs used on the WAF management and
!! monitoring. Also, when (not if) vulnerabilities are found in their
!! product, they could use their WAF to mitigate those security issues.

OK, i.g. this is a true requirement. But keep in mind that a WAF is not
reachable from the internet, but it should only be reachable from trusted
hosts. Most WAFs support such a protection. Why should a WAF protect itself
from trusted hosts, that sounds overkill.
IMHO, such a protection is sufficient 'cause it only leaves the administration
interface open to session riding (which could be solved with isolated
administration hosts).
Anyway, I agree that it's a shame that some WAF have XSS, SQL injection
and some other vulnerabilities.

!!        g) And what about their website? Are the vendor's websites
!! protected by their WAFs?

a simple LOL could be the comment here, but I'm aware that some vendors
are listening ...

!!        i) What about the Web Application Firewall Evaluation Criteria
!! (http://www.webappsec.org/projects/wafec/)? How do this WAF appliances
!! rate to this? I might have missed it, but where is the public disclose
!! of this information?

yes the WAFEC could be used for that. But did you read at least the first 3
paragraphs in the Introduction of that document before asking this question?

!!     6) ...
!! Maybe the
!! solution is for a WAF company and a WASS company to merge and maximize
!! the skills sets of both.

There were two: Sanctum, KavaDo.
Kavado resigned. Sanctum was sold to Watchfire which splits WAF and WASS
again (F5 got the AppScan, why not ask them both:).
Anyway, not bad that idea, and sometimes I see in both camps that respectively
the other skills seem to be missing, or are at least not used. Sigh.

!!     7) Please take my comments with a pinch of salt :)

done
{-: 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
--------------------------------------------------------------------------