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 ID | Name | Severity |
|---|---|---|
| CWE-20 | Improper Input Validation | HIGH |
| CWE-22 | Path Traversal | HIGH |
| CWE-74 | Injection | CRITICAL |
| CWE-77 | Command Injection | CRITICAL |
| CWE-78 | OS Command Injection | CRITICAL |
| CWE-79 | Cross-site Scripting (XSS) | HIGH |
| CWE-89 | SQL Injection | CRITICAL |
| CWE-90 | LDAP Injection | HIGH |
| CWE-91 | XML Injection | HIGH |
| CWE-94 | Code 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.