How does a WAF mitigate vulnerabilities?

In our forthcoming State of Application Delivery 2018 report, we note that the use of web application firewalls (WAF) has been steadily increasing for years. That’s a good thing, because apps today are the gateway to customer and corporate data and traditional methods of controlling access at the network layer aren’t enough. That’s because increasingly bad actors are targeting identities and applications themselves to mine for that digital gold.

So how, exactly, does a WAF mitigate all those vulnerabilities that keep cropping up like weeds in the garden? There are three primary methods a WAF uses to detect and prevent web attacks: deny/allow requests, inspect and reject, and signatures.

Let’s explore each, shall we?

Deny/Allow Requests

The deny/allow requests method is very much like the traditional doorway model used by network firewalls. Requests are either denied or allowed based on available information. That information might be simple – like an IP address – or it might be more complex and specific to HTTP, like OPTIONS or METHODS.

• Black/White Lists 
  If you know a bad actor is coming from a specific IP address or range of IP addresses, block them. If you know an application is only authorized to receive requests from a specific IP address or range of IP addresses, only allow those. This is the simplest method of protection, and relies on a fairly static set of information: the IP addresses/ranges from which requests should or should not come.
  
  If you’re thinking, well, why not just use a network firewall to do that? After all, it’s what they do. On-premises, that works great. But if you have apps you need to protect in the public cloud, that might not be an option. And if you’re one of the 59% of those in our State of Application Delivery 2018 survey already invested in 2-6 different cloud providers, you can’t count on the network firewall policies being the same across providers. While you can certainly implement the same rules in multiple clouds, enforcing rules at a WAF means you can use the same policy in the same WAF in multiple environments. Consistency is key to security success and scale.
• Restricting Options 
  HTTP relies on a set of headers to instruct the app platform (and app) what the user wants to do. HTTP METHODS, for example, can be used to GET, PUT, POST, and DELETE resources. The OPTIONS field, too, has an RFC-restricted set of values that can be easily controlled by a WAF. Some vulnerabilities – like Optionsbleed – exploit these fields. To eliminate the ability to exploit such vulnerabilities, you can use the WAF to restrict the possible values to only those you need to allow for proper execution of the application. In some cases, the WAF – by default – restricts these values. For example, BIG-IP ASM (F5 WAF) by default does not allow the HTTP OPTIONS methodat all.

Signatures

Signatures are another method of protection common to many different security solutions. Anti-virus and anti-malware services rely on signatures that enable them to quickly scan for evidence of viruses and malware and flag them. IPS/IDS, too, rely heavily on this method, as do WAF. There are two kinds of signatures: user-defined and vendor-managed.

• Vendor-managed 
  Vendor-managed signatures are usually kept in a “database” that is automatically maintained by the vendor. This includes updated the database when new vulnerabilities can be identified by a unique, digital signature. A WAF will scan an incoming request against the database and act accordingly if it discovers a match with a signature in the database. Signatures can be purely plain-text, but are more often complex combinations of obscure strings that represent malicious code that trigger remote execution capabilities or otherwise corrupt the app platform and provide access or deny service.
• User-defined 
  User-defined signatures enable operators to quickly add a signature to the database. This capability is important to ensure rapid response (zero-day in many cases) to new vulnerabilities as well as to mitigate vulnerabilities for which a vendor-managed signature has not yet been issued.

Inspection

Finally, inspection is included to ensure complete control over requests (and responses). Inspection of requests allows the WAF to compare information in the request against known good/bad strings and values to determine whether the request is malicious or legitimate. For HTTP applications (which means most of them on the Internets today) this is the most important capability a WAF should provide. If a WAF does not offer programmable inspection, you’ll want to reconsider that choice. Because HTTP is text-based and extensible, there is virtually no way to provide a comprehensive “checkbox” list of options and methods that you can use to inspect requests. Very few HTTP headers have restricted options, making it very difficult to limit what can and cannot be stuffed into it. That means inspection is often required in order to sniff out malicious code embedded in headers or in the payload itself. There are two ways to use inspection: known headers and payload.

• Known Headers 
  There are a set of well-defined headers that every HTTP request carries with it. Host, User-Agent, Content-Type, etc… are almost ubiquitous. Each is little more than a string of text, with such a wide variety of combinations that it is difficult to white list values and instead must be individually scanned for malicious-looking values. Generally speaking, a WAF can very quickly parse out the HTTP headers and enable their inspection. They are at the beginning of every request and they have been known to be used to commit a variety of attacks against app platforms: ApacheKiller, Optionsbleed, and Apache Struts amongst the better known vulnerabilities.
• Payload Inspection 
  Payload inspection is as it sounds: it inspects the entire payload – from the first byte to the last – for known combinations of alphanumeric data that indicate an attempt to exploit a vulnerability. Payload inspection enables operators to examine custom HTTP headers as well as the body of a request for specific indicators of malicious activity. This requires that the WAF first hold the entire contents of the request. This is necessary because packets only hold so much data, and if the malicious data spans two packets, it can go unnoticed by services that merely inspect on a packet-by-packet basis. By inspecting the entire payload, a WAF ensures that no matter where the malicious data occurs, it can be ferretted out and prevented from reaching its target.

A WAF can do a lot more than mitigate vulnerabilities to protect applications. Many also include bot detection, rate limiting, DDoS prevention, and more. But the core purpose of a WAF is to protect applications by mitigating vulnerabilities. While SQLi, XSS, and CSRF are usually mentioned, these are nearly “old hat” at this point. Bad actors have moved beyond the obvious app vulnerabilities and begun targeting the platforms because they offer a much bigger pool of victims from which to mine. Platform vulnerabilities – those in HTTP and its frameworks – are a growing source of breaches that benefit from the protections provided by an enterprise-class WAF.

By employing traditional deny/allow and signature-based scans with the ability to inspect a complete request (and response), a WAF provides the protection business needs today to keep itself – and its customers – safe.