By Lesson 4 you know that the canonical payloads - ' OR '1'='1, UNION SELECT, ' OR 1=1-- - are exactly the signatures a Web Application Firewall is trained to flag. This is the cat-and-mouse chapter. Filters are imperfect parsers; SQL is an over-permissive grammar; the gap between the two is where every WAF bypass lives.
- Explain why a WAF is a backstop, not a wall - it slows attackers, it does not stop them.
- Recognise the four canonical bypass families: case alternation, comment splitting, double-encoding, and hex literals.
- List the five layers of defense in priority order, with the WAF as the last.
- WAF (Web Application Firewall)
- A reverse proxy that inspects HTTP traffic against a rule set and blocks requests that match known-bad patterns. A WAF is a regex engine with incomplete grammar coverage.
- Defense in depth
- The practice of layering multiple independent defenses so that the failure of any one layer does not lead to compromise.
- Anomaly detection
- Monitoring query patterns, error rates, and latency at the database layer to surface what the WAF misses - e.g. a spike in SLEEP() calls from one source IP.
The filter is not the firewall
A WAF is a regex engine bolted onto the edge of an application. It looks at the request, runs a few hundred patterns, and either lets the request through or blocks it. The patterns are written by humans and are necessarily incomplete. SQL has dozens of whitespace alternatives, dozens of string delimiters, dozens of comment styles, and an entire encoding stack layered on top. The defender has to enumerate all of them; the attacker only needs one.
The mindset shift: stop trying to write SQLi payloads that look like English. Write payloads that look like noise to a regex but resolve to a valid query to the database. Comments, case alternation, double-spaces, hex encoding, double-encoding, scientific notation, MySQL-specific backticks, PostgreSQL dollar-quoting, and Unicode confusables are all in the toolbox.
Break the comment filter
The sandbox simulates a comment board that runs each post through a naive WAF. The WAF blocks the four most common SQLi keywords (UNION, SELECT, OR, --) and a handful of patterns. The four preset payloads in the dropdown demonstrate the canonical bypass techniques. Use the “Raw” mode to write your own.
Naive pattern matching on the raw body. Misses casing variations, inline comments, double encoding, and hex literals.
UNION+SELECTin the same body, with no inline comment between them → BLOCK' OR 1=1literal pattern → BLOCK- Trailing
--SQL comment → BLOCK - Hex string
0x[0-9a-f]+→ ALLOW (gap!) - Double-encoded
%25→ ALLOW (gap!)
The WAF paradox
Cloudflare, AWS WAF, Akamai, and ModSecurity all ship with default SQLi rule sets that catch the easy payloads from Lessons 1–4. They also ship with documented bypasses. The Claroty / Team82 December 2022 disclosure revealed a JSON-payload SQLi bypass affecting Cloudflare, AWS WAF, Palo Alto, F5, and Imperva - the common pattern across the WAF vendors was a regex that did not normalise the JSON content type before pattern matching. A 2020 Cloudflare disclosure by George Skouroupathis demonstrated a comment-splitting bypass (multi-line comments between keywords) that was patched within days, not months. WAFs are bypassable out of the box, and the bypasses get published regularly.
The uncomfortable truth: a WAF is a rate limiter on attackers, not a defense. It converts a zero-day into a one-day, and a one-day into a 30-minute task. Every minute an attacker spends bypassing your WAF is a minute they are not exfiltrating data - but if the underlying application is vulnerable, they will eventually get through. WAF without parameterised queries is a screen door on a submarine.
Defense in depth, in order
The proper layering, from inside out: (1) parameterised queries at the data layer - this stops SQLi at the root, and no WAF bypass can reach it. (2) Whitelist input validation for known fields (sort columns, enum values, IDs). (3) Least-privilege database users - the web app should not have DROP TABLE privileges. (4) WAF rules as a backstop, with default-deny for any request that matches a SQLi signature. (5) Anomaly detection at the DB layer - spike in error rates from one IP, spike in SLEEP() calls, and so on.
// BAD: WAF as primary defense
if (request.matches(/union.*select/i)) {
return res.status(403).end();
}
db.query(input);
// GOOD: WAF as backstop, parameterised as primary
if (request.matches(/union.*select/i)) {
log.warn('possible SQLi attempt', { ip: req.ip, body: req.body });
}
const q = 'SELECT * FROM users WHERE id = $1';
await db.query(q, [id]);The WAF stays on because the cost of running it is negligible and the telemetry it generates is valuable. But the application no longer depends on the WAF being correct. That is the only architecture that survives contact with a determined attacker.
What to remember
- WAFs are regex engines with incomplete grammar coverage; SQL is a grammar with infinite variation.
- Comments, case alternation, hex literals, and double-encoding routinely break naive filters.
- A WAF converts a zero-day into a one-day. It does not replace parameterised queries.
- Default-deny WAF rules + least-privilege DB users + parameterised queries is the only safe stack.
- Database-layer anomaly detection catches what the WAF misses - error spikes, SLEEP() calls, schema queries from anonymous users.
Knowledge check
0/2 answered · 0 correct1.A WAF blocks the literal pattern /union.*select/i. Which payload evades it?
2.What is the right role for a WAF in a defense-in-depth stack?