hunting-blind-and-second-order-sql-injection

Hunting blind and second-order SQL injection: the paths first-order testing walks past

Parameterized queries have made obvious SQL injection rare, but two variants survive because they defeat the usual way people test. Blind injection reaches a real query, but the response returns no error and no data, so a single probe looks inert; the vulnerability is real and confirmable only through an inferential channel, a boolean that flips the response or a deliberate time delay. Second-order injection is subtler: the input is stored correctly and safely on the request that accepts it, then read back later and concatenated into a query on an entirely different code path, so the endpoint that accepts the payload is not the endpoint that is vulnerable. You find both by following stored values to their later query uses and by treating no-output sinks as blind rather than safe.

When to use

• A value is stored on one request and later used to build a query on a different code path.
• A parameter reaches a query whose response shows no error and no returned data.
• Data read back from the database, a cache, a log, or a queue is concatenated into a later query.

Scope check

Test SQL injection only against databases and applications you own or are authorized to assess, on non-production data. A confirming boolean or timing probe still executes against the database and a destructive payload must never be used, so stay inside the authorized boundary. If you can't name the authorization, stop.

The loop

1. Establish every query sink, including the silent ones. Inventory all query construction, and mark the sinks whose responses reveal nothing: background jobs, count-only checks, existence probes, and endpoints that return a fixed status regardless of the row. This is the false-positive killer in reverse: a silent sink is not a safe sink, it is a blind one, and it must be tested inferentially rather than dismissed. Name all sinks, silent ones included.

2. Follow stored values to their later query uses. For second-order injection, trace each value from the request that stores it to every later read: a profile field, a name, a comment, a cached lookup, a log line re-parsed by a job. At each later read, ask whether the value is concatenated into a query or bound as a parameter. The storing request being safe tells you nothing about the using request.