Web application firewalls (WAF) is a protection mechanism to help block potential malicious requests before they can reach the application itself. Often this is implemented as a proxy, intercepting HTTP requests, analyzing them, and finally deciding on an action.

While effective, over relying on it could lead to a false sense of security that allows attackers to exploit unresolved internal issues. In this blog we’ll give a penetration tester’s perspective of WAF implementations, our problems with them, general bypass, and other issues encountered.

How WAFs interfere with accurate penetration testing

Often, WAF’s are regarded as a penetration tester’s worst enemy, blocking requests that are common during an assessment. While this can be seen as a slight inconvenience from a non-penetration testers perspective, us practitioners often see this as a problem.

When auditing the application’s security, it’s important that as much as possible is covered during the assessment. With a WAF in place, certain issues become difficult to test, preventing a professional from identifying existing vulnerabilities.

While the WAF might block a cross-site scripting (XSS) attempt in an input field, the application itself might not properly sanitize the input correctly. Therefore, if the WAF is bypassed, an XSS attack is still possible, something that might have been identified if testing was done without the protection of the WAF.

Bypassing the WAF

As with any application security product, researchers as well as attackers will always find issues and ways to bypass them. WAFs are no exception to this, especially due to their common occurrence in modern applications.

It’s a common practice to whitelist internal networks from WAF’s, to ensure internal services or users are not being incorrectly stopped by them. Problems arise if an attacker can spoof their IP address in any way, often due to misconfiguration or mishandling of HTTP headers. Often this is done by adding headers containing IP addresses that, when examined by the WAF or an intermediate proxy, will be interpreted as an internal resource.

Many WAFs have a set limit for how many bytes of an incoming HTTP request they can analyze. For requests larger than this limit, it’s recommended to treat them as malicious, however this is not always the case. An attacker could then bypass the WAF entirely by sending an oversized request, along with malicious content.

These common bypasses can be solved with a secure and robust configuration. However, encoding or obfuscation bypasses are harder to remediate, and therefore the application security needs to be good without the WAF´s help.

Not all vulnerabilities can be stopped

While WAFs are optimized to stop malicious requests, they do not consider vulnerabilities that abuse legitimate actions.

Attacks against the application’s underlying logic will often involve no malicious payloads and instead focus on manipulating the underlying system to perform unintended actions. Actions such as sending requests out of order, repeating requests, or redeeming gift cards are all treated as legitimate requests by the WAF. Therefore, manipulating them and their logic is not detected or stopped.

Authorization issues are also something that WAF will not help protect against. Just like logic flaws, authorization issues are underlying misconfigurations, in this case regarding access control, something that the WAF does not consider. It will just see a valid a user trying to access a resource it should be able to access.

Want to know more about business logic vulnerabilities? Have a look at our recent blog post covering it: Business logic attacks: The silent future of cyberattacks

Issues caused by custom WAFs

Most WAFs are provided by external vendors, but sometimes a smaller service or application can have their own WAF implementation. For a WAF to work effectively, proper configuration is essential, especially for custom implementations. Often, the standard bypasses work for these as well, along with being able to manipulate the WAF to do unintended actions.

These issues often arise when the custom implementation is used together with other proxies. The proxies can be services such as caching services and load balancers, that when combined with the WAF, start acting strangely.

During an assessment, a custom WAF implementation through the service was found to behave strangely with the load balancers in place. The IP addresses in the WAF block responses did not match those of our testers, and slowly functionalities of the site stopped working. After an investigation it was discovered that the WAF was banning the load balancers one after one, instead of the actual source of the request.

This is just one example of many unintended issues that can arise.

WAFs have their uses, but don’t be complacent

WAFs do fulfill an important role in the application security ecosystem but should not be seen as the ultimate solution to all security issues. The underlying security of the application needs to be strong for the firewall and other external protections to be as effective as possible.

To ensure this, regular security audits are needed, without the WAF enabled, to ensure that the standards of the application are up to par. This will ensure that even in the worst-case scenario, if the WAF is bypassed, the application will still properly handle malicious requests.

With Outpost24’s SWAT solution, you can automatically and continuously monitor your internet-facing web applications for the latest vulnerabilities. Results are verified by our certified pen testers to avoid frustrating false positives. The solution can be fully customized to your needs, minimizing unnecessary load, or risk to any sensitive environments.

You can also interact directly with our security experts for validation and remediation guidance, all via an easy-to-use portal. Book your live demo today.