Question
What is the conceptual model of an injection attack?
Answer
Untrusted input reaches an interpreter that executes it as code instead of treating it as data.
* The injection model — untrusted input crosses a trust boundary into an interpreter, which executes it as code instead of treating it as data. *
Every injection tells the same three-step story, and it works for one reason: the vulnerable code hands the interpreter a single string that mixes its own instructions with the attacker's data. The interpreter has no way to tell which characters came from the programmer and which came from the user, so it parses all of them as language.
- An interface accepts untrusted input — a form field, a URL parameter, an uploaded file, an API payload, even a line written to a log.
- That input is forwarded to a subcomponent still glued into the surrounding command, rather than passed alongside it as a separate value.
- An interpreter or parser executes it — the injected fragment becomes part of the query, command or markup instead of a value inside it.
The line the payload steps over is the trust boundary: the point where data from outside reaches a component with a command interface — a SQL engine, a shell, an XPath processor, a browser's HTML parser. Everything arriving from the far side is attacker-controlled, so it must never arrive as code.
Why this one model covers so many attack names: SQL injection, OS command injection, XPath injection and XSS differ only in which interpreter sits behind the boundary. Recognise the shape and the defence follows — keep code and data in separate channels instead of concatenating them into one string.
Go deeper:
OWASP Top 10 (2021) — A03: Injection — injection as untrusted data reaching an interpreter as code.- OWASP Injection Prevention Cheat Sheet — the full injection family and the general defense pattern.
- OWASP — Injection Theory — why any component with a command interface is a candidate target.
Note saved — thanks!
Question
What are the main types of injection attacks and how do they differ?
Answer
The top split is how the payload reaches its target — 1st order, 2nd order, or lateral. 1st order then splits again by how the results come back: in-band, blind (inferential), or out-of-band.
* Injection taxonomy — 1st order / 2nd order / lateral at the top; only 1st order splits again into in-band, blind and out-of-band. *
The classification is a two-level tree, not three independent axes. The first level asks how the payload gets to its target:
| Top-level family | What it means |
|---|---|
| 1st order | The payload fires immediately, on the very system it was sent to |
| 2nd order | The payload is stored harmlessly first, then executes later — often on a different system or in a different user's context |
| Lateral | The damage comes from shifting or transforming one datatype's representation into another (e.g. a value converted between types along the way) |
Only 1st order splits further, and it splits by how the attacker gets the answer back:
| 1st-order subtype | How results reach the attacker | Sub-methods |
|---|---|---|
| In-band | Straight back through the same channel used to attack | WHERE-clause tampering, UNION query |
| Inferential (blind) | Nothing comes back — differing responses reveal the answer bit by bit | conditional, time-based, error-based |
| Out-of-band | Through a different channel, e.g. an email or a DNS lookup | — |
Why the tree matters: it tells you where to look. In-band attacks show up in the response body, so response inspection catches them; blind attacks leave nothing to read and need behavioural or timing analysis; out-of-band ones only surface in outbound traffic (mail, DNS) — a response-only monitor never sees them at all. And 2nd order is the reason encoding at output time is non-negotiable: input that looked harmless going in becomes dangerous coming back out.
Note saved — thanks!