What is WAF?
Web application firewalls (WAF) sit outside of web applications in production, and inspect incoming traffic. They pattern match all incoming traffic against a ruleset of malicious traffic patterns, and either block traffic or allow it to pass, depending on the result.
How did WAFs come about?
A traditional perimeter firewall will only open the common ports (such as 80 and 443) to enable user access and interaction with the web application, but does not have the ability to stop attacks like SQL injections, for example. This is why WAFs came into the picture. In the 90’s, WAFs were developed as a filter in front of a web application to interpret, inspect, and monitor incoming HTTP traffic for potential attacks and malicious activity which may damage, take down or steal sensitive information. They aim to protect against cross-site forgery, cross-site-scripting (XSS), file inclusion, and SQL injection, among other attacks.
A WAF can be designed to shield a specific web application or multiple applications, and it operates based on a set of rules, also called policies, which are used to filter out common attacks. Many external WAF services provide a default ruleset, which they update periodically, but users can (and should) modify their ruleset to suit the needs of their business.
What are the different types of WAFs?
WAFs can operate on a negative security model (a blacklist) or on a positive security model (a whitelist). When a WAF operates on a blacklist, it protects against known attacks and denies access to malicious content. When it operates on a whitelist, it only admits pre-approved traffic. Many WAFs offer a hybrid security model to harvest the advantages of both models and mitigate the drawbacks.
As far as implementation is concerned, web application firewalls can be:
- : which minimizes latency since it is installed locally, but it is an expensive option as it is hardware-based requiring storage and maintenance, and demands all security expertise be in-house.
- : when a WAF is integrated into the server, which can increase consumption of local server resources, implementation complexity, and maintenance costs. Also called “next-gen WAFs”
- : which is easy to implement with minimal upfront cost. Cloud-based WAFs operate as reverse proxies. The providers takes care of the necessary updates to protect against the newest threats without additional work or cost for the web application owner. However, if the application owner wants any customized rules or specific protections, maintaining the WAF can become a big effort.
- : which sits inside the application and has the full context of the application. This removes the need for configuration and maintenance and will not generate false positives like the other types of WAFs.
WAFs can be customized for specific applications. However, the effort can be significant and maintenance will be needed with every application modification that you do.
How does a WAF work?
A WAF is a type of reverse proxy. It intercepts and analyzes every HTTP request before they reach the web application. Unlike traditional firewalls, WAFs are specifically designed to sit in front of the public side of your web applications to protect them, not the servers, because they focus on the application layer (layer 7) of the OSI Model.
WAFs can have many blocking features and rulesets which protect against attacks such as:
- WAFs attempt to secure the web application against SQL injection and cross-site scripting attacks, as well as cookie, session, or parameter tampering attacks, and any other which may try to exploit the vulnerabilities in web properties. WAFs also offers object-level identification and blocking which can stop sensitive data theft. Session management protection: WAFs enforce session duration timeout, inactivity timeout, and warn about hijacking attempts
- In order to protect web session data, most web traffic is encrypted, but many hackers also use HTTPS as a camouflage. WAFs are designed to perform SSL termination. SSL certificates are hosted on the WAF, thus terminating the encrypted connection. The WAF can analyze the received traffic before sending it to the web application in HTTP. The response is sent back to the WAF which encrypts it and forwards it to the user using HTTPS.
- WAFs protect against the risk of application-layer denial and distributed denial of service (DDoS) attacks. They can also identify and block malicious XML attachments and validate the schema for SOAP messages and XPath queries. Furthermore, WAFs enable compliance with the requirements of Payment Card Industry Data Security Standard (PCI DSS).
Defining and maintaining a ruleset is the most challenging and time-consuming part of running a WAF. There are some open source rulesets and WAFs available, however, which can work as a good starting point for those interested in this method of application security.
What are the main advantages of using a WAF?
A web application firewall is designed to monitor or block attacks in production. It acts as a protective outer shell for the application against attacks on its own vulnerabilities as well as on external vulnerabilities such as in the client’s operating system or the web server. By operating solely on the perimeter, WAFs have no impact on the application itself outside of any traffic they block.
WAFs ensure that traffic is analyzed before it penetrates the perimeter, and, if well set up and maintained, ensure that most attacks will not reach the application.
Another considerable advantage is that the ruleset the WAF operates on can be modified and customized by internal security experts with the most information about what constitutes an attack for the particulars of the application. This enables the security team to pattern match against very specific types of traffic, and patch the vulnerabilities uncovered during pentests or code reviews before they can be exploited, if the deployment of the corrected code needs to be scheduled at a later time.
What are the main drawbacks of using a WAF?
The major drawback of WAFs is that their efficiency only goes as far as their configuration allows. If the configuration settings (whether in a blacklist or whitelist) are too loose or too tight, they result in producing false negatives or false positives, thus, letting in malicious requests or blocking legitimate traffic. “Perfect” configuration is an elusive goal as well, so the signal-to-noise ratio is poor.
Furthermore, the configuration needs to be maintained, regularly as a general rule and as often as the application evolves. For a modern application using agile methodologies, this means near daily work. The challenge for the maintenance team is to keep up with the evolutions and be thorough in anticipating the impacts from a web application security standpoint. This reality forces companies to most often use a WAF in monitoring-mode only, because the risk of blocking legitimate traffic is too great.
As a perimeter protection, WAFs can only compare traffic to designated rulesets. They don’t have access or visibility into any of the context of the application itself. This means they can only block what looks like an attack, but not necessarily what actually is an attack. That distinction is what leads to a lot of the false positives or missed attacks. An additional consequence of this is that WAFs can’t protect against 0-day attacks or address vulnerable dependencies.
Are WAFs alone sufficient to ensure web application security?
WAFs provide one element of application security, but alone are insufficient for protecting web applications. With a poor signal-to-noise ratio, complex maintenance, and a lack of visibility into vulnerabilities and applications, WAFs cannot be relied on for all your application security needs.
However, WAFs are well suited for protecting against basic types of application threats, and if used as one layer in a defense-in-depth approach alongside elements like [RASP](link to What is RASP) and CSPs, WAFs can provide value.