WAF Bypass

A WAF sees an HTTP request and tries to predict what the database will do with it. The database sees SQL and applies a full grammar. Between those two views there is a large gap, and every bypass technique exploits some part of it:

• The WAF normalises differently from the database (encoding, whitespace, case).
• The WAF's regex matches a keyword shape the database accepts in other forms.
• The WAF inspects part of the request; the application reads a different part.
• The WAF has a size or depth limit; the database does not.

A WAF is a compensating control that buys time and blocks automated tooling. It is not a fix, and a rule that requires bypassing is still protecting a vulnerable query. Treat a bypassed WAF as a finding about the WAF, and the injection underneath it as the finding that matters.

Bypasses are product-specific. Determine what you are against before guessing.

Signals: a distinctive block page or reference ID, a Server or X- header, a specific status code (406, 419, 429 are common), a cookie set on the block response, or timing (an inline WAF blocks fast, an out-of-band one lets the request through then resets).

wafw00f fingerprints most commercial products. Once identified, look up its known normalisation quirks rather than working blind.

Then find the boundary. Send progressively simpler payloads until one passes: ' OR 1=1-- -, then ' OR 1=1, then ' OR 1, then '. Knowing exactly which token triggers the block tells you what to transform.

Rules frequently match union\s+select. Databases accept a much wider set of separators than \s covers — and in some positions accept none at all.

Useful substitutes: %09 (tab), %0a (newline), %0b (vertical tab), %0c (form feed), %0d (carriage return), %a0 (non-breaking space, MySQL), and /**/.

Parentheses remove the need for whitespace entirely, which is the most robust variant:

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

-- No spaces at all
UNION(SELECT(1),(2),(3)FROM(users)WHERE(id)=(1))

-- Mixed separators
UNION%0aSELECT%091,2,3
UNION%a0SELECT%0b1,2,3        -- %a0 works on MySQL

-- Comment as separator
UNION/**/SELECT/**/1,2,3

The classic bypass is a difference in when each layer decodes.

Double URL encoding. If the WAF decodes once and the application server decodes again, %2527 is %27 to the WAF and ' to the application. Effective against reverse-proxy WAFs in front of a server that decodes independently.

Mixed encoding. Encoding only some characters (%53ELECT) defeats rules that match literal text but not those that normalise first.

Unicode. Overlong UTF-8 sequences and full-width forms (ＳＥＬＥＣＴ, U+FF33 onward) are normalised by some stacks into ASCII after the WAF has inspected them.

Hex literals. 0x61646d696e on MySQL contains no quotes at all, defeating quote-based rules outright. CHAR(97,100,109,105,110) is the portable equivalent.

Charset declaration. Setting an unusual Content-Type charset (ibm037, utf-16) can cause the WAF to inspect bytes it cannot interpret while the application decodes them correctly.

'          -> %27  -> %2527      (double-encoded)
SELECT     -> %53%45%4c%45%43%54 (fully encoded)
SELECT     -> %53ELECT           (partially encoded)
'admin'    -> 0x61646d696e       (hex, no quotes)

Sometimes the payload never needs transforming — you just deliver it somewhere the WAF is not looking.

Change the method. A rule written for GET query strings may not apply to a POST body, or vice versa. Try POST with the parameter in the body, and try method override headers (X-HTTP-Method-Override).

Change the content type. JSON, XML, and multipart bodies are parsed by different WAF modules with different coverage. Multipart in particular has many parser-differential bugs.

Parameter pollution. Send the parameter twice: ?id=1&id=' OR 1=1-- -. WAFs and application servers disagree about which occurrence wins — ASP takes the concatenation of both, PHP takes the last, JSP takes the first.

Exceed the inspection limit. Most WAFs stop inspecting a body after a size threshold. Pad with a large benign field and place the payload after it.

Chunked transfer encoding. Splitting the payload across chunks defeats inspectors that do not reassemble.

Nulls and control characters. %00 truncates some parsers mid-inspection while the database reads the whole value.

sqlmap ships tamper scripts that automate most of the transformations above. Chain them and set a lower risk/level to reduce noise:

# Fingerprint first
wafw00f https://target.example.com

# Common chains
sqlmap -u 'https://t/x?id=1' --tamper=space2comment,between,randomcase
sqlmap -u 'https://t/x?id=1' --tamper=charunicodeencode,space2plus
sqlmap -u 'https://t/x?id=1' --tamper=versionedmorekeywords   # MySQL

# Slow down and look less like a scanner
sqlmap -u '...' --delay=2 --random-agent --safe-url=https://t/ --safe-freq=3

List everything available with sqlmap --list-tampers. See Tooling for the wider workflow.

Be aware that heavy tampering plus high --risk is exactly the pattern that gets an engagement IP blocked. Confirm manually first, then automate narrowly.

Fix the query. Parameterisation makes every technique on this page irrelevant. A WAF in front of a parameterised query is defence in depth; a WAF in front of a concatenated query is a delay.

For the WAF itself, if you are configuring one:

• Normalise before matching, and normalise the same way the application stack does. Most bypasses are normalisation mismatches.
• Prefer positive security models. Allowlisting expected input shapes per parameter is far more robust than blocklisting attack patterns.
• Do not strip and forward. Rules that remove a matched keyword and pass the rest along are actively harmful — see the UNIunionON case above. Block the request instead.
• Alert on bypass attempts. The encoding permutations here are noisy and distinctive. A WAF that logs them gives your detection team a strong signal even when a request slips through.
• Test the WAF against your own stack's decoding behaviour, not against a generic payload list.