While you spend your time arguing over where application security belongs, miscreants are taking advantage of vulnerabilities. By the time you address the problem, they’ve moved on to the next one.

Dmitry Evteev @ Positive Technologies Research has discovered (yet) another method of exploitation that allows for the injection of malicious SQL into sites and databases.

A method that I discovered today in MySQL documentation struck me with its simplicity and the fact that I haven’t noticed it before. Let me describe this method of bypassing WAF.

MySQL servers allow one to use comments of the following type:

/*!sql-code*/ and /*!12345sql-code*/

As can be noticed, SQL code will be executed from the comment in both cases! The latter construction means that "sql-code" should be executed only if the DBMS version is later than the given value.

As I have been repeatedly asserted [1,2], some WAFs skip comments during signature search. Among such WAFs, there is the latest stable assembly of Mod_Security (v. 2.5.9).

As is immediately pointed out by several folks in the comments, while this exploit may indeed get past a WAF (and through application defenses, too) for an agile web application firewall (WAF) this is not really a problem. Even for not-so-agile WAFs this should  not be too much of a problem provided the detection of the /*! pattern is flexible enough to adapt in the event that /* ! and /*  !, etc… are also valid exploitable patterns.

In the case of a WAF enabled not just with standard schema (input field) parameter tightening capabilities, i.e. the ability of a WAF to restrict the valid input for any given form field/element/object in a web application, but also enabled with network-side scripting exploits like this can be addressed immediately, before it can be exploited.

Now, every time one of these “avoiding the WAF” exploits is discovered or discussed it kindles the flames of the WAF vs APP security war. Why there’s a war in the first place is beyond me as the two techniques are certainly complementary and should be working together toward a common goal: the defense of web applications against exploitation.

But someone is sure to bring it up, so I’m going to ask a very valid, I think, question:

How long would it take for your developers to address this vulnerability in every application?

Remember that the time includes not only development, but testing and deployment into production where those vulnerable applications are exposed. Never mind, you don’t need to answer that. A look at the Spring 2009 Website Security Statistics Report from WhiteHat Security clearly shows that it’s too long: 

Q1 2009 Key Findings

• 82% of websites have had a HIGH, CRITICAL, or URGENT issue
• 63% of websites currently have a HIGH, CRITICAL, or URGENT issue
• 60% vulnerability resolution rate among sample with 7,157 (out of 17,888 historical vulnerabilities) unresolved issues remaining as of 3/31/09
• Vulnerability time-to-fix metrics are not changing substantively, typically requiring weeks to months to achieve resolution.
• Average # of HIGH, CRITICAL, or URGENT severity vulnerabilities per website during the vulnerability assessment lifetime: 17
• Average number of serious unresolved vulnerabilities per website: 7
• Average number of inputs (attack surface) per website: 227
• Average ratio of vulnerability count / number of inputs: 2.58%

In the 38 days it takes developers to address a new vulnerability across all web applications those same applications are vulnerable; exposed to the possibility they will be exploited, which puts not only the organization but users, customers, and partners at risk for exploitation, identity theft, and data exposure. Web application firewalls are enabled with flexible, agile methods of filtering, screening, and inspecting requests and data to ensure this very type of exploit cannot reach an application. No, the specific solution is not necessarily coded into the WAF any more than it’s coded into the application as the discovery by Dmitry clearly shows. But the web application firewall can be quickly, within hours if not less, adapted to stop an exploit in its tracks while it’s going to take much longer than that to do the same in every application for which this vulnerability might be applicable. That, too, is clearly indicated by the responses to Dmitry’s post in which several folks point out how easy it is to modify mod_security to recognize and prevent the evasion.

Are there architectural and performance advantages – and disadvantages – to employing a WAF? Of course there are. It’s give and take, like any technological solution. There are pros and cons, risks and benefits that need to be weighed. But when you’re weighing the decision based on where web application security should exist you have to factor in when it will exist and how that impacts the overall risk of the choice not to employ a WAF and trust only in developer-generated security.

No one is saying “don’t fix this in the application.” What we’re saying is stop the exploit now, before it’s used against you, while miscreants are taking advantage of the window of opportunity they know exists when a new exploit is discovered. When a vulnerability is addressed is probably much more important than where, and I’m willing to bet that users, customers, and partners don’t care one whit about how you prevent them from being exploited, they only care that you do.

Related blogs & articles:

• Would you risk $31,000 for milliseconds of application response time?
• Web Application Security at the Edge is More Efficient Than In the Application
• Securing the Other Side of the Cloud
• Cloud Changes Cost of Attacks
• Layer 4 vs Layer 7 DoS Attack
• An Unhackable Server is Still Vulnerable
• The IT Security Flowchart
• Get your SaaS off my cloud
• New TCP vulnerability about trust, not technology
• 4 Reasons We Must Redefine Web Application Security