Tide Out for Web Application Firewalls

I recently stumbled across an article by Ivan Ristic who also writes for the ModSecurity Web Security Blog. It’s about how 2008 is finally going to become the year of Web Application Firewalls.

I really hate to be a spoilsports, but I’m afraid it’s still a long time until we have such a thing as the Year of WAFs. I’ve never been a huge fan of such firewalls and for a reason. I’ll use the following posting to tell you why I feel this way.

While I think that e.g. ModSecurity can increase the security by some, the dangers IMHO out-weight the gains. Here is my reasoning:

• Web Application Firewalls give companies a false sense of security. As opposed to normal network firewalls, where people know exactly that such devices keep traffic from going to certain ports, however let traffic to other ports pass, it is impossible to know the vulnerabilities that can or cannot be prevented with a WAF in front of an application. Many instances of SQL Injection or Cross-Site Scripting will be detected, but others will fall through the cracks. I’d rather know that I have lots of SQL Injections in my application than think it is secure when it in fact has a few exploitable flaws.
• Many critical vulnerability classes can not be detected and prevented at all. Flaws in the logic of an application, or Cross-Site-Request Forgery vulnerabilities (which get more interesting by the minute) can be exploited even with a WAF in front of the application. This, in connection with the false sense of security matter mentioned above can be a problem, even though I admit it is a weak argument not to use WAFs just because they don’t protect against certain attacks.
• They increase the attack surface by adding a new layer. While ModSecurity seems to have a pretty clean vulnerability record, this does not hold true for other Web Application Firewalls. In any case, they do add a layer of complexity and therefore also bear the risk of introducing new vulnerabilities. In fact, I’ve seen WAFs that were more easily hacked than the application they was supposed to protect.
• False positives can cause the protected application to stop working. WAFs come with a huge number of default configurations. However many are not context sensitive and those who are can often be tricked. Take the word Union for example. It might either be used by an attacker exploiting an SQL Injection vulnerability, or by a valid user posting a comment about the European Union. Another example is a forum that allows certain HTML-tags for postings. The default configuration will break the complete forum functionality. Companies using WAFs to protect huge applications need to put a whole lot of work into testing if their web applications still work in boundary conditions after installment.

So, to sum it up, I think it is indeed possible to protect web applications from some attacks by WAFs. However it takes a lot of work to correctly configure the product and make it a fit to the application. More importantly, correctly configuring it requires to know the vulnerabilities to protect from. Once the vulnerabilities are known, it’s almost always more effective to patch the code instead of putting a WAF in front of it (there are some cases where this might not be true, e.g. when only the binary code is available and the manufacture cannot be squeezed to fix the flaws).

My appeal is to please, please Web application developers: Start to write secure code. It’s not that hard! Have a look at the Open Web Application Security Project (OWASP) Guide. It is a great starter into the world of secure development.

Picture of Lego-Firewall by ianlloyd

Tags: Application Level Firewall, Cross Site Scripting, CSRF, Firewall, Firewalls, Hack, Hacking, ModSecurity, OWASP, Rant, Security, SQL Injection, Vulnerabilities, WAF, WAFs, Web Application Firewall, Web Application Firewalls, Web Application Security, XSS