Page History

{quote}
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.

{quote}

Absolute or relative path names may contain file links such as symbolic (soft) links, hard links, short cuts, shadows, aliases, and junctions. These file links must be fully resolved before any file validation operations are performed. For example, the final target of a symbolic link called {{trace}} might be the path name {{/home/system/trace}}.  Path names may also contain special file names that make validation difficult:

# "." refers to the directory itself.

# Inside a directory, the special file name ".." refers to the directory's parent directory.

In addition to these specific issues, there are a wide variety of operating system-specific and file system-specific naming conventions that make validation difficult.

The process of canonicalizing file names makes it easier to validate a path name. More than one path name can refer to a single directory or file. Further, the textual representation of a 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.

Validation may be necessary, for example, when attempting to restrict user access to files within a particular directory or otherwise make security decisions based on 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 vulnerability occurs when an attacker provides a different but equivalent name for a resource to bypass security checks.

Canonicalization contains an inherent race window between the time the program obtains the canonical path name and the time it opens the file. While the canonical path name is being validated, the file system may have been modified and the canonical path name may no longer reference the original valid file. Fortunately, this race condition can be easily mitigated.  The canonical path name can be used to determine whether the referenced file name is in a secure directory (see rule FIO00-J

 for more information). If the referenced file is in a secure directory, then, by definition, an attacker cannot tamper with it and cannot exploit the race condition.

This rule is a specific instance of rule IDS01-J.

h2. Noncompliant Code Example

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 rule FIO00-J

 from operating on files

 outside of their home directory.  The {{validate()}} method attempts to ensure that the path name resides within this directory, but can be easily circumvented.  For example,

 a user

 can create a link in

 their home directory

 that refers to a directory or file outside of their home directory.  The path name of the link might appear to the {{validate()}} method to reside in

 their home directory and consequently pass validation, but the operation will actually be performed on the final target of the link, 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 _Java Language Specification_ (JLS) lacks any guarantee that this behavior is present on _all_ platforms or that it will continue in future implementations.

h2. Compliant Solution ({{getCanonicalPath()}})

This compliant solution uses the {{getCanonicalPath()}} method, introduced in Java 2, because it resolves all aliases, shortcuts, and symbolic links consistently across all platforms. 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.

{code

:bgColor

=#ccccff

}
public static void main(String[] args) throws IOException {
  File f = new File(System.getProperty("/user.home/me/") + System.getProperty("file.separator")+ args[0]);
  String canonicalPath = f.getCanonicalPath();

  if (!isInSecureDir(Paths.get(canonicalPath))) {
    throw new IllegalArgumentException();
  }
  if (!validate(canonicalPath)) {  // Validation
    throw new IllegalArgumentException();
  }
}

{code}

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

}}.


h2. 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 user's home 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

 ${user.home}/

* and actions {{read}} and {{write}}.

{code

:bgColor

=#ccccff

}
grant codeBase "file:/home/programpath/" {
  permission java.io.FilePermission "/${user.home}/me*", "read, write";
};
{code}

This solution requires

{code}


h2. Noncompliant Code Example

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}}.  Canonicalization without validation is insufficient because an attacker can specify files outside the intended directory.

{code

:bgColor

=#FFCCCC

}
File f = new File("/img/" + args[0]);
String canonicalPath = f.getCanonicalPath();
FileOutputStream fis = new FileOutputStream(f);
// ...

 Compliant Solution (Security Manager)

This compliant solution grants the application the permissions to read only the intended files or directories. 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}}.

{code

:bgColor

=#ccccff

}
// All files in /img/java can be read
grant codeBase "file:/home/programpath/" {
  permission java.io.FilePermission "/img/java", "read";
};

{code}


h2. 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 ||
| IDS02-J | medium | unlikely | medium | {color:green}P4{color} | {color:green}L3{color} |

h3. Related Vulnerabilities

[CVE-2005-0789|http://cve.mitre.org/cgi-bin/cvename.cgi?name=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|http://cve.mitre.org/cgi-bin/cvename.cgi?name=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.

h2. Related Guidelines

| [The CERT C Secure Coding Standard|seccode:CERT C Secure Coding Standard] | [FIO02-C. Canonicalize path names originating from untrusted sources|seccode:FIO02-C. Canonicalize path names originating from untrusted sources] |
| [The CERT C+\+ Secure Coding Standard|cplusplus:CERT C++ Secure Coding Standard] | [FIO02-CPP. Canonicalize path names originating from untrusted sources|cplusplus:FIO02-CPP. Canonicalize path names originating from untrusted sources] |
| [ISO/IEC TR 24772:2010|http://www.aitcnet.org/isai/]

 | Path Traversal \[EWR

\] |
| [MITRE CWE|http://cwe.mitre.org/] | [CWE-171|http://cwe.mitre.org/data/definitions/171.html]. Cleansing, Canonicalization, and Comparison Errors |
| | [CWE-647|http://cwe.mitre.org/data/definitions/647.html]. Use of Non-Canonical URL Paths for Authorization Decisions |


h2. Bibliography

| \[[API 2006|AA. Bibliography#API 06]\] | [method getCanonicalPath()|http://java.sun.com/javase/6/docs/api/java/io/File.html#getCanonicalPath()] |
| \[[Harold 1999|AA. Bibliography#Harold 99]\] | |


----
[!The CERT Oracle Secure Coding Standard for Java^button_arrow_left.png!|IDS01-J. Normalize strings before validating them]      [!The CERT Oracle Secure Coding Standard for Java^button_arrow_up.png!|00. Input Validation and Data Sanitization (IDS)]      [!The CERT Oracle Secure Coding Standard for Java^button_arrow_right.png!|IDS03-J. Do not log unsanitized user input]