liveBook · Manning

Injection attack

As explained in Grokking Web Application Security

An injection attack is an attack in which crafted input is interpreted as executable commands or code by a target component.

An injection attack happens when an application treats untrusted input as code or commands. An attacker can use that mistake to run malicious code on a server, bypass authentication, steal data, or disrupt a web service—even by injecting a newline character. section 12.0

The danger is usually a boundary crossing: input arrives in an HTTP request, then reaches a database, operating system, template feature, log, or HTTP response header with special characters still meaningful to that downstream component. Metacharacters in a parameter can relay malicious code through the web server to a database or operating system. section 4.4 section 12.16

Reduce injection risk with layers that assume any single defense can fail:

  • Use parameterized database statements instead of building queries from input. section 4.14
  • Validate request input against an allow list, patterns, or a block list; restrict characters to the expected format where possible. section 4.14 section 4.4
  • Give database accounts limited permissions, verify expected database responses, and log and monitor database activity. section 4.14
  • Avoid command-line calls from application code; if unavoidable, keep untrusted input out of commands or remove control characters before use. section 12.16
  • Treat logs and response headers as injection boundaries too: strip newlines from untrusted values, and use standard logging metadata. section 12.16

Input validation example

For a value that should contain only letters and digits, a Ruby pattern can replace every other character with an underscore: `input_value = input_value.gsub(/[^0-9a-z]/i, '_')`. This illustrates why defining permitted input is safer than letting metacharacters reach a downstream interpreter. section 4.4

Do not dynamically execute untrusted input as code. If users need a custom expression language, use an embedded language such as Lua or parse its grammar before evaluation so it can be properly sandboxed. For rich search syntax, use a dedicated search index rather than evaluating user input as a regular-expression pattern. section 12.16

How Grokking Web Application Security covers it

How deep it goes
Explains several injection boundaries and gives layered prevention, logging, monitoring, and response-handling guidance without protocol internals.
Examples
Uses ransomware deployment, data-store authentication bypass, newline injection, and a Ruby character-filtering expression.
What you can do after
Apply parameterization, input validation, least privilege, sanitization, logging, and monitoring to reduce injection opportunities.
How it connects
Connects injection attacks to parameterized statements, input validation, allow lists, regular expressions, least privilege, logging, and HTTP response splitting.

Also explained in

Compare how 3 books explain injection attack →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Grokking Web Application Security. The section links point to the parts of the book it draws on.