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

[Dinis Cruz <dinis () ddplus net>]

Achim Hoffmann wrote:
> hmm, does this mean that nobody is able to configure WebProxy to test ALL
> (known) vulnerabilities of a categorie? Come on ;-)
>   
I am not saying that nobody would able to use a WebProxy to test ALL 
(known) vulnerabilities. That is even doable with notepad and NetCat :)

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.

Remember that most HacmeBank vulnerabilities (namely the ones the WAF 
vendors did their demos on) are basic examples, which would be easy to 
implement in a automated test suite (if they had one)
> I guess that the majority of cases in the logical and semantical layer could
> not be detected by a WAF. 
My argument is that they should be detected by a WAF (we might agree to 
disagree on this one :).
> That would require that the WAF knows the business
> logic of all applications it protects.
>   
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)

Think about this, normal firewalls don't do Layer 7 (port 80,443 traffic 
is not checked), if then you have WAFs (at layer 7) that only check for 
basic exploits, what happens next?

XYZ appliance that handles the Layer 7.5? (i.e. the application logic)
> Let the WAF detect the simplistic attacks, that's currently still a challenge.
>   
Well I refuse to accept that WAFs can only handle simplistic attacks.

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

"...TrafficShield® is a web application firewall that provides 
comprehensive, proactive, network and application-layer protection from 
generalized and targeted attacks..." 
(http://www.f5.com/products/TrafficShield/)

"...The SecureSphere Web Application Firewall is the only solution to 
provide automated attack protection for Web and Web Services 
applications....Dynamic Profiling is the foundation of a multi-layer 
security architecture that provides complete protection for all layers 
of the application infrastructure, including the network, server and 
application" 
(http://www.imperva.com/products/securesphere/web_application_firewall.html)

"...WebDefend is a next-generation Internet security appliance that 
provides comprehensive Web application protection to resolve information 
security challenges such as Identity Theft, Information Leakage, 
regulatory compliance, and insecurely coded applications..." 
(http://www.breach.com/products_breachgatewebdefend.asp)
> !!        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.
>   
That depends on your definition of Firewall :)

Here is a good one:

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

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.
> Do you know of any network firewall which behaves this way?
>   
No I don't know of a WAF Appliance that behaves like this (which is a 
shame because I would have several clients for them). This gap in the 
market is exactly why I am defending that this is were the new 
generation of WAF vendors should be focusing their effort on.
> It's dangerous that a WAF has its own idea how to sort data out (even if
> configuerable). 
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).

Note that I am not defending that you should actively use a WAF on the 
entire website (especially the functions that dynamically change data).

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.

Being able to dynamically manipulate form's (and other http) content has 
the following advantages:

   1) There are some security issues that you cannot mitigate in any 
other way (for example information leakage, or certain types of data 
validation)
   2) It minimizes site effects and allows much more flexibility on how 
do you handle (potential) malicious input (remember that at the moment 
you get a black or white decision (allow or deny))
   3) It allows for the detection of an attack without giving the 
attackers any clue that the attack was detected (of course that I am 
assuming here that there are incident escalation procedures in place)
> 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?
>   
That depends on the case and on the specific vulnerability. What I know 
is that I don't want Mr O'Reilly to get a 404 page or to be logged out 
every time he signs up for a newsletter (let's assume that the login 
page was not vulnerable to SQL Injection, since Mr O'Reilly needs to 
login :) )

I also like to have the possibility to replace one ' with '' (two ' ) or 
with an html version of a ' (')  or with an _ (underscore) or with a 
"[quote was here]" tag (to be replaced on the way out with a ' again :)

The bottom line is that you need to be able to have the flexibility to 
provide the business with a solution that A) solves/mitigates the 
security vulnerability and B) doesn't affect the user's experience
> Input data validation has to be done by each application for each value
> and this validation is bound to the destination of the data. 
Of course, Data Validation should ultimately be the responsibility of 
the Application. But with development cycles of weeks or months, WAFs 
'patches' are the perfect solution to stop current or future attacks on 
known vulnerabilities.

In the medium term, what would also help would be if web applications 
were able to provide (to the WAFs) xml feeds containing detailed 
information about all input points (i.e. the attack surface). Think 
Struts (http://struts.apache.org/)
> Something
> a WAF usually does not know.
>   
It doesn't do know, but I wish they did
> !! 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.
>   
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)
> 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.
>   
Sure and that is a good thing they do.

But what about when secret data is sent on a response? Shouldn't we be 
able to stop that?
> !!        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.
True, but in large enterprises the number of nodes that will be able to 
connect to those boxes will be quite high, but (as I explain below) the 
main reason for this request is not to reduce the risk created by these 
web applications
>  Why should a WAF protect itself
> from trusted hosts, that sounds overkill.
>   
Why? Surely a WAF should be able to handle such task without any 
problems? Aren't they all designed to handle complex websites generating 
large amounts of traffic?
> 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).
>   
If isolation administration hosts worked in large corporate 
environments.... :)
> Anyway, I agree that it's a shame that some WAF have XSS, SQL injection
> and some other vulnerabilities.
>   
The problem here is not that they have those issues (that is a problem 
with the software industry), the problem is that these WAF don't have a 
quick way to deploy patches for those vulnerabilities.

Also by using the WAF to protect their web applications (which are 
complex and feature rich) they (the WAF vendors) would gain a huge 
amount of experience on what a complex application looks like, and how 
to handle the issues that are created by protecting it with their product.

I would also be a great demo for them (unless they couldn't protect 
their WAF security issues with their WAF :)
> !!        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?
>   
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?

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

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