SQL Injection Resources

SQL injection is solved, which is exactly why it still matters

The fix has been known for two decades and is unambiguous: send the query and the data separately, so that user input can never be parsed as SQL. A parameterized query is not a mitigation that raises attacker cost — it removes the class. And yet the bug keeps appearing, because the fix only holds where it is applied, and real codebases have places it is not: dynamic ORDER BY and column names, which cannot be parameterized and get concatenated instead; raw-SQL escape hatches in ORMs; stored procedures that build strings internally; reporting and search features written against a different database than the rest of the application.

The techniques below are organized by how much the database tells you. When errors come back, extraction is quick. When they do not but responses differ, boolean-based inference recovers data one condition at a time. When responses are identical, time-based methods use conditional delays, at the cost of a query per bit. Out-of-band methods — making the database resolve a DNS name or open a connection — are fastest of all when the database can reach the network, which is why they appear so often in writeups against otherwise silent targets.

Second-order injection deserves separate attention because it breaks the mental model people bring to testing. Input is stored safely on the way in, then concatenated into a query somewhere else entirely — a scheduled job, an admin view, an export. Nothing happens when you submit the payload, so it looks clean. The writeups here that find these are usually the ones that went looking for where stored values get reused.

On tooling: sqlmap is very good, and leaning on it before you can do the extraction by hand is a mistake that shows up immediately when a target needs a custom tamper script or has a WAF in front of it. Learn the manual path first; the automation makes far more sense afterwards, and so does the substantial body of evasion research collected below.