Page History

...

Absolute or relative path names may contain file links such as symbolic (soft) links, hard links, short cuts, shadows, aliases, and junctions rather than canonical paths. 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:

...

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

The process of canonicalizing file names makes it easier to validate an 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 making make security decisions based upon 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. During this time While the canonical path name is being validated. However, also during this time the canonical path name the file system may have been modified and the canonical path name may no longer be referencing reference the original valid file. Fortunately, this race condition can be easily mitigated. The canonical path name can be used to determine if whether the referenced file name is in a secure directory (see rule FIO00-J. Do not operate on files in shared directories 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. Normalize strings before validating them.

...

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. Do not operate on files in shared directories to ensure that the file is in a secure directory. But it does not resolve However, it neither resolves file links or eliminate nor eliminates equivalence errors.

public static void main(String[] args) {
  File f = new File("/home/me/" + args[0]);
  String absPath = f.getAbsolutePath();

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

The application intends to restrict the user me from operating on files outside the /home/me directory. The validate() method ensures attempts to ensure 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 the home directory /home/me 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 /home/me 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.

...

This compliant solution uses the getCanonicalPath() method, introduced in Java 2, because it resolves all aliases, shortcuts, or 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.

...

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 the user an attacker can specify files outside the intended directory.

...

Bibliography

...