Command injection
TL;DR
Command injection is when user input reaches a system shell, so the attacker’s input runs as OS commands. The fix is to never build shell commands from input — use safe APIs that pass arguments directly, not a shell string.
Only test apps you’re authorised to test.
What it is
Some apps shell out to the operating system to do a job — ping a host, convert a file, run a utility. If user input is pasted into that command line, the input can stop being an argument and become a command of its own. It’s the same root cause as SQL injection, aimed at the shell instead of the database.
How it works
The app concatenates input into a command string and hands the whole thing to a shell. Shell metacharacters in the input let an attacker tack on extra commands. The lesson, as with SQLi, is that input was allowed to change the structure of the command.
How to test for it
- Find features that clearly run something on the system (network tools, converters, exports).
- See whether the app behaves differently — delays, errors, changed output — when the input might influence a command.
- Out-of-band signals (a DNS or HTTP callback) are the safe way to confirm “blind” cases in scope.
How to fix it
- Don’t call a shell. Use library functions or APIs that take arguments as a list, so input can never be parsed as a command.
- If you must, allow-list the exact values permitted.
- Run with least privilege so a mistake has a small blast radius.
Reference: OWASP: Command Injection.