Five security attacks WAFs can help you with...

There seems to be a lot of confusion about the role of a Web Application Firewall (WAF) in application security, and what types of threat a WAF can help mitigate in your deployment.

In this brief article, I'll quickly summarise five specific types of security vulnerabilities that a WAF can help you with, as well as some important caveats that need to be carefully considered before deciding that a WAF is the right tool for your use case.

1. Denial of Service (DoS) and brute-force attacks

Any modern web application or API should have some form of request rate limiting as a security measure. This helps to stop automated Denial of Service (DoS) attacks, brute force attacks, and credential stuffing. However, where rate limiting controls are inadequate, too coarse, or not provided at all by the application, this security logic can be provided on an Application Delivery Controller (ADC) such as the Loadbalancer.org appliance using its integrated WAF.

To block these kind of attacks, a WAF looks at requests and determines if the same or similar HTTP request is being made repeatedly, blocking such flood attacks. DoS attack prevention is perhaps one of the best uses of a WAF, since it is often simpler to implement rate limiting on the ADC rather than modifying the application itself, which may not even be possible.

2. Script injection and malformed URL attacks

A WAF can inspect the content of traffic before it reaches web applications, thereby helping to prevent injection attempts such as embedded SQL and JavaScript, and off-site script loading attacks, by filtering out attempts at Remote Code Execution (RCE) and Cross-Site Scripting (XSS).

When suspicious web requests and responses are detected, the WAF will log an alert and if configured to do so, block the injection attempt at the load balancer so that it never reaches the web application. This can help mitigate certain application vulnerabilities in form validation for web applications, although this is no substitute for proper security patches to the application.

3. Attacks from specific IP ranges and geographical regions

Another useful feature of a WAF is that it allows fine-grained blocking based on request characteristics. This permits highly configurable blocking based on the attributes of a connection, such as geolocation or client platform based on the HTTP headers in the request.

In many applications, it is useful to allow only traffic from a particular series of countries, to block all traffic from specific problem regions, or block an outdated version of a client application from connecting. For example, telephony services (e.g. SIP) can be limited only to the geographical regions from which clients are connecting.

This can come in useful in reducing casual attack traffic, but of course, it is trivial for someone to simply use an IP address outside of their geographic region to evade the blocking or to spoof their HTTP headers. The use of a VPN server located in a different region bypasses such filtering, which can also cause legitimate clients to be blocked.

4. Application-specific attacks

Application-specific attacks – sometimes known as "niche attacks" – are related very specifically to a particular application type or product, such MAC Address Provisioning attacks in SIP telephony, or resource consumption attacks on cloud object storage. These are attacks which rely on a specific behaviour, limitation or design characteristic of the particular application being targeted.

These would mostly pass through a network firewall, but can cause a severe impact to both security and service for the application. A WAF allows extremely specific criteria to be set to prevent these.

This can come in useful where the application itself cannot be modified to patch the vulnerability.

5. Unpatched vulnerabilities via "virtual patching"

Using a WAF, it is possible to write specific rules to virtually patch and preemptively fix known issues before a full patch can be applied. These rules detect and block exploit attempts before they reach a web application. To accomplish virtual patching, full details are needed about what an attack would look like to the ADC.

Usually, there is plenty of information available from industry experts, security researchers, and sometimes from malicious actors themselves describing the attack architecture. Virtual patches can be created individually for each identified vulnerability and added to the WAF rule set, as a temporary mitigation until the underlying application is fixed.

The downsides of WAFs

While it can be tempting to assume that adding a Web Application Firewall should be your default choice, it is also important to be honest about the downsides of using a WAF.

1. WAFs can, and do, inadvertently block stuff that’s actually good (collateral blocking) in unexpected and unpredictable ways. For example, older apps do things they shouldn’t do, and so they often trigger WAF rules in an unwanted way.
2. On a high traffic website, WAFs can be very RAM hungry, and in some cases a WAF can cause degradation to performance by acting as a network bottleneck, thereby limiting traffic throughput.
3. If not set up correctly, it is possible for a WAF to become an additional security risk in and of itself, mainly if it is not regularly patched and hosts a vulnerable service. Alternatively, the WAF may be misconfigured in such a way that external clients can access the service that it is protecting whilst bypassing access controls. Additionally, a WAF can actually "amplify" certain attacks – that is, make them worse – by returning many forbidden requests, or acting as a network bottleneck if presented with a large amount of malicious traffic.
4. WAFs are only capable of blocking known attack classes, or at least attacks that follow a defined pattern. Although a WAF can block certain novel attacks prior to software patches being available, it has to know at least the type of group of attack that that involves in its rule set. This fact might sound obvious, but it's often missed: it's important to understand that a WAF will not block a significant proportion of "zero-day" vulnerabilities. Therefore, a WAF does not replace good security practices. The practical protection offered by your WAF might be weaker than you think, which is why regular penetration testing is important.
5. A WAF doesn’t make insecure applications secure. I cannot stress this point enough. There is no WAF on this planet that will ever make them secure, even if it might be able to take the edge off some types of attacks.

In other words, just because you can use it, doesn't mean you should.

Weighing it all up

It is important to fully weigh up the costs and benefits of having a WAF and whether or not enabling a WAF is a useful addition to your security infrastructure. Before embarking on using a WAF by default, first understand what you’re actually trying to achieve.

If you'd like some general advice on WAFs, please feel free to get in touch with our team: we'd be glad to tell you the honest truth, as we have always promised to do for over 20 years.