External programs are commonly invoked to perform a function required by the overall system. This practice is a form of reuse and might even be considered a crude form of component-based software engineering. Command and argument injection vulnerabilities occur when an application fails to sanitize untrusted input and uses it in the execution of external programs.
...
Consequently, command injection attacks cannot succeed unless a command interpreter is explicitly invoked. However, argument injection attacks can occur when arguments have spaces, double quotes, and so forth, or when they start with a -
or /
to indicate a switch.
This rule is a specific instance of rule IDS00-J. Sanitize untrusted data passed across a trust boundary. Any string data that originates from outside the program's trust boundary must be sanitized before being executed as a command on the current platform.
...
This noncompliant code example provides a directory listing using the dir
command. This It is implemented using Runtime.exec()
to invoke the Windows dir
command.
...
Code Block |
---|
java -Ddir='dummy & echo bad' Java |
the The command executed is actually two commands:
...
The attacker can supply the same command shown in the previous noncompliant code example with similar effects. The command executed is actually:
Code Block |
---|
sh -c 'ls dummy & echo bad' |
...
Code Block | ||
---|---|---|
| ||
// ... if (!Pattern.matches("[0-9A-Za-z@.]+", dir)) { // Handle error } // ... |
Although this it is a compliant solution, this sanitization approach rejects valid directories. Also, because the command interpreter invoked is system dependent, it is difficult to establish that this solution prevents command injections on every platform on which a Java program might run.
...
This compliant solution prevents command injection by passing only trusted strings to Runtime.exec()
. While the The user has control over which string is used , the user but cannot provide string data directly to Runtime.exec()
.
Code Block | ||
---|---|---|
| ||
// ... String dir = null; int number = Integer.parseInt(System.getProperty("dir")); // onlyOnly allow integer choices switch (number) { case 1: dir = "data1"; break; // Option 1 case 2: dir = "data2"; break; // Option 2 default: // invalidInvalid break; } if (dir == null) { // handleHandle error } |
This compliant solution hard codes the directories that may be listed.
...
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
IDS07-J | High | Probable | Medium | P12 | L1 |
Related Vulnerabilities
Related Guidelines
ENV03-C. Sanitize the environment when invoking external programs | |||
| ENV04-C. Do not call system() if you do not need a command processor | ||
ENV03-CPP. Sanitize the environment when invoking external programs |
| ENV04-CPP. Do not call system() if you do not need a command processor | |
The CERT Perl Secure Coding Standard | IDS34-PL. Do not pass untrusted, unsanitized data to a command interpreter | ||
Injection [RST] | |||
CWE-78. , Improper neutralization of special elements used in an OS command ("OS command injection") |
Bibliography
Chapter 5, "Handling Input," section "Command Injection" | |
[OWASP 2005] | A Guide to Building Secure Web Applications and Web Services |
[Permissions 2008] | Permissions in the Java™ SE 6 Development Kit (JDK) |
...
IDS06-J. Exclude user input from format strings IDS08-J. Sanitize untrusted data passed to a regex