An afternoon goes into a signup form: username, email, address, display name. Single quotes, UNION payloads, sqlmap pointed at every parameter in turn. Nothing comes back. No errors, no timing tells, no boolean differences. Every field is parameterized cleanly on insert. The report is basically writing itself: clean.
Then, on a hunch, check where the display name field shows up elsewhere in the app, not just on the public profile page. It turns up in an internal admin dashboard, in a report that joins user data together, built as a raw concatenated string because that endpoint predates the ORM migration and nobody circled back to fix it. The exact payload that did nothing at the signup form fires the moment an admin loads that report.
That's second-order SQL injection: the payload is safe at the point it enters the app and dangerous at a completely different point where it gets read back out. Standard SQLi testing methodology, throw payloads at every parameter and watch the immediate response, tests entry points. It says nothing about exit points: every place stored data later gets pulled into a new query. A report generator, a search reindex job, a CSV export, a webhook payload, an audit log formatter. None of those necessarily go through the same sanitization the original insert did, and a scanner testing the form field has no way to know they exist.
Finding it means thinking about the data's whole lifecycle instead of just its arrival. Where does this field get read again, by what code, and does that code definitely parameterize the same way the original insert did? That question doesn't show up in an automated scan result. It shows up when someone reads the codebase for every place a given column gets selected, or at minimum tests every screen that could plausibly render or process stored user input, not just the one screen it was typed into.
A clean sqlmap run against every entry point is a start, not a finding. The dangerous query is rarely the one the input reached first.
Codelivly's SQL Injection Notes PDF covers this exact distinction between first-order and second-order injection as part of its exploitation methodology, and the SQLi login bypass lab on the site is a good place to build the entry-point fundamentals that make hunting for the exit point actually make sense.
Top comments (0)