Web Application Firewalls are popular for DevOps and Security Ops teams. They are also one of the most misunderstood and are often implemented incorrectly. I’ll explain what a Web Application Firewall (WAF) is and how to best to set one up.
Web Application Firewall: A Brief History
WAFs rapidly gained popularity in the 2000s after Mozilla developed open-source ModSecurity. Before ModSecurity (distributed commonly as an Apache HTTP module), most implementations of Web Application Firewalls were expensive proprietary software. ModSecurity brought WAFs to the masses and was many administrators first experience with this type of tool. Soon after, PCI-DSS, a popular compliance standard for the credit card industry, recommended Web Application Firewalls for satisfying some of its compliance requirements. This added to the growing popularity.
Gartner, through its Magic Quadrant Report, estimates that the total WAF market was valued at “about $626 million in 2016, representing a growth of 21.3% compared to 2015.”
Today, WAFs evolved far beyond their modest offerings with a range of modern features including rate-limiting, bot detection, session management, and many rich options for request inspection.
Popular, Misunderstood, Abused
A common misconception is that all the security concerns become satisfied when a WAF integrates with an application. That is simply not true. For starters, a WAF can only supplement and never replace a proper security posture. Also, a WAF deployment is only the beginning of the story. WAFs need regular maintenance and monitoring (sometimes called “tune-ups”). A proper WAF deployment will always consider regular tune-ups as part of the complete package.
Unfortunately, this puts many teams in a precarious position where an improper WAF deployment gives a false sense of confidence. WAFs are very valuable when integrated correctly but not enough teams are doing it right. I believe this is because we commonly misunderstand a WAF’s role in a full security stack is.
For example, let’s take Cross-Site Scripting (XSS) and SQL Injection (SQLi) attacks. Simply put, XSS and SQLi attacks occur when the attacker packages executable code into an HTTP request and tricks the victim to run it. Any modern Application Framework (like Django or Ruby On Rails) has preventive measures built-in to prevent these attacks. Usually these measures work by treating any data from a user’s request as “untrusted”. WAFs can also prevent XSS and SQLi but works much differently. A WAF eliminates the same attacks by filtering out anything that looks like code that the attacker is packaging in the request. Sounds like the security precautions of the Application Framework is redundant.
So, now it sounds like the WAF is pretty useless, right? Just use the mitigation that the Application Framework provides. But, developers can still incorrectly configure these security rules or add exceptions that could be unintentionally dangerous or maybe there’s a bug in the framework.
While helpful for common web-based attacks, WAFs are really better suited to help support better prevention measures. WAFs are not a “set it and forget it” kind of security tool which is why it saddens me to see this mistake repeated over and over.
Are WAFs overhyped then? What major advantage can a WAF bring to a Security team?
For starters, the WAF market today has a diverse, rich set of features and any team can probably find a unique product offering that adds value to their security posture. There’s no denying that.
However, I think it is important to point out one very valuable intrinsic feature that all WAFs have because it’s key to properly understand these systems. It is also the one thing teams should emphasize during a WAF deployment. That very important feature of a WAF is the ability to patch zero-day vulnerabilities.
Imagine the example from earlier where a web application is built in a framework like RoR or Django. It could also be written in something like React. By nature of using a modern framework, many common web-based attacks are preventable. However, let’s say a severe vulnerability is discovered for your framework of choice. The framework developers are frantically trying to release a patch but it could be a full day before it you receive it. Even still, the patch may need testing in your environment. What if your version of the framework is a major version behind? You may never get the security patch at all. This is a very common scenario and one I’ve ran into many times in the past.
With a WAF, a new rule that filters out any attempts to exploit the zero-day will manage these kind of situations. This can give your Development and Security teams more cover time to properly develop, test, QA, and ultimately deploy a proper fix. I believe this is the true power of a well thought-out WAF deployment and can save your team from a future of pain.
As Web Application Firewalls have gotten more popular, they’ve also become commonly misunderstood as a “one stop shop” for application security. Because of this, unfortunate situations tend to develop where teams will install a WAF and never think of Application Security again. Web Application Firewalls are best used to supplement a team-wide discipline at every level of the stack. This is the DevOps approach to security.