Wiki Markup |
---|
According to the Java API \[[API 2006|AA. Bibliography#API 06]\], for class {{java.io.File}} |
A path name, whether abstract or in string form, may be either absolute or relative. An absolute path name is complete in that no other information is required to locate the file that it denotes. A relative path name, in contrast, must be interpreted in terms of information taken from some other path name.
...
The process of canonicalizing file names makes it easier to validate an path name. More than one path name can refer to a single directory or file. Further, the textual representation of an path name may yield little or no information regarding the directory or file to which it refers. Consequently, all path names must be fully resolved or canonicalized before validation.
This is necessary because operating on untrusted user input may result in Validation may be necessary, for example, when attempting to restrict user access to files within a particular directory, or otherwise making security decisions based upon the name of a file name or path name. Frequently, these restrictions can be circumvented by an attacker by exploiting a directory traversal or path equivalence vulnerability. A directory traversal vulnerability allows an I/O operation to escape a specified operating directory. A path equivalence vulnerabilities occur when an attacker provides a different but equivalent name for a resource to bypass security checks.
...
This noncompliant code example accepts a file path as a command line argument and uses the File.getAbsolutePath()
method to obtain the absolute file path. It also uses the isInSecureDir()
method defined in FIO00-J. Do not operate on files in shared directories (or equivalent method) to ensure that the file is in a secure directory but does not resolve file links or eliminate equivalence errors.
...
The application intends to restrict the user me
from operating on files outside the /home/me
directory. The validate()
method ensures that the path name resides within this directory, but the validation can be easily circumvented. For example, the user me
can create a link in their home directory /home/me
that refers to a directory or file outside of the directory. The path name of the link might appear to the validate()
method to reside in the /home/me
and consequently pass validation, but the operation will actually be performed on the final target of the link residing , which resides outside the intended directory.
Note that File.getAbsolutePath()
does resolve symbolic links, aliases, and short cuts on Windows and Macintosh platforms. Nevertheless, the JLS lacks any guarantee that this behavior is present on all platforms or that it will continue in future implementations.
...
Noncompliant Code Example
The following code examples assume that /img
and /img/java
are secure directories.
This noncompliant code example attempts to mitigate the issue by using the File.getCanonicalPath()
method, which fully resolves the argument and constructs a canonicalized path. For example, the path /img/../etc/passwd
resolves to /etc/passwd
. Validation without canonicalization remains is insecure because the user can specify files outside the intended directory.
...
Code Block | ||
---|---|---|
| ||
File f = new File("/img/" + args[0]); String canonicalPath = f.getCanonicalPath(); if (canonicalPath.equals("/img/java/file1.txt")) { // Validation // Do something } if (!canonicalPath.equals("/img/java/file2.txt")) { // Validation // Do something } FileOutputStreamFileInputStream fis = new FileOutputStreamFileInputStream(f); |
The /img/java
directory must be secure to eliminate any race condition.
Compliant solution (Security Manager)
A comprehensive solution is to grant This compliant solution grants the application the permissions to read only the specifically intended files or directories. Grant these permissions by to For example, read permission is granted by specifying the absolute path of the program in the security policy file and granting java.io.FilePermission
with the canonicalized absolute path of the file or directory as the target name and with the action set to read
.
...
Recommendation | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
IDS02-J | medium | unlikely | medium | P4 | L3 |
Related Vulnerabilities
CVE-2005-0789 describes a directory traversal vulnerability in LimeWire 3.9.6 through 4.6.0 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 allow remote attackers to upload files to arbitrary directories.
Related Guidelines
FIO02-C. Canonicalize path names originating from untrusted sources | ||||
FIO02-CPP. Canonicalize path names originating from untrusted sources<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="f8bcea6c-fda0-4474-8673-1b0572c68812"><ac:plain-text-body><![CDATA[ | ||||
[[MITRE 2009 | AA. Bibliography#MITRE 09]] | [CWE ID 171 | CWE ID 171 http://cwe.mitre.org/data/definitions/171.html] "Cleansing, Canonicalization, and Comparison Errors"]]></ac:plain-text-body></ac:structured-macro> | |
| CWE ID 647 "Use of Non-Canonical URL Paths for Authorization Decisions" |
...
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="d32fdb7134e30b6c-27b6737d-4d184e9f-b899bb31-49c1d62b86859e378beb6c92"><ac:plain-text-body><![CDATA[ | [[API 2006 | AA. Bibliography#API 06]] | [method getCanonicalPath() | http://java.sun.com/javase/6/docs/api/java/io/File.html#getCanonicalPath()] | ]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="12ca2f85caaac6a4-8a37300a-452947eb-90858b6f-0faa13650538a5b14d31d1d6"><ac:plain-text-body><![CDATA[ | [[Harold 1999 | AA. Bibliography#Harold 99]] |
| ]]></ac:plain-text-body></ac:structured-macro> |
...