Overview
The root cause of command injection is unsafe concatenation — building a command string by gluing untrusted input into it. This lesson examines that pattern and why it is dangerous, defensively.
Learning objectives
- Identify the unsafe-concatenation pattern.
- Explain how shell metacharacters enable injection.
- Recognize the pattern to eliminate it.
Core concept
Unsafe concatenation is constructing an OS command by inserting untrusted input directly into a command string that is then run through a shell. Because the shell interprets metacharacters — such as ; (command separator), | (pipe), &, $()/backticks (command substitution), and redirection — any of these appearing in the concatenated input can change the command's meaning, introducing additional commands or altering behavior. This is exactly analogous to SQL injection: untrusted data is allowed to become code.
How it works
When input is concatenated into a shell command string, the shell parses the whole string, so metacharacters in the input are treated as operators, not literal text. This lets injected sequences chain extra commands onto the intended one or redirect its behavior. The vulnerability is not in the system tool being called but in how the command is assembled — string concatenation plus shell interpretation. Recognizing this pattern (untrusted input concatenated into a shell command) is how you spot command-injection risk in code; the fix is to stop concatenating into a shell string (later lessons).
Practical example
An app builds a command like "tool " + user_input and runs it through a shell. For benign input, this runs tool <value> as intended. But because the shell interprets metacharacters, input containing a command separator or substitution operator would be parsed as additional shell syntax, causing the shell to execute more than the intended command. The flaw is the concatenation-into-shell pattern itself — the same input passed as a separate argument to a directly-executed binary would be harmless data. Identifying the concatenation pattern is the key defensive skill here.
Cybersecurity relevance
Unsafe concatenation into shell commands is the concrete source of command-injection vulnerabilities, which can result in full server compromise. It is a high-severity, recognizable anti-pattern that code review and testing target directly. Just as with SQL injection, the lesson is that filtering metacharacters is fragile — the robust fix is to avoid building shell command strings from untrusted input at all (via direct execution with separated arguments), covered next. Spotting the concatenation pattern is the first step to eliminating it.
Common mistakes
- Concatenating untrusted input into a shell command string.
- Trying to blocklist shell metacharacters instead of avoiding shell string construction.
- Assuming a specific input "can't contain" metacharacters without enforcing it safely.
Key takeaways
- Command injection's root cause is unsafe concatenation: inserting untrusted input into a shell command string that the shell then interprets.
- Shell metacharacters (
;,|,&,$(), redirection) in concatenated input can introduce extra commands or change behavior — data becoming code. - The flaw is in command assembly, not the tool; filtering metacharacters is fragile, so the robust fix is to avoid shell string construction from untrusted input (next lessons).
Check your understanding
- Why do shell metacharacters in concatenated input enable command injection?
- Why is filtering shell metacharacters an unreliable defense compared with avoiding shell string construction?