Updated 4/16/2020. Originally published 12/28/2016.
It seems so tempting. Solve your application security problem by throwing an appliance at it. After all, if web applications are the most common form of attack, why not just protect them the same way you protect your network and email servers, and be done with it? Why should you spend time hunting down vulnerabilities in your code and figuring out how to fix them?
The “appliance throwing” approach would be viable if web application firewalls (WAFs) were perfect, but protecting your app layer with only a WAF leaves a lot of holes. WAFs, at their heart, are black-box protection technologies that rely on inspecting incoming traffic for known attack patterns – and that’s often not enough. There are circumstances where WAFs will leave you vulnerable to attack, for instance:
Missed attack due to new patterns
A WAF tries to use known attack patterns to protect an application. It can be tuned via writing rules, but attackers are coming up with new patterns all the time. In fact, creating WAF bypasses is something of a cottage industry for security researchers, to the point that you can download cheat sheets for creating WAF bypasses from security researchers like @Pentestit_ru and @themiddleblue, the editor-in-chief from 1337pwn, or the well-known OWASP foundation.
And that’s not even including the risk of new vulnerability categories. Veracode Community member Mark Merkow from HealthEquity notes, “Even if a WAF is configured 100 percent correctly and catches and stops attacks it knows about successfully and every time, it's still at risk for letting new attacks through, including zero-day attacks. With Web Services and API communications as the most likely future form for all apps, WAFs will become less and less useful. What will survive in this new world are well-written, high-quality, resilient applications that can stand up to endless attacks.”
Missed attack due to application changes
Based on the results of a penetration test or other evaluation of an application, you can make a WAF very accurate by creating rules that focus on specific input fields and types of vulnerability. However, you have to maintain these rules every time the application is changed. The SANS Institute notes, "During the WAF deployment, everyone involved understands exactly which form fields and inputs are vulnerable and to which attack categories but, over time, this knowledge fades. Many organizations lack the in-house expertise to conduct penetration tests every time they change the web application or WAF configuration (and miss the opportunity to ensure a vulnerability was not introduced).”
SANS issued this report over five years ago. In the intervening years, the frequency of application updates has only gotten higher thanks to increased adoption of agile software development and DevOps. This means that the window of time during which a WAF configuration should not require updates due to application changes has dramatically decreased.
Missed attack due to configuration complexity
The same SANS report notes that it’s not uncommon for WAFs to be extended to cover more applications than they can handle, to fail under high load, or to have a high number of false positives. For this reason, some organizations configure their WAFs to alert only in the event of a potential attack, rather than try to block it — which means that a successful attack will likely be missed in the midst of other alerts from the WAF.
There are definitely still benefits to deploying WAFs, including avoidance of denial of service attacks and—when properly configured— some protection against an attack. If nothing else, they slow an attacker down.
No application security silver bullet
Effective application security requires multiple technologies that protect apps in different ways and in different stages of their lifecycle. As Veracode Community member, Glico Man, said in a recent comment, “WAF is a ‘safety net’ and may provide ‘virtual patching’ until the application code is fixed… A well-configured WAF will provide more time for a developer to fix their code.”
If you’re going to use a WAF, you won’t be protecting your products from attack indefinitely. So use the time a WAF gives you wisely; figure out where the underlying vulnerabilities are in your application and fix them. For instance, consider an automated application security solution that integrates into your SDLC, allowing developers to find and remediate security-related defects early in the development process.
Cyberattackers are increasingly focused on the application layer; it’s critical to understand both how this layer is being exploited, and which solutions protect it most effectively. To learn more about application security solutions and where to start, check out the Ultimate Guide to Getting Started With AppSec or visit the Veracode Community page.
