...
This recommendation is a specific instance of IDS01-J. Normalize strings before validating them.
Noncompliant Code Example
This noncompliant code example allows the user to specify the path of an image file to open. By prepending /img/
to the directory this code enforces a policy that only files in this directory should be opened. The program also uses the isInSecureDir()
method defined in FIO00-J. Do not operate on files in shared directories.
...
Code Block | ||
---|---|---|
| ||
File file = new File("/img/" + args[0]); if (!isInSecureDir(file)) { throw new IllegalArgumentException(); } FileOutputStream fis = new FileOutputStream(file); // ... |
Noncompliant Code Example (getCanonicalPath()
)
This noncompliant code example attempts to mitigate the issue by using the File.getCanonicalPath()
method, introduced in Java 2, which fully resolves the argument and constructs a canonicalized path. Special file names such as dot dot (..
) are also removed so that the input is reduced to a canonicalized form before validation is carried out. An attacker cannot use ../
sequences to break out of the specified directory when the validate() method is present. For example, the path /img/../etc/passwd
resolves to /etc/passwd
. The getCanonicalPath()
method throws a security exception when used within applets because it reveals too much information about the host machine. The getCanonicalFile()
method behaves like getCanonicalPath()
but returns a new File
object instead of a String
.
...
Code Block | ||
---|---|---|
| ||
File file = new File("/img/" + args[0]); if (!isInSecureDir(file)) { throw new IllegalArgumentException(); } String canonicalPath = file.getCanonicalPath(); FileOutputStream fis = new FileOutputStream(canonicalPath); // ... |
Compliant Solution (getCanonicalPath()
)
This compliant solution obtains the file name from the untrusted user input, canonicalizes it, and then validates it against a list of benign path names. It operates on the specified file only when validation succeeds; that is, only if the file is one of the two valid files file1.txt
or file2.txt
in /img/java
.
Code Block | ||
---|---|---|
| ||
File file = new File("/img/" + args[0]); if (!isInSecureDir(file)) { throw new IllegalArgumentException(); } String canonicalPath = file.getCanonicalPath(); if (!canonicalPath.equals("/img/java/file1.txt") && !canonicalPath.equals("/img/java/file2.txt")) { // Invalid file; handle error } FileInputStream fis = new FileInputStream(f); |
Compliant Solution (Security Manager)
A comprehensive way of handling this issue is to grant the application the permissions to operate only on files present within the intended directory—the /img
directory in this example. This compliant solution specifies the absolute path of the program in its security policy file and grants java.io.FilePermission
with target /img/java
and the read action.
This solution requires that the /img
driectory is a secure directory, as described in FIO00-J. Do not operate on files in shared directories.
Code Block | ||
---|---|---|
| ||
// All files in /img/java can be read grant codeBase "file:/home/programpath/" { permission java.io.FilePermission "/img/java", "read"; }; |
Risk Assessment
Using path names from untrusted sources without first canonicalizing them and then validating them can result in directory traversal and path equivalence vulnerabilities.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
IDS02FIO16-J | medium | unlikely | medium | P4 | L3 |
Automated Detection
Tool | Version | Checker | Description |
---|---|---|---|
Coverity | 7.5 | BAD_EQ PATH_MANIPULATION | Implemented |
Fortify | 1.0 | Path_Manipulation | Implemented |
Related Vulnerabilities
CVE-2005-0789 describes a directory traversal vulnerability in LimeWire 3.9.6 through 4.6.0 that allows remote attackers to read arbitrary files via a .. (dot dot) in a magnet request.
CVE-2008-5518 describes multiple directory traversal vulnerabilities in the web administration console in Apache Geronimo Application Server 2.1 through 2.1.3 on Windows that allow remote attackers to upload files to arbitrary directories.
Related Guidelines
FIO02-C. Canonicalize path names originating from tainted sources | |
FIO02-CPP. Canonicalize path names originating from untrusted sources | |
Path Traversal [EWR] | |
CWE-171, Cleansing, canonicalization, and comparison errors |
Android Implementation Details
This rule is applicable in principle to Android. Please refer to the Android specific instance of this rule: DRD08-J. Always canonicalize a URL received by a content provider.
Bibliography
...