Claude on Question 19, Sep 16

SQL Injection: A Developer Briefing

The Root Cause (lead with this)

Every SQL injection vulnerability comes from the same mistake: data from an untrusted source is concatenated into a query string and then parsed as code. The database has no way to know which parts of the string the developer wrote and which parts the attacker supplied.

Everything below is a taxonomy of how attackers exploit that mistake — useful for understanding detection and impact, but the fix is nearly always the same.

Classification by Data Retrieval Channel

1. In-Band SQLi (results come back through the app's normal response)

Union-based — The attacker appends UNION SELECT to graft their own result set onto the legitimate one.

GET /products?category=books' UNION SELECT username, password FROM users--

Requires matching column counts and compatible types; attackers enumerate these quickly.

Error-based — The attacker triggers database errors that leak data in the error message. Common with verbose error handling.

' AND 1=CONVERT(int, (SELECT TOP 1 password FROM users))--

On SQL Server this produces: "Conversion failed when converting the varchar value 'hunter2' to data type int."

2. Inferential / Blind SQLi (no data in the response — attacker infers it)

Boolean-based — The attacker sends conditions and observes whether the page renders differently.

' AND SUBSTRING((SELECT password FROM users LIMIT 1),1,1)='a'--

One request per character per guess. Automated tools do this in seconds.

Time-based — Used when the response is identical either way. The attacker makes the database pause conditionally.

' AND IF(SUBSTRING(...)='a', SLEEP(5), 0)--
'; WAITFOR DELAY '0:0:5'--

Blind SQLi is fully exploitable. "We don't show errors" is not a mitigation — it only slows extraction.

3. Out-of-Band SQLi

When the attacker can't read