Home / Knowledge hub / Blind SQL injection
Knowledge hub
Blind SQL injection
Injection where no data comes back, so answers are read from timing or behaviour.
What it means
Blind SQL injection is a form of SQL injection where the page never shows the database's output or errors. The attacker cannot read the data directly, so they ask yes-or-no questions and watch how the application reacts. Each answer is tiny, but enough of them add up to a whole table.
Two signs are used. In the boolean kind, the page looks different when the question is true: a result appears or disappears, or a sign-in succeeds. In the time-based kind, the injected query tells the database to pause, so a slow response means yes.
Why it matters
Hiding error messages does not make the flaw go away. It only slows the attacker, and automated tools remove that slowdown by asking thousands of questions to rebuild a table one character at a time. Given time, the contents of your database can leave.
It is also easy to miss in testing. Nothing visibly breaks, so a quick manual check or a scan that looks for error text may report no problem. The cost to you is the same as any SQL injection: customer data, credentials, and a breach notice.
How it shows up
It appears where input reaches a query but the result is not displayed: tracking pixels, analytics calls, sign-in checks, search filters that only change the number of results, and fields that are used in a lookup behind the scenes. Cookies and headers count as input too.
The fix is the same as for any SQL injection: parameterised queries, so input is never part of the SQL text. To test, compare responses for a true condition and a false one, then try a delay. Results can be noisy and slow, so tools help, but a person should judge whether it is real.
Questions people ask
Blind SQL injection, answered
How is blind SQL injection different from ordinary SQL injection?
With ordinary injection the attacker sees the results or error messages. With blind injection they see nothing, and learn the data from differences in behaviour or timing.
The flaw is identical, only the way it is read differs.
Does hiding error messages protect us?
It helps by not handing the attacker free information, but it does not fix the flaw. Blind techniques exist because errors are hidden.
Fix the query, and hide the errors as well.
What is time-based injection?
The attacker injects a command that makes the database wait, such as a sleep of several seconds, only if a condition is true. A slow reply means yes.
It works even when the page looks the same in every case.
Why is it slow for attackers?
Each request reveals only a tiny fact, so reading a table takes many requests. Software automates this, so slow is not the same as safe.
Rate limits and monitoring can make the pattern visible.
How do we prevent it?
Use parameterised queries everywhere, give the database account minimal rights, and keep errors out of responses. Watch for floods of near-identical requests.
Prevention is the same as for any SQL injection.
Sources
Where this comes from
Related
Terms that sit next to this one
SQL injection
Input a database ends up running as part of a query.
Parameterised queries
Sending the query and the data separately so input can never become code.
Injection
Input that ends up running as a command instead of being read as text.
Timing attack
Learning a secret by measuring how long your application takes to answer.
Second-order injection
Malicious input stored safely at first, then run later when another part reads it.
Is a quiet page a safe page?
Quiet injection points are the ones scanners tend to miss. We test inputs for behaviour and timing differences, and report a finding only when we have proved it with a request and response. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.