In WAF we (should not) trust

Deep dive into Web Application Firewall (WAF) bypasses, from misconfiguration exploitation to crafting obfuscated payloads. We show the impact of the parsing discrepancy between how a WAF reads a request and how a backend executes it. It is not a bug, it is a feature.

Deep dive into Web Application Firewall (WAF) bypasses, from misconfiguration exploitation to crafting obfuscated payloads. We show the impact of the parsing discrepancy between how a WAF reads a request and how a backend executes it. It is not a bug, it is a feature. Introduction You just finished configuring your brand new Web Application Firewall. You are now protected from attackers, or so you think. Maybe your applications have weaknesses, but the WAF has your back... Right? Throughout this article, we will demonstrate different ways to bypass a WAF. What is a WAF and How Does it Work? Before we begin, let us review the basics of what is a WAF and how it works. A Web Application Firewall (WAF) is a specific form of application firewall that filters, monitors, and blocks HTTP traffic to and from a web service. By inspecting HTTP traffic, it can prevent attacks exploiting known web application vulnerabilities such as SQL injection, XSS, file inclusion, and security misconfigurations. At its core, a WAF is a reverse proxy operating at the application layer (layer 7 of the OSI model ). Every HTTP request passes through it before reaching the backend. Unlike network firewalls which operate on IP and port rules, a WAF understands the application layer. It reads HTTP headers, query parameters, cookies, and request bodies. The following diagram describes the workflow of a request as it passes through a WAF: Web Application Firewall (WAF) Workflow To summarize, a WAF is a succession of filters: Blacklist Check : Before inspecting anything, the WAF checks static lists of blocked IPs, user-agents, countries, or known malicious headers. If the sender matches any entry, the request is dropped immediately. No further processing occurs. Penalty Box : Clients previously flagged for suspicious behavior by scanning patterns, brute force attempts, etc., are temporarily banned. This list is maintained dynamically and is based primarily on IP address and User-Agent. Once you land here, every subsequent request is blocked regardless of its content. Rate Control : Too many requests in too short a time window triggers throttling, blocking, or a challenge (CAPTCHA). This layer protects against brute force and volumetric DDoS at the application layer. Client Reputation : Dynamic scoring based on the sender's history. Known Tor nodes, botnets, flagged IPs, behavioral signals across the WAF's global network. Parsing & Inspection : If the request survives the above layers, the WAF decodes it. URL encoding, body format, chunked transfer, compression, etc. and runs it through its ruleset. Three detection models are used: Signature-based : Regex patterns matched against known attack strings. The OWASP Core Rule Set (CRS) is the most widely deployed baseline, used by ModSecurity, Cloudflare, AWS WAF, and others. Anomaly scoring : Instead of blocking on a single match, the WAF accumulates a score across multiple partial matches. A request only gets blocked when the cumulative score exceeds a configured threshold. This reduces false positives while maintaining coverage. Custom rules : Defined by the operator are evaluated in this same phase, after the default ruleset. Decision : If the request was not blocked by any previous layer, a final decision is made based on the accumulated score. Allow the request through to the origin, block it with a 403, challenge the client with a CAPTCHA or browser integrity check, or log it silently for review. The action depends on the WAF's configuration and the severity of the score. The overall architecture is close enough to this one for all WAFs. Now, you know enough to be able to play with a WAF. Knock Knock. Who's there ? Mis(s)config When discussing WAF bypass techniques, the first ideas that usually come to mind are payload obfuscation, encoding tricks and fuzzing. While these techniques are widely documented and sometimes effective, they might not be the best in real-world scenarios. Finding a payload that consistently bypasses detection requires a high number of requests, which generates: Large volumes of suspicious requests. Anomalous traffic patterns. Elevated WAF logs and alerts. From a defensive standpoint, these behaviors are easy to detect. From an offensive standpoint, they significantly increase the risk of early detection, IP blocking, or session invalidation. So let's discuss some alternative techniques. Direct Origin Exposure Our first technique is the most straightforward. Instead of trying to bypass the WAF's rules, we just ignore it entirely. By directly targeting the origin server, every request reaches the application without ever passing through the WAF, nullifying all of its security protections and potential logging. This exposure can occur for several reasons: Historical DNS records still pointing to the origin IP. : Passive DNS databases continuously archive DNS resolutions over time, including records that predate a CDN or proxy setup. Querying these databases can reveal...