A blind sql injection cheat sheet exists because blind SQL injection does not return database errors or query output directly to the attacker, which forces a different, slower technique built on inferring true or false answers one bit at a time. Where classic SQL injection lets an attacker read data straight off an error page or a UNION-based response, blind injection works against applications that suppress that output but still process the injected query logic differently depending on whether a condition is true or false, or how long the query takes to run.
This post is a practical reference for how blind SQL injection actually works, both major techniques, and what a fix actually needs to look like.
How to do a sql injection when there is no visible output?
The starting point is the same as any SQL injection: unsanitized user input reaches a query as raw SQL rather than as a parameterized value. The difference in a blind scenario is that the application's response looks identical whether the injected condition evaluates to true or false, at least visually, so the attacker cannot simply read the answer off the page.
Blind techniques work around this by asking the database yes-or-no questions and reading the answer through some other observable signal. There are two dominant methods, boolean-based and time-based, and a competent attacker will usually try both, since one is often blocked while the other works depending on the specific defenses in place.
What does boolean-based blind injection actually look like?
Boolean-based blind injection relies on the application behaving subtly differently depending on whether an injected condition is true or false, even if no error message appears. A common example against a login or search feature: appending a payload like ' AND 1=1-- causes the application to behave normally (because the condition is true and the rest of the query executes as intended), while ' AND 1=2-- causes it to return no results or a different page state (because the condition is false and the query returns nothing).
Once that true/false channel is established, an attacker automates it to extract data one character at a time using conditional substring comparisons, for example asking "is the first character of the admin password hash greater than 'm'" and using the binary-search pattern of responses to narrow down each character across the entire string. This is mechanical and slow by hand but trivial to automate, which is exactly what tools built for this purpose do.
What does time-based blind injection look like, and why does it work even with no visible difference at all?
Time-based blind injection is the fallback for when there is no observable difference in application behavior at all between a true and false condition, not even a subtle one. Instead of relying on response content, the attacker injects a conditional delay, for example a payload that says "if this condition is true, sleep for 5 seconds," then measures the actual response time. A payload structured like ' AND IF(1=1, SLEEP(5), 0)-- (syntax varies by database engine) causes a 5-second delay only when the injected condition holds, giving the attacker a clean binary signal purely from timing, independent of any visible content on the page.
This technique is slower still, since every single bit of extracted information costs a full round trip with a multi-second delay, but it works even against applications engineered to look completely identical regardless of query outcome, which is why it remains a go-to technique in real assessments.
Have there been recent sql injection attacks worth learning from?
SQL injection, blind and otherwise, has remained a consistently exploited vulnerability class for over two decades precisely because it keeps appearing in new applications, not because old ones keep getting re-exploited. It shows up regularly in breach disclosures involving custom-built internal tools, legacy admin panels, and API endpoints that concatenate query parameters directly into SQL strings, especially in codebases that predate widespread ORM adoption or that hand-roll raw queries for performance reasons. The pattern across these incidents is rarely a novel technique; it is almost always the same root cause, string-concatenated SQL fed by unsanitized input, that has been well understood and well documented for years.
How do you actually prevent blind SQL injection?
The fix for blind SQL injection is identical to the fix for classic SQL injection, since the underlying vulnerability, unsanitized input reaching a raw query, is the same; blind injection is just a technique for exploiting that vulnerability without visible output, not a different root cause. Use parameterized queries or prepared statements everywhere user input touches a database call, so the database engine treats input strictly as data and never as executable query syntax, regardless of what characters it contains.
Layer in least-privilege database accounts, so that even a successful injection is limited in scope, and disable verbose error messages in production so an attacker gets less signal to work with, though note this alone does not stop blind techniques, it only removes the easier error-based variant. Web application firewalls can catch common blind-injection timing and boolean payload patterns, but treat that as a mitigation, not a substitute for parameterized queries.
From a detection standpoint, a DAST scan that specifically tests for both boolean-based and time-based blind injection, by measuring response content and response timing differences across crafted payloads, will catch this class reliably in a running application, which complements a SAST scan that flags the string-concatenated query pattern directly in source code before it ever ships.
FAQ
What is the difference between blind and classic SQL injection?
Classic SQL injection returns data or errors directly to the attacker, for example through a UNION-based query or a verbose error page. Blind injection returns no direct output; the attacker infers data through indirect signals like true/false behavior differences or response timing.
Is time-based blind injection slower than boolean-based?
Generally yes, since every extracted bit requires waiting out an injected delay, whereas boolean-based extraction only needs to observe a response difference, which can be near-instant. Attackers prefer boolean-based when available and fall back to time-based when the application gives no other signal.
Can parameterized queries fully prevent blind SQL injection?
Yes, when applied consistently across every query that includes user input. Parameterization removes the ability for input to alter query structure at all, which closes off both classic and blind variants at the root cause.
Does rate limiting help against blind SQL injection?
It helps by slowing down the large number of requests blind extraction requires, especially for boolean-based attacks that need many requests to extract meaningful data. It is a useful layer but should not replace parameterized queries as the primary fix.