SQL Injection: Detection to Confirmation

SQL injection has been on every major vulnerability list for over two decades, and it still shows up in real engagements constantly. The vulnerability class has not gone away. What has changed is how carefully it should be confirmed once found.

What SQL injection actually is

It happens when user-controlled input reaches a database query without being properly separated from the query's own structure. An attacker who can influence that structure can change what the query does entirely, reading data it was never meant to return, or in worse cases, modifying or deleting it.

Detection: spotting the indicator

Passive and automated checks often surface SQL injection as an indicator rather than a proof. An error message that leaks database syntax, a response that changes shape based on a single character in a parameter, these are strong signals, but they are not yet confirmation that an attacker could reliably exploit the flaw.

Confirmation: boolean-based testing

One of the most reliable, least destructive ways to confirm a SQL injection indicator is a boolean-based blind test: send two nearly identical requests, one crafted so the underlying query should evaluate to true, one crafted so it should evaluate to false, and compare the two responses. A meaningful difference between them, when nothing else about the request changed, is strong evidence the parameter genuinely controls query logic.

Why this step needs a human, not just a tool

Detection can run automatically inside an authorized scope with very little risk. Confirmation is different: it means sending a crafted payload at a real, possibly production, system. That is exactly the point where a person should look at the specific parameter, the specific payloads, and the specific target before anything actually fires. We go into why this split exists in the case for human-in-the-loop exploit confirmation.

Beyond confirmation

Once a SQL injection is confirmed, deeper exploitation, extracting data, escalating access, belongs to a separate conversation with the client about what the engagement's ROE actually authorizes. Confirming a flaw is real is not the same decision as exploiting it further, and treating them as one step tends to go further than most clients actually intended to authorize.

For how a broader exploitation tool like Metasploit fits into this same careful sequencing, see how Metasploit fits into a modern pentest workflow.