Why a Definition?
Web applications firewalls are not new. The 1st one was introduced in 1997. But web application firewalls did not receive significant market attention until recently.
One of the primary drivers for web application firewalls adaption today is the Payment Card Industry Data Security Standard or PCI for short. PCI offers WAFs as one of two methods to protect web applications, the other being code review. However, until February 2008 PCI fell short of describing what a WAF is and, and discussed later, the clarification provided is hardly sufficient.
Why would we need to define a web application firewall? After all we use regular firewalls (referred to as network firewalls in this book) and anti-virus software without an exact definition and still get the required protection. The reason is the WAFs are not a commodity yet, and therefore not all of them do the same thing, so while many solutions define themselves as WAFs, they may not be actually doing the same thing and consequentially do not provide the same security benefits.
The Basic Definition
Simply put, A WAF is an operational security control which monitors HTTP traffic in order to protect web applications from attacks.
The key elements in this definition are:
- Operational control - a WAF protects applications in real time, rather than hardening them or fixing them in advance.
- HTTP traffic - a WAF analyzes the traffic between the untrusted client and the web server.
- Protect web applications - WAFs protect web applications. Mostly custom written and very dynamic, web applications are in many cases vulnerable and not well protected by other solutions.
Differentiation
Only by defining the method used to protect applications, a WAF can be differentiated from other security solutions that inspect traffic, most notably IDS and IPS. To be a WAF, a system should:
- Have intimate understanding of HTTP - while not of importance by itself, only by fully parsing and analyzing HTTP, breaking it to its elements including headers, parameters and payload, a WAF can effectively perform the following requirements and avoid evasion.
- Provide a positive security model - a positive security policy allows only things know to be valid to go through. This protection mechanism, sometimes called "white listing" provides an external input validation shield over the application. Too many web attacks cannot be reliably detected using signatures making a signature only solution not strong enough to protect web applications.
- Application layer rules - due to high maintenance cost, a positive security model by itself is not effective enough to protect web applications and should be augmented by a signature based system. But since web applications are custom, traditional signatures targeting known vulnerabilities are not effective. WAF rules should be generic and detect any variant of an attack such as SQL injection.
- Session based protection - one of the biggest downsides of HTTP is the lack of a built in reliable session mechanism. A WAF must complement the application session management and protect it from session based and over time attacks.
- Allow fine grained policy management - most notably, exceptions should be applied to only minimal parts of the application. If a system does not allow minimal exceptions, false positives force opening wide security gaps.
The details of these 5 requirements are discussed in later chapters.
Caveats
Based on the discussion above one may assume that if a WAF answers all the requirements it provides total security for web applications. If only that was true...
Like any other security solution, WAFs provide security up to a point. The usual division is between technical and logical vulnerabilities. WAFs protects well from technical vulnerabilities such as SQL injection, but is usually not effective in protecting from logical vulnerabilities, for example a too simple password reminder question. The border line between the two is not always easy to define and for those issue in the middle a WAF may or may not provide effective security, depending on the specific issue and the WAF technology used.
In addition to technical limits, WAFs also often suffers from implementation issues. For example, it is nearly impossible to define a positive security policy for an application manually. Most automatic processes for generating such policy need to balance false positives and false negatives and therefore may not provide full security.
However, not being a silver bullet solution, WAFs differentiation from alternative operational solutions such as intrusion detection and prevention systems blurs. Why would the differentiators listed above provide the necessary security while others not? This book provides some answers to that.
Other Definitions
Interestingly, not many have tried to define what a WAF is. The most prominent attempt at defining a WAF, is the Web Application Firewall Evaluation Criteria (WAFEC) project, led by Ivan Ristic, the creator of ModSecurity, for the Web Application Security Consortium. Created by many talented people, WAFEC enjoy the wisdom of them all, but suffers from being created by a large group. WAFEC is a list of everything a WAF can include, but says nothing about what it must include.More information about WAFEC can be found in the relevant chapter.
PCI allow using a WAF as one of two options to protect web applications, however PCI itself does not say what a WAF is. The PCI council issued in February 2008 a supplement describing the what a WAF should provide, however this supplement did not make it into PCI 1.2, the latest version of standard. The most important defining requirement the document makes is that a WAF should have both a positive and a negative security models.More information about PCI and WAFs can be found in the relevant chapter.
The leading industry organizations specializing in web application security also provide their definition of a WAF: