Preventing Command Injection

Welcome to the final lesson of the "A03: Injection" course! In previous lessons, we've explored various injection vulnerabilities, such as SQL and XSS injections, and their impact on web application security. In this lesson, we'll focus on command injection, a critical vulnerability that occurs when user input is improperly handled in command execution, particularly in file processing.

Understanding and mitigating command injection is essential to prevent unauthorized command execution and potential system compromise. Let's dive in! 🚀

Command injection (also known as OS injection) is a type of security vulnerability that occurs when an application passes unsafe, user-supplied data to a system shell. This allows an attacker to execute arbitrary operating system (OS) commands on the server. Unlike other injection attacks that target specific components (like SQL injection targeting a database), command injection targets the underlying host operating system, making it one of the most dangerous vulnerabilities.

Developers often use system commands to leverage powerful and efficient utilities built into the OS, such as file manipulation tools (ls, wc, find), network utilities (curl, ping), or other custom binaries. The vulnerability arises when user input is concatenated into a command string that is then executed by a shell. The shell interprets special characters in the user input not as simple text, but as instructions to chain, modify, or execute new commands.

Suppose that in our pastebin application, we have an endpoint for getting file statistics (like word count) of uploaded files. This endpoint uses the system's wc command to count words in files. Without proper security measures, an attacker could manipulate the filename input to run commands far beyond the intended wc utility.

Now that we understand the basics of command injection and have context for our example, let's look at some vulnerable code to see how this attack works in practice.

Let's examine a code snippet that demonstrates a vulnerable endpoint. This example uses Python's subprocess module with FastAPI, a common way to interact with the system shell. The vulnerability is introduced when user input is directly formatted into a command string and executed with shell=True.

from fastapi import FastAPI, Request, HTTPException
import subprocess

app = FastAPI()

@app.post('/api/process/file-stats')
async def file_stats(request: Request):
    data = await request.json()
    filename = data.get('filename')
    # VULNERABLE: User input is directly inserted into a command string.
    # An attacker can add shell metacharacters like ';' to chain commands.
    command = f"wc {filename}"
    try:
        # DANGEROUS: `shell=True` causes the command string to be interpreted
        # by the system's shell (e.g., /bin/sh), which executes any injected commands.
        result = subprocess.run(command, shell=True, capture_output=True, text=True)
        if result.stderr:
            raise HTTPException(status_code=500, detail=result.stderr)
        return {'result': result.stdout}
    except Exception as e:
        raise HTTPException(status_code=500, detail=str(e))

In this code, the file_stats function takes a filename from a POST request. The core of the vulnerability lies in these two lines:

1. command = f"wc {filename}": The filename provided by the user is directly embedded into the command string. There is no sanitization or validation to check for malicious characters.
2. subprocess.run(command, shell=True, ...): The shell=True argument is critical. It tells subprocess to pass the entire command string to the system's default shell for execution. The shell then parses this string, and if it contains command separators (like ;), it will execute the commands sequentially.

This combination creates a perfect storm for command injection. Let's see how an attacker might exploit this.

An attacker can exploit this vulnerability by crafting a filename that includes shell metacharacters to append new commands. The semicolon (;) is a common choice in Unix-like systems because it acts as a command separator, allowing multiple commands to be run in sequence on a single line.

Here are two examples demonstrating how an attacker could use curl to send malicious JSON payloads to our vulnerable endpoint:

# Example 1: List directory contents
# The payload "test.txt; ls -la" becomes the command "wc test.txt; ls -la"
# The shell executes `wc` and then executes `ls -la`, returning the directory listing.
curl -X POST http://localhost:3000/api/process/file-stats \
  -H "Content-Type: application/json" \
  -d '{"filename": "test.txt; ls -la"}'

# Example 2: Access a sensitive file
# The payload "test.txt; cat /etc/passwd" becomes "wc test.txt; cat /etc/passwd"
# The shell executes `wc` and then `cat /etc/passwd`, returning the content of the password file.
curl -X POST http://localhost:3000/api/process/file-stats \
  -H "Content-Type: application/json" \
  -d '{"filename": "test.txt; cat /etc/passwd"}'

This attack works because the shell doesn't distinguish between the developer's intended command and the attacker's injected command. It simply receives a string and executes it. An attacker could use this technique to execute more dangerous commands, such as:

• Reading sensitive files: test.txt; cat /etc/passwd
• Writing to files to create backdoors: test.txt; echo '<hacked>' > /var/www/html/index.html
• Establishing a reverse shell for persistent access.

Now that we understand how the vulnerability can be exploited, let's look at a multi-layered approach to prevent these attacks.

The first step in preventing command injection is to perform basic validation on all user-supplied input. This is a fundamental security practice that acts as a first line of defense.

data = await request.json()
filename = data.get('filename')
# Check if the filename exists and is a string
if not filename or not isinstance(filename, str):
    raise HTTPException(status_code=400, detail='Invalid filename')

