Injection is a broad class of security vulnerabilities that occur when an application sends untrusted user input to an interpreter without proper sanitization or separation between code and data. The interpreter treats the attacker's input as executable instructions rather than as data, allowing unauthorized actions such as reading, modifying, or deleting data, executing system commands, or bypassing authentication.
How It Works
SQL injection is the most well-known variant. When an application constructs a database query by concatenating user input directly into the SQL string, an attacker can inject additional SQL syntax. A login form that queries SELECT * FROM users WHERE username = '{input}' AND password = '{input}' can be bypassed with input like admin' --, which comments out the password check and grants access as the admin user.
Command injection occurs when user input is passed to a system shell. If a web application calls ping {user_input} on the server, an attacker providing ; cat /etc/passwd executes both the ping and the file read. The semicolon terminates the first command and introduces a new one.
Other injection types include LDAP injection (manipulating directory queries), XPath injection (attacking XML queries), template injection (executing code through server-side template engines), header injection (injecting newlines into HTTP headers to add malicious headers or split responses), and NoSQL injection (manipulating query operators in databases like MongoDB). Each targets a different interpreter but follows the same principle: untrusted input crosses the boundary between data and code.
Why It Matters
Injection consistently appears in the OWASP Top 10 because it remains both prevalent and devastating. A single SQL injection vulnerability can compromise an entire database. A command injection can give an attacker full control of the server. The impact is often complete system compromise.
The defense is well understood: use parameterized queries for databases, avoid passing user input to system shells, employ allowlist validation, and use framework-provided escaping functions for the specific context. Despite these known solutions, injection vulnerabilities persist because developers sometimes take shortcuts or work with legacy code that was not built with these patterns.
Need your application tested? Get in touch.