Page History

...

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.

An absolute Absolute or relative path names may contain aliasesfile links such as symbolic (soft) links, hard links, short cuts, shadows, symbolic links and shortcuts ( aliases, hereafter) and junctions rather than canonical paths, which refer to the actual files or directories that these point to. These aliases must be fully resolved before any file validation operations are performed. For instanceexample, 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:

1. “.” refers to the directory itself.
2. 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 and file system specific naming conventions which make validation difficult.

The process of canonicalizing file names makes it easier to verify validate an aliaspath name. More than one alias path name can refer to a single directory or file. Further, the textual representation of an alias path name may yield little or no information regarding the directory or file to which it refers. Consequently, all aliases path names must be fully resolved or canonicalized before validation.

This is necessary because operating on untrusted user input may allow result in a directory traversal or path equivalence vulnerability. A directory traversal vulnerability allows an I/O operation to escape the a specified operating directory. Violation of this rule can result in information disclosure and malicious modification of files existing in directories other than the specified oneA path equivalence vulnerabilities occur when an attacker provides a different but equivalent name for a resource to bypass security checks.

This rule is an a specific instance of 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. This method does not automatically resolve symbolic file links or eliminate equivalence errors.

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

  if (!validate(absPath)) {  // Validation
    throw new IllegalArgumentException();
  }		  
}

The application intends to restrict the user from operating on files outside the {{/tmp}} directory and uses a {{validate()}} method to enforce this condition

Let {{argv\[0\]}} be the string {{filename}}, where. The path name validation can be easily circumvented.  For example, an attacker who can create symbolic links in {{/tmp}} can cause the program to pass validation checks by supplying the unresolved path. All file operations performed are reflected in the file pointed to by the symbolic link. If the string {{filename}} is passed as {{argv\[0\]}} and {{/tmp/filename}} is a symbolic link that pointsrefers to the file {{/dirname/filename}} present on the localvalidation file systempasses. The validationThis passesis because the root directory of the compiled path name is still {{/tmp}}, but the operations are carried out on the file {{/dirname/filename}}.

Note that File.getAbsolutePath() actually does resolve all 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.

...

Using path names from untrusted sources without first canonicalizing them and then validating them can result in directory traversal attacksand ath equivalence vulnerabilities.

Other Languages

...

Related Guidelines

...

...

...

...

...

Related Vulnerabilities

...

...