The WAF Guidebook: What is a Web Application Firewall?

Simply put, Web Application Firewalls are security controls designed to provide the best automated operational protection for HTTP applications, whether web based on mobile. What is “the best” protection, or even “sufficient protection” is not a simple question.  As a result there is a spectrum of solutions for protecting web applications with varying quality and functionality. Which one can call itself a web application firewall is not an easy question to answer.

Probably the only way to define a web application firewall is to list the key features common to web application firewalls uniquely suited for protecting web and mobile applications and which would differentiate than other operational security controls such as intrusion prevention systems and network firewalls. The following sections touch on those key features of WAFs. A fuller discussion of the features will follow in later posts.

Intimate understanding of HTTP

To provide significant level of security, a web application firewall must understand very well HTTP. In practice, this would imply parsing the HTTP protocol and applying any detection and prevention method on protocol elements such as HTTP headers or parameters rather than on network traffic as an intrusion prevention system would do.

The reason is that it is just too simple to evade detection if based solely on unparsed data. Evasion techniques include for example utilizing different encoding schemes or HTTP parameter pollution. It is important to note that full parsing does not guarantee that evasion is impossible. It just enables the detection engines, if smart enough, to avoid evasion.

All WAFs parse HTTP making it de-facto the minimum criteria differentiating a WAF from an IPS.

Insight into web and mobile applications

Understanding HTTP is not enough. Good protection for web and mobile applications require understanding the application itself. While HTTP is a well-defined standard and a WAF can “understand it”, applications vary and a WAF cannot normally understand the application in its entirety. Moreover, one of the key aspects of web application protection is the need to protect custom fast changing applications, making the challenge of “understanding” application much bigger.

Nevertheless, a WAF should be able to accommodate several key attributes differentiating one application from the another:

  • Custom parameters, for example JSON or XML based parameters – this would enable parsing parameters and applying rules on a parameter level for non HTTP standard parameters schemes.
  • Expected inputs for the parameters – this would enable whitelisting of web requests, similarly to how a network firewall would whitelist traffic between systems.
  • The application flow which would enable enforcing valid user flow in the application and prevent direct access to pages and resources. The application flow will include information about which requests are valid at what pages, what page can link to another and what parameters are valid in each request.
  • The application authentication scheme and session management which is required to identify users, enforce permissions and track user activity. The authentication and session management scheme includes among other things the logon page and how to extract the user name in it, what parts of the application are intended only for authenticated users and what is the session identifier embedded in each HTTP requests tying it to a user session.

Understanding all of this is a major challenge for WAFs. One solution is to require the user to configure the data, for example tell the WAF what is a login page. Alternatively, the WAF can utilize heuristics or learning – if a page includes a password field (which HTTP identified) it is a login page. Lastly, modern web application frameworks such as ASP.NET, AngularJS or Ruby on Rails or development libraries such as jQuery define or help identify many of those aspects for web applications developed using the framework.

Understanding applications is what differentiate full-fledged WAFs from entry level WAFs, the latter of might be better called “HTTP aware IPS”.

Broad application visibility

To have intimate understanding of HTTP and the web application, a WAF needs to have visibility into the application. The most common way to get such broad visibility is to be located in-line between the application users and the protected web server, potentially as an intermediate cloud service. It is important to note that such a deployment method does not provide full visibility, for example the WAF does not have access to internal application state variables. In addition, the solution must decrypt SSL traffic, which is possible but may break security requirements such as non-repudiation.

An alternative is to have the WAF implemented as a web server or application server plug-in. While this method has advantages for both SSL and state visibility it inherently leaves some processing in the web server exposed as it would happen prior to the plug-in activity. Most notably it would be harder to provide denial of service mitigation in such a setup. In practice such WAFs do not enjoy the same level of market penetration and hence maturity as their network based siblings.

Multiple detection methods

Nothing is as controversial as what are the most important detection methods a WAF should provide.

Blacklisting

All WAFs support signatures or rules to detect attacks. Rules allow setting more complex conditions which enable utilizing the HTTP and application understanding described above. As an example rules may enable combining conditions over several HTTP fields or across multiple requests in a single session. Common rules would attempt to detect SQL injection or XSS attack strings.

WAFs heavily rely on the quality and relevance of the rules or signatures themselves, whether supplied by the WAF vendor or obtained elsewhere. Assessing the quality of signatures is very hard and in most cases users need to rely on the reputation of the vendor for that.

Whitelisting and virtual patching

To avoid the challenges of getting and maintaining effective rules and to better adjust to custom applications, WAFs allow setting a policy to allow only certain inputs or flows, for example that a page or a request accepted only specific parameters with specific data types and ranges, or that to a certain page one can get only if authenticated and coming from a set of other pages. This method is often called “positive security” and is similar in nature to how network firewalls work with regard to access to systems.

Whitelisting provides a high level of security but is very hard to configure as the policy would have to mirror the structure of the application. There are several learning methods that facilitate creating such a policy though none is bullet proof and effortless. As a result, a common use case for whitelisting is selective use of white listing for virtual patching in which a white listing policy is applied to a limited part of the application in which there is a known security issue.

Rate, score and behavior based detection

Both black listing and whitelisting are best suited for simpler, syntax level attacks within a single request or a short session. Modern threats to web applications are in many cases at the application logic level and focus on abuse of functionality. An example would be automation attacks such as web spam and click fraud.

Those attacks are harder to detect because they utilize valid application functionality and because as a result differentiating between a valid user and a malicious user is much subtler.

A solution for that would be to profile the behavior of an actor over time to determine if it is a malicious actor. Specific examples of behavioral profiling may be to track its activity rate or to score the risk associated with its activity.

Behavioral based detection is strongly coupled with challenge/response reaction as such a reaction provides a better mitigation option for incidents which cannot be classified as black or white.

Granular policy management

Since web applications are complex and dynamic, any detection method is prone to generate false positives. To avoid sweeping exclusion of rules and policies, the system must be able to enable setting granular exception. Particularly, exceptions should be set to small parts of the application such as a page, a request or even a parameter.

Yes, no and maybe responses

Most security controls offer “pass” and “block” responses. WAFs should offer a 3rd option in the form of a challenge/response mechanism. This would enable handling situations in which the certainty of detection is not absolute. Such a challenge/response mechanism can be a downloaded code that will differentiate an automated client from a browser or an interaction with the user to verify her identity.

In Summary

The list above does not imply that every WAF would have all those features. This article does not even try to define a minimum set of features. However, a mature WAF will strive to include as many of them as possible. Conversely, WAFs support many other features ranging from Geo IP based protection to SIEM integration. Those contribute significantly to the quality, usability and protection provided by the WAF, but are not unique to a WAF and therefore are not discussed in this article.

Lastly, any discussion of WAFs needs to touch on the common confusion between web application firewalls and application firewalls. While the name is far too similar, those are very different security controls. An application firewall, or more precisely “an application aware firewall” is a network firewall that can base its policy not just on IP port information but also on identifying the application. The policy itself is still limited to controlling access to applications as a whole and the focus is standard rather than custom applications.

2 thoughts on “The WAF Guidebook: What is a Web Application Firewall?

  1. Pingback: Anniversary to the ModSecurity Core Rule Set celebrated with a new major release | InfoSec aXioms

  2. Pingback: Anatomy of a SIEM use case: the brute force example | InfoSec aXioms

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s