HIGH command injectionspring boot

Command Injection in Spring Boot

Spring Boot-Specific Remediation

Spring Boot provides several native approaches to prevent command injection. The most secure method is avoiding system command execution entirely by using Java libraries for file operations, HTTP requests, and other tasks:

// Instead of ProcessBuilder for file operations:
import java.nio.file.*;
import java.io.IOException;

@Service
public class FileService {
    
    public String listFiles(String directory) throws IOException {
        // Safe file operations using Java NIO
        Path path = Paths.get(directory).normalize();
        if (!path.startsWith(Paths.get("/uploads"))) {
            throw new IllegalArgumentException("Invalid directory");
        }
        
        return Files.list(path)
            .map(Path::toString)
            .collect(Collectors.joining("\n"));
    }
}

For HTTP requests that might have been implemented with curl, use Spring Boot's WebClient or RestTemplate:

@Service
public class HttpService {
    
    public String fetchContent(String url) {
        // Safe HTTP client instead of ProcessBuilder
        WebClient client = WebClient.create();
        return client.get()
            .uri(url)
            .retrieve()
            .bodyToMono(String.class)
            .block();
    }
}

When system commands are unavoidable, use parameterized execution and strict input validation:

@Service
public class CommandService {
    
    public String executeSafeCommand(String fileName) throws IOException {
        // Validate input against whitelist
        if (!fileName.matches("^[a-zA-Z0-9_.-]+$")) {
            throw new IllegalArgumentException("Invalid filename");
        }
        
        // Use ProcessBuilder with argument separation
        ProcessBuilder pb = new ProcessBuilder("ls", "-la", "/uploads/" + fileName);
        pb.redirectErrorStream(true);
        
        Process process = pb.start();
        return process.getInputStream().readAllBytes();
    }
}

For Spring Boot applications using @ShellComponent, implement strict input validation and avoid exposing shell methods to untrusted users:

@ShellComponent
public class SecureCommands {
    
    @ShellMethod("Safe file listing")
    public String listFiles(@ShellOption String directory) {
        // Strict validation and path normalization
        Path path = Paths.get(directory).normalize();
        if (!path.startsWith(Paths.get("/safe/directory"))) {
            throw new IllegalArgumentException("Access denied");
        }
        
        try {
            return Files.list(path)
                .map(Path::toString)
                .collect(Collectors.joining("\n"));
        } catch (IOException e) {
            throw new RuntimeException(e);
        }
    }
}

Related CWEs: inputValidation

CWE IDNameSeverity
CWE-20Improper Input Validation HIGH
CWE-22Path Traversal HIGH
CWE-74Injection CRITICAL
CWE-77Command Injection CRITICAL
CWE-78OS Command Injection CRITICAL
CWE-79Cross-site Scripting (XSS) HIGH
CWE-89SQL Injection CRITICAL
CWE-90LDAP Injection HIGH
CWE-91XML Injection HIGH
CWE-94Code Injection CRITICAL

Frequently Asked Questions

How can I test my Spring Boot application for command injection vulnerabilities?
Use middleBrick's black-box scanning by submitting your API endpoint URL. The scanner tests for command injection by sending payloads with command separators (;), pipes (|), and other injection patterns to parameters that might be used for system commands. It analyzes responses for indicators like process IDs, system information, or timing differences that suggest command execution.
Are Spring Boot Actuator endpoints vulnerable to command injection?
Spring Boot Actuator endpoints can be vulnerable if misconfigured or if they expose functionality that allows command execution. middleBrick scans for exposed Actuator endpoints and tests them with command injection payloads. Always secure Actuator endpoints with authentication and only expose necessary endpoints in production.