Summer’s over — what’s your move? Join Pro for 50% off using code [MAKEITHAPPEN](https://www.codecademy.com/checkout?periods=year&plan_id=proGoldAnnualV2&discountCode=MAKEITHAPPEN)


Learn how to identify and prevent shell injection vulnerabilities!

Identify and Prevent Shell Injection Attacks

If you’re looking for a shell injection vulnerability, it helps if you’ve got some idea of what it could look like. If you have access to the application's source code you're investigating, the simplest starting point is finding locations where shell commands are executed. 

This is simple in theory, but different languages have different methods of invoking the shell, and some have more than one. PHP, for example, has `exec()`,  `exec_shell()` and `system()`. In Python, one could use `os.system()`, `subprocess.run()`,  or `os.popen()`, among others. Needless to say, you will want to research the language the app is programmed in.

Just because a program executes a shell command doesn’t mean it’s vulnerable - it needs to execute it so that a maliciously crafted input could cause unintended behavior, such as executing additional commands.

Remember also that most modern applications have dependencies that need to be checked. For example, if an application passes a user's input to an external library, the external library must be checked to ensure it doesn’t contain shell injection vulnerabilities. If that library has dependencies, they may also need to be checked. It’s easy to overlook a potential vulnerability in cases like these, which is why it’s so important to have multiple layers of security. A defender would need to find every potential vulnerability, but an attacker only needs to find one.

Identifying Shell Injection Vulnerabilities with Source Code Access

So, shell injection is a serious vulnerability, but how do we prevent it? Unfortunately, there’s no foolproof way to ensure it doesn’t happen. Defense-in-depth is especially important here because the stakes are high if an attacker finds and exploits a vulnerability.

Our first layer should be one of an inherently safer design. We can avoid executing shell commands in our code and invoke other programs using safer methods. We can also refrain from using dependencies that are closed-source or have a poor security reputation.

If we must execute shell commands, we can sanitize the inputs we give to them, blocking all characters except those that are strictly required, taking special care not to allow any characters that have special meaning in the system shell-like `;`, `’`, `”`, `|`, or `&`, among others.

We can also take steps to limit the damage an attacker can cause if they exploit a shell injection vulnerability. Similarly to how we only allowed characters that were strictly required, we can restrict the system accounts used by our backend code and webserver to only those that are strictly required, preventing them from running any noncritical commands or accessing any noncritical files. We can also use sandboxing or virtualization to add another layer that an attacker must bypass. 

Finally, we can use tools like endpoint security software and intrusion detection systems to monitor for signs that an attacker has managed to breach our systems. If we detect the attack early and slow the attacker down with multiple layers of additional security, we can prevent them from doing too much damage.


A microscope scanning or searching for vulnerabilities on a computer.



Preventing Shell Injection

Welcome! In this lesson, we’ll take a more technical look at how shell injection happens, how to identify the vulnerability, and how we can deal with them.

Theoretically, shell injection can happen any time an unsanitized user's input is used to invoke a shell command. Usually, this is in the context of the user's input from a website executing a shell command on the backend server, but it doesn't always have to be that way.  

Shell injection also isn’t limited to any specific programming language. Most languages have some way of invoking a system's shell. Linux and Unix were, and still are, structured with the idea that programs should invoke other programs through the system's shell as part of normal operation. It isn’t innately bad for a program to use shell commands, but we must be careful, and there are usually safer ways to accomplish the same goal.

Introduction

Arguably, a more straightforward approach to finding shell injection vulnerabilities is to just try performing shell injection. This works even without access to the source code, though it’s helpful to have access.

Suppose you suspect an input field is somehow linked to the execution of a shell command. In that case, you can provide unusual inputs and see if any unexpected behavior occurs. For example, if you put a colon (`:`) into an input field and get a 500 internal server error, that’s a sign that something interesting may be happening. The exact characters that can cause problems vary depending on the server operating system, but some variety of Linux distro is a reasonable initial assumption.