Web Application Firewall Bypass

Description

Web Application Firewall (WAF) bypass refers to techniques that allow attackers to deliver malicious payloads past a WAF's detection rules to a vulnerable backend application. WAFs operate by matching request data against patterns known to be malicious — SQL keywords, XSS payloads, traversal sequences — but these pattern matching rules are applied to a specific representation of the request. Any encoding, obfuscation, or protocol feature that causes the WAF and the backend application to interpret the same request differently creates a bypass opportunity.

CWE-693 — Protection Mechanism Failure is the applicable weakness: a deployed security control is circumvented, and the application behaves as if no WAF were present. Under A05:2021 — Security Misconfiguration, OWASP notes that security controls must be correctly configured and their limitations understood — a WAF that is bypassed is not a misconfiguration of the WAF per se, but of the security architecture that relies on the WAF as a primary defence rather than a defence-in-depth layer.

WAF bypass findings are typically reported in combination with an underlying vulnerability (SQL injection, XSS, LFI). The bypass itself is not exploitable without the underlying flaw, but confirming the bypass is important because it means the WAF provides no protection for that vulnerability in practice.

How It Works

URL encoding and double encoding:

# Blocked by WAF
GET /search?q=<script>alert(1)</script>

# WAF bypass — double URL encoding
GET /search?q=%253Cscript%253Ealert(1)%253C%252Fscript%253E
# Backend decodes twice: %25 → %, then %3C → <

Case variation for SQL keywords:

-- Blocked
SELECT * FROM users WHERE id=1 UNION SELECT 1,2,3--

-- Bypass
SeLeCt * FrOm users WhErE id=1 uNiOn SeLeCt 1,2,3--

Comment-based obfuscation in MySQL:

-- Bypass using MySQL inline comments to break keywords
UNION/**/SELECT/**/1,2,3--
UN/**/ION/**/SE/**/LECT/**/1,2,3--

HTTP parameter pollution — some WAFs inspect only the first occurrence of a parameter, while backends use the last or merge all values:

# WAF inspects first 'id' (clean), backend uses last (malicious)
GET /item?id=1&id=1+UNION+SELECT+1,2,3--

Unicode normalisation — applications that normalise Unicode characters before processing may accept codepoints that visually represent dangerous ASCII characters:

# Unicode fullwidth characters that normalise to < and >
GET /search?q=＜script＞alert(1)＜/script＞
# Fullwidth: U+FF1C = ＜, U+FF1E = ＞

Chunked transfer encoding — HTTP chunked encoding splits the request body into chunks. Some WAFs inspect the reassembled body incorrectly or do not handle chunked encoding, causing them to see a different body than the application:

POST /login HTTP/1.1
Transfer-Encoding: chunked

4
user
5
=admi
1
n
0

Tools like sqlmap with --tamper scripts and wafw00f + bypass-firewalls-by-DNS-history automate WAF fingerprinting and bypass testing.

Impact

• Complete WAF neutralisation — once a bypass is established for a specific payload, the WAF provides no protection for that attack vector.
• Exploitation of underlying vulnerabilities — any SQL injection, XSS, or command injection that the WAF was blocking becomes fully exploitable.
• Alert evasion — payloads that bypass WAF rules also bypass WAF-generated security alerts, making the attack invisible to security monitoring teams that rely on WAF logs.
• False confidence — WAF bypass findings reveal that security posture assessments based on "we have a WAF" are incomplete.

Detection

1. Fingerprint the WAF — use wafw00f to identify the WAF product and version. Research known bypasses specific to that product version.
2. Test encoding variants — for each blocked payload, systematically test URL encoding, double encoding, HTML entity encoding, UTF-8 overlong sequences, and Unicode equivalents.
3. Test HTTP-level obfuscation — test chunked encoding, abnormal content types, parameter pollution (multiple parameters with the same name), and HTTP/1.0 versus HTTP/1.1 differences.
4. Use sqlmap tamper scripts — run sqlmap with multiple tamper scripts targeting the identified WAF type: --tamper=space2comment,between,randomcase,charencode.
5. Fuzz the WAF rule boundary — for a blocked keyword like UNION, submit variations (uNiOn, UN/**/ION, UNION%00) until a variant passes, then use that variant to test the underlying application.

Remediation

Fix the underlying vulnerability. WAF bypass findings are only exploitable because an underlying vulnerability exists. Parameterised queries, output encoding, and input validation eliminate the root cause regardless of whether the WAF is bypassed.

Implement WAF in blocking mode with regular rule updates. Ensure the WAF is in blocking mode (not detection-only), subscribed to vendor rule updates, and configured with the application-specific virtual patching rules recommended for your framework.

Add application-layer defence-in-depth. Deploy multiple complementary controls: parameterised queries prevent SQL injection, Content Security Policy limits XSS impact, and rate limiting reduces brute-force risk. A WAF bypass against one control does not compromise all controls simultaneously.

Test WAF effectiveness periodically. Include WAF bypass testing in your annual penetration test scope. A WAF that has never been tested for bypass may be providing far less protection than assumed.