A command injection vulnerability allows an attacker to execute arbitrary system commands, resulting in an entire takeover of the webserver. Learn here how you can prevent command injections!
A command injection attack can occur with web applications that run OS commands to interact with the host OS and the file system. They do this to execute system commands, start applications in a different language, or execute shell, Python, Perl, or PHP scripts. While this functionality is standard, it can be used for cyber attacks.
The main loophole through which command injection can be executed is when user-supplied input is not validated in applications. This input is used in the construction of commands that will be performed. Such cyber-attacks are possible when a web application passes the unverified user input (cookies, forms, HTTP headers, and the like) directly to OS functions like exec() and system(). The input is always a string (string cmd) linked to a constant string of the application, which shapes the whole command.
Command injection is also known as shell injection. The arbitrary commands that the attacker applies to the system shell of the web server running the application can compromise all relevant data. The command injection can also attack other systems in the infrastructure connected to and trusted by the initial one. This is how the attacker can use the privileges of the targeted application to gain broader control over the system.
Most OS command injections are blind security risks. The targeted application doesn’t bring back the command output within the HTTP response. Still, blind injections are a security threat and can compromise a system.
Example of Command Injection
Malicious attackers can escape the ping command by adding a semicolon and executing arbitrary attacker-supplied operating system commands.
$ip = $_POST['ip'];
$cmd = system('ping '.$ip);
Example input: ; cat /etc/passwd
To ensure your web application is not vulnerable to command injections, you’ll have to validate all user input and only allow commands needed for the task. You can also clean up user input by removing special characters like ; (semi-colon) and other shell escapes like &, &&, |, ||, <.
There are proven ways to limit the situations in which command injections can be executed in your systems.
Here are the most valuable tips for applying:
- Limit the use of shell command execution functions as much as possible
- Employ a trusted API for user input into your application, especially when
running system commands such as execFile()
- Always validate user input that will be feeding into a shell execution command, which entails having a sound input validation strategy.
- Filter potentially problematic special characters by using an allowlist for user input or by targeting command-related terms and delimiters
- Encode user input before using it in commands to avoid command-related characters being read as elements of the command or as a delimiter, as well as malformed inputs
- Parameterize user input or limit it to certain data sections of the command to avoid the input being read as an element of the command
- Make sure users can’t get control over the name of an application by using execFile() securely.
A command injection vulnerability exists when user-supplied input is not validated correctly by the web application. The following snippet shows PHP code that is vulnerable to command injection.
Testing for Command Injection Attacks
Application security is a top priority, so it’s essential to regularly check your systems’ critical vulnerability risks.
To check for blind command injections, you can use various detection techniques, such as time delays, redirecting output and checking the file manually, or running an OOB network interaction with an external server.
You can use some standard parameters to test for operating system command injections:
Suppose you prefer to use automated pentesting rather than manual testing for dangerous software weaknesses. In that case, you can use a dynamic application security testing tool to check your applications.