Let’s look at Command Injection by itself for now. We’re mostly going to focus on a few different examples so it’s easier to see what it looks like in action. So, as a quick refresher, Command Injection vulnerabilities occur when user input uses part of an operating system command, like the following function:
If a user provides the IP address, we’ll use `8.8.8.8` as an example, the command that gets executed will be `ping 8.8.8.8`, which does exactly what one would expect. However, if the user provides `8.8.8.8 && ls /etc/` this command wouldn’t just ping the IP 8.8.8.8, but it’ll also run `ls` on the `/etc/ folder.
Given the severity of a command injection attack, there are some important questions you need to ask first when working with system commands:
If these things aren’t possible, parameterization is important.
Here are a few examples in various languages to help show how this looks in practice.
Without the use of parameterization, this is vulnerable to Command Injection.
C# - secure
By providing the command as a list of parameters, the command is parameterized and protected against Command Injection.
Java - Insecure
Without the use of parameterization, this is vulnerable to Command Injection.
Java - Secure
By providing the command as a list of parameters, the command is parameterized and protected against Command Injection.
Javascript - Insecure
Without the use of parameterization, this is vulnerable to Command Injection.
Javascript - Secure
Python - Insecure
Without the use of parameterization, this is vulnerable to Command Injection.
Python - Secure
By providing the command as a list of parameters, the command is parameterized and protected against Command Injection.
We secure software through developer-driven security at the start of the software development lifecycle.
Visit Secure Code Warrior