Virtual patching, for those new to the term, is the practice of adding a rule to a Web Application Firewall (WAF) to filter out traffic that could exploit a known vulnerability in a protected application. This has triggered debate in the security community — is this a good thing? Why would a developer fix the vulnerability if it is mitigated?
First off, Virtual Patching is, in fact, a good thing. The development turnaround time for a WAF rule is almost certainly shorter than the development cycle for the backend application, so this shortens your mitigation window. That shouldn’t really be a topic of debate.
The interesting debate, then, is how we manage the underlying vulnerability. One school of thought argues that the WAF is only a stopgap, and developers should fix the vulnerability because that’s the right thing to do. Another school’s argument is a bit more complex. Don’t fix the vulnerability. Fix the entire class of vulnerabilities.
If you have a vulnerability in a webapp, odds are that it’s a symptom of a greater category of vulnerability. That CSRF bug on one page likely reflects a design flaw in not making GET requests nullipotent, or not using some form of session request management. Given the urgency of an open vulnerability, the developers will likely focus on fixing the tactical issue. Virtually patch the tactical vulnerability, and focus on the flaw in the foundation. It’ll take longer to fix, but it’ll be worth it in the long run.