...
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 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 to ensure that the file is in a secure directory. However, it neither resolves file links nor eliminates equivalence errors.
However, the user can still specify a file outside the intended directory by entering an argument that contains ../
sequences. An attacker can also create a link in the /img
directory that refers to a directory or file outside of that directory. The path name of the link might appear to reside in the /img
directory and consequently pass validation, but the operation will actually be performed on the final target of the link, which can reside outside the intended directory.
Code Block | |||
---|---|---|---|
| |||
File filepublic static void main(String[] args) { File f = new File(System.getProperty("user.home")/img/" + System.getProperty("file.separator") + args[0]); String absPath = f.getAbsolutePath(); if (!isInSecureDir(Paths.get(absPathfile))) { throw new IllegalArgumentException(); } FileOutputStream if (!validate(absPath)) { // Validation throw new IllegalArgumentException(fis = new FileOutputStream(file); } } |
The application intends to restrict the user from operating on files outside of his or her 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 the home directory that refers to a directory or file outside of the home directory. The path name of the link might appear to the validate()
method to reside in the user's 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 shortcuts 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.
...
// ...
|
Noncompliant Code Example (getCanonicalPath()
)
This compliant solution uses the noncompliant code example attempts to mitigate the issue by using the File.getCanonicalPath()
method, introduced in Java 2, because it resolves all aliases, shortcuts, and symbolic links consistently across all platforms. Special 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.
Code Block | ||
---|---|---|
| ||
public static void main(String[] args) throws IOException {
File f = new File(System.getProperty("user.home") + 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();
}
}
|
The 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
.
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 Block | ||
---|---|---|
| ||
grant codeBase "file:/home/programpath/" {
permission java.io.FilePermission "${user.home}/*", "read, write";
};
|
This solution requires that the user's home directory is a secure directory, as described in FIO00-J. Do not operate on files in shared directories.
Noncompliant Code Example
This noncompliant code example allows the user to specify the absolute path of a file name on which to operate. The user can specify files outside the intended directory (/img
in this example) by entering an argument that contains ../
sequences and consequently violates the intended security policies of the program.Unfortunately the canonicalization is performed before the validation, which renders the validation ineffective.
Code Block | ||
---|---|---|
| ||
FileOutputStreamFile fisfile = new FileOutputStream(new File("/img/" + args[0])); // ... |
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 Block | ||
---|---|---|
| ||
File f = new File("/img/" + args[0]); if (!isInSecureDir(file)) { throw new IllegalArgumentException(); } String canonicalPath = ffile.getCanonicalPath(); FileOutputStream fis = new FileOutputStream(fcanonicalPath); // ... |
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 ffile = new File("/img/" + args[0]); if (!isInSecureDir(file)) { throw new IllegalArgumentException(); } String canonicalPath = ffile.getCanonicalPath(); if (!canonicalPath.equals("/img/java/file1.txt") && !canonicalPath.equals("/img/java/file2.txt")) { // Invalid file; handle error } FileInputStream fis = new FileInputStream(f); |
The /img/java
directory must be secure to eliminate any race condition.
Compliant Solution (Security Manager)
This compliant solution grants A comprehensive way of handling this issue is to grant the application the permissions to read operate only on files present within the intended files or directories. For example, read permission is granted by specifying directory—the /img
directory in this example. This compliant solution specifies the absolute path of the program in the its security policy file and granting grants java.io.FilePermission
with the canonicalized absolute path of the file or directory as the target name and with the action set to read
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"; }; |
...
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 |
...