Time-Blind Injection

Overview

Time-based injection is the universal fallback. It needs no visible results, no error messages, and no observable difference between a true and a false page — you create the difference yourself by making the query take measurably longer when your condition holds.

It is also the slowest and least reliable technique, because network jitter, server load, and connection pooling all add noise to the only channel you have. Reach for it when nothing else is available, and treat every measurement as provisional until confirmed.

The Conditional Delay

An unconditional SLEEP(5) proves the injection but extracts nothing. The useful form makes the delay depend on the bit you are testing:

if (condition) then wait 5 seconds, else return immediately

A slow response means true, a fast response means false. Combine with the binary search from Boolean-Blind — the inference logic is identical, only the oracle changed.

Per-Engine Payloads

SQL
-- Proof of execution
' AND SLEEP(5)-- -

-- Conditional: IF() is the compact form
' AND IF(ASCII(SUBSTRING((SELECT password FROM users LIMIT 1),1,1))>79,SLEEP(5),0)-- -

-- Portable CASE form
' AND (SELECT CASE WHEN (1=1) THEN SLEEP(5) ELSE 0 END)-- -

-- BENCHMARK burns CPU instead of sleeping — noisier, but survives
-- filters that block SLEEP, and works where SLEEP is disabled.
' AND IF(1=1,BENCHMARK(5000000,MD5('a')),0)-- -

Making Measurements Trustworthy

The timing channel is noisy. These practices separate signal from luck:

Calibrate first. Measure baseline latency over 20+ requests. Note the median and the spread. Your delay must exceed the 99th percentile of normal by a comfortable margin — if the baseline is 200 ms ± 400 ms, a 1-second delay is not enough.

Use a long enough delay. 5 seconds is conventional because it clears almost any jitter. Shorter is faster but starts producing false readings.

Confirm both directions. A payload with an intentionally false condition must return at baseline speed. If a "false" test is also slow, you are measuring something other than your delay.

Re-test disagreements. When a result is near the threshold, repeat it. Two out of three agreeing is a reasonable rule.

Watch for timeouts. A proxy or load balancer with a 30-second timeout will cap your delay. If a 5-second and a 60-second sleep produce identical response times, something upstream is truncating.

Mind connection pooling. A long sleep holds a pooled database connection. Enough parallel requests will exhaust the pool and take the application down — which is an outage you caused, not a finding you reported.

Operational Risk

Time-based extraction is the technique most likely to cause real harm during an authorized test.

Each bit costs one request that occupies a database connection for the full delay. A 32-character password at 7 requests per character is 224 requests, each holding a connection for 5 seconds — roughly 19 minutes of connection-seconds. Run several threads against a pool of 20 connections and you have a self-inflicted denial of service.

Before running an extended time-based extraction against production: agree the approach with the client, cap concurrency low, and prefer off-peak windows. Note it explicitly in the rules of engagement.

Prevention

Parameterise. No mitigation on the output side touches this technique — there is no output. Suppressing errors, hiding results, and unifying response pages all leave it fully exploitable.

What helps operationally: query timeouts (a statement that cannot run for 5 seconds cannot signal a bit), least-privilege accounts that lack EXECUTE on sleep-capable packages, and monitoring for the volume-plus-latency pattern that blind extraction inevitably produces. All compensating controls, none a fix.