When conducting a web security audit, it is common to encounter a WAF (Web Application Firewall), a security layer designed to detect and block exploitation attempts. While this protection adds security to the application, it can also significantly hinder the auditor’s work, preventing the validation of the real impact of certain findings.
In this post, I’ll share some of the tricks and techniques I use when auditing applications protected by a WAF, but before diving into that, it’s important to understand what a WAF is, how it works, and its limitations.
what is a waf and how does it work?
A WAF (Web Application Firewall) is a security system that acts as an intermediary between the client and the web application, analyzing HTTP/HTTPS traffic to detect and block malicious requests. Its main purpose is to protect against common attacks such as SQL Injection, Cross-Site Scripting (XSS), Remote File Inclusion (RFI), and other exploitation vectors described in the OWASP Top 10. Unlike a traditional firewall, which filters packets at the network or transport layers, a WAF operates at the application layer (Layer 7 of the OSI model), allowing it to thoroughly inspect the content of requests and responses.
The operation of a WAF is based on applying security rules and policies that identify suspicious patterns in web requests. These rules may follow a blacklist approach (blocking known malicious traffic) or a whitelist approach (only allowing trusted traffic). Many modern WAFs leverage machine learning and behavioral analysis to detect anomalies that do not match previously known patterns. Depending on its configuration, a WAF can run in detection mode (monitoring) or prevention mode (blocking), making it a key component in the defense-in-depth strategy for Internet-exposed applications.
tip 1: use security trails to view historical ip addresses.
An initial technique when auditing applications protected by a WAF is to investigate the underlying infrastructure. For this, SecurityTrails can be used—a platform that provides historical domain information, DNS records, IP addresses, and other infrastructure data. By entering the domain of a WAF-protected website, it is possible that some historical IP records reveal the real server IP, which can be useful for understanding the site’s architecture and planning further tests, always within a legal and authorized scope.
Below we can see an image showing where we need to go when entering the domain
tip 2: exploiting the maximum analysis limit of WAFs.
From my experience, this technique works intermittently, as it depends on the specific WAF implementation. Most WAFs analyze requests only up to a maximum size limit; when the request contains too much data, the WAF does not fully inspect it and allows the request to pass.
For example, in a post by @k_firsov, it is shown how he managed to bypass Cloudflare Enterprise, whose WAF inspects requests up to 128 KB. This allows that if we inject a payload that would normally be detected, we can pad the request with extra data to increase its size, causing the WAF to miss it and letting the request pass undetected.
For this technique, you can use the Burp Suite extension nowafpls, which allows adding extra data to a request to increase its size. The same repository also includes a PoC (Proof of Concept) demonstrating how to bypass an Akamai WAF.
this video was extracted from the repository.
tip 3: create the payload manually
The third tip involves designing and building the payload manually, rather than relying solely on automated tools. This technique is the most challenging, as it requires a deep understanding of the application’s behavior, the structure of requests, and the specific rules enforced by the WAF. By creating the payload manually, it is possible to experiment with different formats, encodings, and patterns to attempt evasion of the security protection.
However, it is important to note that some vulnerabilities may be nearly impossible to exploit, even using advanced manual techniques. The success of this approach depends on the auditor’s creativity and detailed analysis of both the WAF and the application, as well as the ability to innovate by combining multiple evasion strategies.
conclusion
bypassing a WAF is not an easy task. I created this post with the intention of giving readers some practical techniques and strategies that can be used when facing a security audit where the application is protected by a WAF. Although every WAF is different and not all vulnerabilities will be exploitable, these techniques provide a solid starting point for planning more advanced testing and analysis.