You don’t need an exotic payload to get past most WAFs. You need a string ' or two that the WAF’s regex set has never seen, and you need the input to land in the right ' field. The five strings covered below all do real damage in production systems, and all of ' them sail past the WAFs that ship in the default rule set of the four biggest CDN providers. ' The reason is the same in every case: the WAF is matching the payload, not the pattern. A ' SQL injection detector that runs against the input at the server boundary, before the ' parameterized query ever has a chance to do its job, is the only reliable second line of ' defense — and the patterns it has to look for are different from the ones the WAF watches.
What a SQL injection detector actually looks at
Every web application firewall claims it blocks SQL injection. Most of them stop at the obvious payload — ' OR 1=1 -- and its tabloid cousins. A real SQL injection detector, the kind that runs against raw input the moment it lands on a server, looks at something narrower: it scans the string for the syntactic fingerprints that an attacker has to leave behind, no matter how the payload is encoded, split, or hidden inside otherwise innocuous fields.
That distinction matters because every WAF in production lets at least one class of attack through, and the things that get through are almost never the things the WAF’s marketing page warned you about. They are the things that look like normal query parameters with one or two carefully placed tokens. The job of a SQL injection detector is to be the second pair of eyes that catches those tokens before they ever reach the database driver. A quick way to check your own input for these patterns is the SQL Injection Detector tool — paste a string, see which class it falls into, and find out whether your WAF would have caught it.
The four pattern classes that catch the most attacks
The attacks that survive a WAF’s first pass fall into a small number of well-studied pattern classes. A detector that watches for all four covers most of the long tail without dragging in benign strings that happen to contain a quote.
- Boolean tautologies — fragments like
OR 1=1,AND 'a'='a, orOR 'x'='x'. These are the classics, but they survive when the attacker uses an unusual separator (a tab, a comment block, or a backtick) to defeat a naive regex. - UNION-based extraction — anything that appends
UNION SELECT(or its case-shuffled form) to a query. The detector has to recognize the keyword, not just the case-insensitive spelling, and ignore the noise that a string-concat attacker uses to push the keyword past a length threshold. - Comment truncation — sequences like
--,#, or/* ... */inserted to cut off the rest of the SQL query after the injection point. These are dangerous not because they execute, but because they silently change what the rest of the statement does. - Stacked statements — terminating a statement with
;and appending a second one. Most drivers reject stacked statements, but a few don’t, and a detector that doesn’t flag the semicolon will let the whole attack through.
What the detector cannot see
A SQL injection detector is a syntactic tool, not a semantic one. It tells you whether a string looks like an attack, not whether the string would succeed against the database that receives it. Three classes of attack will look clean to the detector and still execute.
Second-order injection
When attacker input is stored safely and then re-served to the database in a different code path — say, a name that gets logged and then re-inserted into a report query — the original input was clean when the detector scanned it, and the dangerous form only appears at the second site. The detector never sees the payload in its executable form. The fix is at the storage layer (parameterized writes, even for “safe” data) and outside the detector’s scope.
Out-of-band exfiltration
A payload that uses xp_dirtree, UTL_HTTP, or LOAD_FILE to send data to an attacker-controlled host doesn’t need a tautology or a UNION. The SQL it generates is syntactically ordinary — the dangerous part is a function call that looks like any other function call. The detector will let it through because the only suspicious token is the function name, and many benign queries use the same function names. This is one of the cases where the detector has to make a judgment call, and most detectors err on the side of not alerting.
Type-coerced payloads
When a string parameter is later cast to an integer and compared, the attacker can pass 1 OR 1=1 as a numeric value and the database silently coerces the trailing text into a comparison operand. The detector sees a string with what looks like a numeric value plus some text. Whether it flags that depends on how aggressive the detector’s numeric-handling rules are, and most detectors are not aggressive enough to catch it.
How the detector reports findings
When the detector fires, the report has to tell you three things: which pattern class matched, where in the string the match started, and which input field the string came from. Most detectors collapse all three into a single boolean (injected / not injected), which is the worst possible output for a developer trying to figure out whether the flag is real.
A good report splits findings into high confidence (a tautology with a comment terminator, a UNION with a SELECT in the same string) and low confidence (a string that contains OR and an equals sign but no other injection markers). The high-confidence findings can be blocked; the low-confidence ones should be logged and reviewed. A detector that doesn’t distinguish between them either floods the log with false positives or trains the team to ignore the alerts.
The output should also tell you the position of the match. A payload of username' OR 1=1 -- in a username field is a different problem from the same string in a comment field, and the position in the string tells the reviewer which field it landed in. The detector that just says “found: OR 1=1” with no context is asking the reviewer to do the work the detector should have done.
When to reach for a SQL injection detector
A SQL injection detector is the right tool when the input is untrusted and you can’t control the upstream code — a legacy endpoint, a third-party API wrapper, a batch importer that accepts CSV from outside. It is the wrong tool when the input is already parameterized at the call site; in that case the detector is doing work the database driver would have done for you, and adding a second layer of scrutiny on top is wasted effort.
It is also a useful audit tool even when you do use parameterized queries. Run your test suite’s input fixtures through the detector; if the detector flags them, the fixtures are not testing what you think they’re testing. The detector in this mode is acting as a canary for “this string is shaped like an attack” — not a real defense, but a useful tripwire for input that someone has accidentally let past the parameter boundary.
For the security audit pattern, the ReDoS Scanner is the natural companion — same input-fuzzing workflow, different failure class. For password-handling review, the Password Validator tool covers the credential side of the same audit pass. Explore more security tools at elysiatools.com.
