Blind SQL injection is a form of SQL injection where the application does not show query results or database errors, so the tester or attacker has to infer what is happening from indirect signals. The two main types are boolean-based blind injection, which compares responses to true and false conditions, and time-based blind injection, which asks the database to pause.
Why it matters: A field that shows no errors can look safe while still being injectable. Many teams hide error messages, which is good practice, but it does not fix the underlying query. Blind techniques let testers confirm the problem without visible output, and attackers can use the same techniques to extract data one piece at a time.
In practice: Testers start by establishing a baseline response and timing for a normal input. They then send pairs of conditions and compare the results:
- A boolean pair such as ' AND 1=1-- - against ' AND 1=2-- -, where a difference between the two pages suggests injection.
- A time delay such as SLEEP(5) for MySQL, WAITFOR DELAY for SQL Server or pg_sleep(5) for Postgres.
A response that takes about five seconds longer than the baseline is a non-destructive way to confirm the issue.
Examples:
- A search box returns normal results for the true condition and an empty page for the false one, despite never showing an error.
- A login form takes five seconds longer to respond when a SLEEP payload is added to the username.
- A filter on an API endpoint returns different record counts depending on an injected condition.
Common pitfalls:
- Concluding a field is safe because a single quote produced no visible error.
- Misreading normal network delay as a positive result instead of repeating the time-based test against a measured baseline.
How is blind SQL injection fixed? The same way as any SQL injection: use parameterised queries so user input is always treated as data and never as part of the SQL statement.
