...
The process of canonicalizing file names also makes it easier to verify a path, directory, or file name by making it easier to compare names. This is because extraneous characters are eliminated during canonicalization. Validation after performing canonicalization is necessary in the absence of a security manager because untrusted user input may allow an input-output operation to escape the specified operating directory. Failure to do this can result in information disclosure and malicious modification of files existing in directories other than the specified one.
Noncompliant Code Example
This noncompliant code example accepts the a file path as a command line argument and uses the File.getAbsolutePath()
method to obtain the absolute file path. This method does not automatically resolve symbolic links. unmigrated-wiki-markupLet {{argv\[0\]}} be the string {{java/dirname/filename}}, where {{/tmp/java/}} is a symbolic link that points to the directory {{/dirname/}} present on the local file system.
The application desires to restrict the user from operating on files outside the {{/tmp
}} directory and uses a {{validate()
}} method to enforce this condition. An adversary who can create symbolic links in {{/tmp
}} can cause the program to pass validation checks by supplying the unresolved path. After the validation, any file operations performed are reflected in the file pointed to by the symbolic link.
Wiki Markup |
---|
Let {{argv\[0\]}} be the string {{filename}}, where {{/tmp/filename}} is a symbolic link that points to the file {{ pointed to by the symbolic link. If an attacker enters an unresolved input such as {{java/dirname/filename}}, present on the local file system. The validation will passpasses because the root directory of the compiled path name is still {{/tmp}}, but the operations will beare carried out on the file {{/dirname/filename}}. |
On Windows and Macintosh systems, this behavior is not observed. The symbolic link, Symbolic links, aliases and short cuts are fully resolved on these platforms.the Windows and Macintosh platforms when File.getAbsolutePath()
is used.
Code Block | ||
---|---|---|
| ||
public static void main(String[] args) { File f = new File("/tmp/" + args[0]); String absPath = f.getAbsolutePath(); if(!validate(absPath)) { // Validation throw new IllegalArgumentException(); } } |
Compliant Solution
This compliant solution uses the getCanonicalPath()
method, introduced in Java 2, because it resolves the aliases, shortcuts or symbolic links consistently, across all platforms. The value of the alias (if any) is not included in the returned value. Moreover, relative references like the double period (..) are also removed so that the input is reduced to a canonicalized form before validation is carried out. Consequently, this compliant solution is also compliant with IDS18-J. Prevent directory traversal attacks in that, an An adversary cannot use ../
sequences to break out of the specified directory when the validate()
method is present.
...
The getCanonicalPath()
method throws a security exception when used within applets as 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
.
Compliant solution
A comprehensive way of handling this issue is to grant the application the permissions to operate on files present only within /tmp
. This can be achieved by specifying the absolute path of the program in the security policy file and granting the java.io.FilePermission
with the target name as /tmp
and the actions as read
and write
. This is shown below.
Code Block | ||
---|---|---|
| ||
grant codeBase "file:/home/programpath/" {
permission java.io.FilePermission "/tmp", "read, write";
};
|
The guideline ENV02-J. Create a secure sandbox using a Security Manager contains more information on using a security manager.
Noncompliant Code Example
This noncompliant code example allows the user to specify the absolute path of a file name on which operations are required to be performed. If the user enters an argument that contains ../
sequences, it is possible to escape out of the /img
directory and operate on a file present in another directory.
Code Block | ||
---|---|---|
| ||
FileOutputStream fis = new FileOutputStream(new File("/img/" + args[0]));
// ...
|
Noncompliant Code Example
This noncompliant code example tries to mitigate the issue by using the File.getCanonicalPath()
method. This method fully resolves the argument and constructs a canonicalized path. For example, the path /img/../etc/passwd
resolves to /etc/passwd
. This is insecure because the program breaks out of the specified directory /img
.
Code Block | ||
---|---|---|
| ||
File f = new File("/img/" + args[0]);
String canonicalPath = f.getCanonicalPath();
FileOutputStream fis = new FileOutputStream(f);
// ...
|
Compliant Solution
This compliant solution obtains the canonicalized file name from the untrusted user input and validates it against the target file name, before operating on the file.
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
}
FileOutputStream fis = new FileOutputStream(f);
|
Compliant solution
A comprehensive way of handling this issue is to grant the application the permissions to read only the specific files or directory. This can be achieved by specifying the absolute path of the program in the security policy file and granting the java.io.FilePermission
with the target name as the absolute path of the file or directory and the action as read
. This is shown below.
Code Block | ||
---|---|---|
| ||
// All files in /img/java can be read grant codeBase "file:/home/programpath/" { permission java.io.FilePermission "/img/java", "read"; }; |
The guideline ENV02-J. Create a secure sandbox using a Security Manager contains more information on using a security manager.
Risk Assessment
Using path names from untrusted sources without first canonicalizing the filenames makes it difficult or impossible to validate file names and pathsbefore validating them can result in directory traversal attacks.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
FIO00- J | medium | unlikely | medium | P4 | L3 |
Automated Detection
TODO
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Other Languages
This rule appears in the C Secure Coding Standard as FIO02-C. Canonicalize path names originating from untrusted sources.
This rule appears in the C++ Secure Coding Standard as FIO02-CPP. Canonicalize path names originating from untrusted sources.
References
Wiki Markup |
---|
\[[API 06|AA. Java References#API 06]\] [method getCanonicalPath()|http://java.sun.com/javase/6/docs/api/java/io/File.html#getCanonicalPath()] \[[API 06|AA. Java References#API 06]\] [method getCanonicalFile()|http://java.sun.com/javase/6/docs/api/java/io/File.html#getCanonicalFile()] \[[Harold 99|AA. Java References#Harold 99]\] \[[MITRE 09|AA. Java References#MITRE 09]\] [CWE ID 171|http://cwe.mitre.org/data/definitions/171.html] "Cleansing, Canonicalization, and Comparison Errors", [CWE ID 647|http://cwe.mitre.org/data/definitions/647.html] "Use of Non-Canonical URL Paths for Authorization Decisions" |
...