Command injection is an attack in which the attacker runs arbitrary operating-system commands on the server through a vulnerable application.

It is possible when an application passes unsafe user-supplied data, from forms, cookies or HTTP headers, to a system shell. The exact syntax depends on the server's operating system, such as Linux or Windows.

See it in action

This demonstration uses the Damn Vulnerable Web Application (DVWA), a deliberately vulnerable application for practice, hosted on Windows. You can get DVWA from github.com/digininja/DVWA. Only test applications you own or are authorised to test.

Examples of input used in the demonstration, where a second command is appended to an expected IP address:

• 127.0.0.1 && dir
• 127.0.0.1 | dir
• 127.0.0.1 & calc

Prevention

• Avoid calling operating-system commands from application code. Use the language's built-in libraries instead, for example a network library rather than the ping command.
• If a command is unavoidable, pass the arguments as a list without invoking a shell, so that characters such as &, | and ; have no special meaning.
• Validate input against a strict allow-list, such as a valid IP address format. Blocking a few characters like && and | is not enough, because there are many ways around a block-list.
• Run the application with the least operating-system privileges it needs.

How Vooki Pro helps

• Tests inputs for OS command injection.
• Also covers code injection, server-side template injection and CVE-class issues such as Shellshock.
• Gives step-by-step reproduction and remediation for each finding.

Frequently asked questions

How do I prevent command injection?

Avoid calling the shell with user input. Use library functions or pass arguments as a list without a shell, and allow-list any values you must accept.

Is escaping enough?

Escaping is error-prone. Removing the shell from the code path is far safer.

Related: Server-side template injection (SSTI) · Insecure deserialization