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