By checking that the filename is a non-empty string, we can filter out malformed requests (e.g., null values or incorrect data types). However, this check is not sufficient on its own. An attacker's payload ("test.txt; ls -la") is a valid, non-empty string. Therefore, we need stronger defenses to neutralize the actual threat.

A common attack vector combined with command injection is directory traversal, where an attacker uses sequences like ../ to navigate the file system and access files outside the intended directory. To prevent this, we must construct a safe file path by isolating the filename from any path information.

from pathlib import Path

# Strips any directory information, e.g., "../../etc/passwd" becomes "passwd"
base_name = Path(filename).name
# Safely join the base name with the current working directory
safe_path = Path.cwd() / base_name

# Ensure the file actually exists before trying to process it
if not safe_path.exists():
    raise HTTPException(status_code=404, detail='File not found')

Using Path(filename).name is a crucial step. It extracts only the filename component from the input string, effectively neutralizing any directory traversal attempts. For example, if an attacker provides ../../boot.ini, Path().name will return just boot.ini. We then join this sanitized base name with a trusted base directory (Path.cwd()). With our path now properly sanitized, we can move on to the most important step: implementing safe command execution.

The most effective way to prevent command injection is to avoid using a shell to interpret commands. Instead, we should pass the command and its arguments as a list, where each element is treated as a single, literal argument. This is achieved by setting shell=False (which is the default and recommended setting) in subprocess.run.

Here is the secure implementation of our endpoint:

from fastapi import FastAPI, Request, HTTPException
from pathlib import Path
import subprocess

app = FastAPI()

@app.post('/api/process/file-stats')
async def file_stats(request: Request):
    data = await request.json()
    filename = data.get('filename')
    # 1. Input validation
    if not filename or not isinstance(filename, str):
        raise HTTPException(status_code=400, detail='Invalid filename')

    # 2. Safe path construction
    base_name = Path(filename).name
    safe_path = Path.cwd() / base_name

    if not safe_path.exists():
        raise HTTPException(status_code=404, detail='File not found')

    try:
        # 3. Parameterized command execution
        # The command and its arguments are passed as a list.
        # `shell=False` ensures the input is treated as a literal argument, not executable code.
        result = subprocess.run(['wc', str(safe_path)], capture_output=True, text=True, shell=False)
        if result.stderr:
            raise HTTPException(status_code=500, detail=result.stderr)
        return {'result': result.stdout}
    except Exception:
        raise HTTPException(status_code=500, detail='File processing failed')

By using subprocess.run(['wc', str(safe_path)], shell=False), we are instructing the OS to execute the wc program and pass the value of safe_path as a single argument to it. If an attacker tries to inject a command like test.txt; ls -la, the safe_path variable will contain that entire string. The wc command will then try to find a file literally named "test.txt; ls -la", which will fail, and no secondary command will be executed. The shell's command parser is never invoked on the user input, completely mitigating the vulnerability.

As part of a defense-in-depth strategy, we can further harden our endpoint by restricting the types of files it is allowed to process. This reduces the application's attack surface by ensuring it only interacts with expected file types and prevents it from being used to execute uploaded scripts or other potentially dangerous files.

import os

# This check should be performed after constructing the safe_path
# and before executing the command.

allowed_extensions = ['.txt', '.md', '.log', '.csv']
_, file_extension = os.path.splitext(safe_path)
if file_extension.lower() not in allowed_extensions:
    raise HTTPException(status_code=400, detail='Invalid file type. Only text files are allowed.')

By whitelisting allowed extensions, you add another layer of validation. If an attacker manages to upload a shell script (e.g., backdoor.sh), this check would prevent the wc command from ever being run on it, even if other defenses were to fail.

Command injection vulnerabilities have led to several significant security breaches. The most notable example is the 2014 Shellshock vulnerability (CVE-2014-6271), which affected millions of web servers running Bash. It allowed attackers to execute arbitrary commands through specially crafted HTTP headers, leading to widespread system compromises. Additionally, numerous Internet of Things (IoT) devices have been compromised through command injection vulnerabilities in their web interfaces, leading to the creation of massive botnets (like Mirai) used for DDoS attacks.

The consequences of these attacks can be severe, including data breaches, complete system compromise, financial losses, and irreparable damage to a company's reputation. These real-world examples emphasize the critical importance of implementing proper security measures to prevent command injection attacks.

In this lesson, we've explored command injection vulnerabilities in file processing, demonstrated how they can be exploited, and discussed a multi-layered strategy for prevention. By understanding and applying these concepts—input validation, safe path construction, parameterized execution, and defense-in-depth—you can enhance the security of your web applications and protect against unauthorized command execution.

As you move on to the practice exercises, remember to apply the techniques you've learned to reinforce your understanding. Keep exploring related topics like secure file handling and vulnerability detection tools to further deepen your knowledge. Happy coding! 🎉