What should we do when web protection mechanisms fail?

By Rodrigo Montoro on March 24, 2009

Upon reading the news we have found a problem in the modsecurity that can be exploited by means of a simple web requirement.

Many companies generally make use of tools like the Web Application Firewall (WAF) to protect their web applications against attacks but the question is: who’s going to protect the protection itself?

We often use Web Application Firewall (WAF) to mitigate errors in programming and attacks carried out with SQL Injections, Cross Site Scripting (XSS) among so many attack forms existing on the server side. Starting from the principle that if a threat exists — whereas the vulnerability does not exist, then there is no Risk involved. So why companies, instead of usually deploying another tool for protection just to make it do, do not create or set up the development process of their respective tools by adopting SDLC and fixing the problem instead of just mitigating it with another possible point of failure?

The SDLC (Software Development Life Cycle) proposes to formalize (within a team dealing with project construction phases) processes and norms that will facilitate previsibility and, most of all, productivity, which will be capable of being measured in the outputs of such team.

You may point out that your web application firewall has a bypass (failover/failopen) or that I can run my solutions in active-active cluster. Vendors very often try to sell us jargons such as “My solution has bypass capability failover/failopen) and thus your application will not be off the air”.

My question is: Is it better to remain online with a critical vulnerability like a SQL Injection that was being protected by the Web Application Firewall or simply stay off the air and thus have nothing explored and exposed on the internet?

I particularly like the web application firewall as a virtual patching tool (in case the process fails – nothing is perfect), i.e., if your scanner for web vulnerability, code review and pentesting finds something you will be protected while programmers correct the solution.

The failure we had read about was in the modsecurity and this is a typical example showing that protection tools have flaws like any other systems and, YES, they also show flaws, maybe low, critical, local and remote ones. When remote, as mentioned, how can one protect himself from it? Who can protect the protection?

By making use of safe development processes, besides “really fixing” the problem, it can as well diminish to a great extent another point of failure in your structure.

Exploit for the DoS of modsecurity : http://www.milw0rm.com/exploits/8241

We must bear in mind that I am not saying that you shouldn’t use the web application firewall – I believe they are excellent tools (as I mentioned in my opinion – they are fine tools for virtual patching), however, this is not the most correct way to mitigate web application issues.

This entry was posted in Community Blog and tagged , , . Bookmark the permalink.