Injection attacks

Authorization first: this is a defender’s autopsy

Everything below assumes a signed engagement with explicit scope — a deliberately vulnerable lab, a CTF, your own app, or a bug-bounty program with the target in its asset list. Probing a live application you don’t own for injection is unauthorized access in most jurisdictions, full stop; a single malformed query against someone else’s database can corrupt or destroy data, so “I was just testing” is not a defense. We study the attacker’s reasoning for one reason: you cannot reliably close a vulnerability class you only understand as a checklist item. Read this as the autopsy a defender performs on their own code, learning to see the query the way the attacker does so they can break the attack before it exists. No payloads to copy live here — only the mechanism, so you can recognize it in a code review and kill it in design.

The one mechanism behind every “injection”

SQL injection, OS command injection, NoSQL injection, LDAP injection, XPath injection, even server-side template injection — security people name them separately, but they are the same bug in different interpreters. The mechanism is always this: the application builds an instruction (a SQL statement, a shell command, an LDAP filter) by concatenating trusted code with untrusted input as text, then hands the combined string to an interpreter that re-parses the whole thing. The interpreter has no idea which bytes the developer wrote and which the user supplied — it only sees one string, and it parses it by its own grammar. If the user’s bytes contain characters that are syntactically meaningful in that grammar — a quote that ends a string literal, a semicolon that ends a statement, a backtick that opens a subshell — the user has just written code, and the interpreter runs it.

That reframing is the whole lesson. The vulnerability is not “the user typed something bad.” It is that the system mixed two trust levels into one channel and then parsed that channel with a grammar. The attacker’s entire job is to find a place where their input lands inside an interpreted string, then supply input that breaks out of the data slot and into the code slot. The apostrophe in the search box is exactly that: in SQL, ' terminates a string literal, so an input that contains one can close the literal the developer intended and continue with attacker-chosen SQL.

How an attacker reasons about an injection point

An attacker doesn’t start by knowing the bug is there — they probe for the boundary between data and code. The reasoning is a small, disciplined loop, and understanding it is what lets a defender reproduce and fix it.

1. Find the sink. Locate where user input plausibly reaches an interpreter — a search filter, a sort parameter, an id in a URL, a login form, an export filename, a header. Anything the app might feed into a query or command.
2. Perturb the syntax. Send input containing a character that is special to the suspected grammar (for SQL, a quote; for a shell, a metacharacter) and watch what changes. A 500 error, a different result count, or a timing change are all signals that the input reached a parser and altered it.
3. Confirm and characterize. Distinguish a real injection from a coincidental error by toggling between input that should keep the syntax valid and input that should break it. If “valid” loads normally and “broken” errors, the input is being parsed — that’s a confirmed injection point.
4. Determine the context and channel. Figure out which interpreter (SQL? shell? LDAP?) and whether results come back in the response (in-band) or must be inferred (blind).

The contexts: same bug, different interpreter and blast radius

The reason injection stays at the top of every risk list is that it generalizes across every interpreter a backend talks to — and the blast radius scales with what that interpreter can do.

OS command injection deserves a special note because its blast radius is the worst on the list. A SQL injection compromises a database; a command injection compromises the host, running with the privileges of the application process — which on a poorly-isolated box can mean the whole machine and everything it can reach. The root cause is the same string-concatenation mistake, just with a shell as the interpreter instead of a database. And the structural fix mirrors the SQL one: don’t hand a string to a shell that re-parses it for metacharacters — invoke the target program directly with its arguments passed as a discrete list, so the OS never runs a shell that could interpret a semicolon or a pipe as a new command.

Blind injection: when the answer doesn’t come back

Beginners assume injection requires the database to echo data into the page. It doesn’t. Blind injection is the case where the application doesn’t return query results or errors to the attacker — but the attacker can still extract data one bit at a time by asking yes/no questions and observing a side effect. The two classic channels:

• Boolean-based: craft input so the query is true in one case and false in another, and watch the response differ — a different page, a different length, a present-or-absent element. Each request leaks one bit (“is the first character of the admin hash an ‘a’?”).
• Time-based: make the query sleep when a condition is true. The data never appears anywhere; the attacker reads it purely from how long the response takes. This is slow — often automated, exfiltrating a hash character by character over thousands of requests — but it is complete: a blind, time-based channel can extract an entire database given enough patience.

The defensive lesson from blind injection is brutal and clarifying: suppressing error messages does not fix injection. Teams routinely “remediate” by hiding the database error that first revealed the bug. The injection point is still there; the attacker just switches to a blind technique and keeps going, now without the convenient error to tip off your monitoring. Hiding the symptom removes your own signal and leaves the vulnerability fully exploitable.

Why parameterization is the only fix that closes the class

Tie it together. Injection exists because code and data share one channel that an interpreter re-parses. Every durable fix works by separating those channels at the architecture level so untrusted input is delivered as a value that is structurally incapable of being interpreted as syntax. For SQL, that’s parameterized queries (a.k.a. prepared statements / bound parameters): the database receives the query template, plans it, and only then accepts the values — which it treats as opaque data, never as part of the statement’s structure. For OS commands, it’s invoking the binary with an argument vector instead of a shell string. For NoSQL, it’s typed query builders that reject operator-shaped input. Defense-in-depth still matters — least-privilege database accounts so a successful injection reads less, input validation as an allowlist to reject malformed input early, and structured logging to detect probing — but those reduce the damage; they don’t close the hole. Only separating code from data does that, and it’s why the parameterized query, not the WAF rule, is the senior’s first and last answer to injection.