You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

An absolute path may sometimes contain aliases, shadows, symbolic links and shortcuts as opposed to canonical paths, which refer to actual files/directories that these point to. Canonicalizing file names makes it much easier to verify a path, directory, or file name by making it easier to compare names.

Noncompliant Code Example

In this example, the user inputs a part of the path as a command line argument. Let argv[1] be "java" where /tmp/java is a symbolic link that points to another file in some directory. On UNIX, the getAbsolutePath() method includes /tmp/java (name of the symbolic link) in the path that it returns. On the other hand, on Windows and Macintosh systems, this behavior is not observed. The symbolic link is fully resolved in this case leading to implementation defined behavior.

public static void main(String[] args) {

   try {
	
     File f = new File("/tmp/" + args[1]);
     String absPath = f.getAbsolutePath();
   }
   catch(IOException ie) {}
}

Compliant Solution

Use the getCanonicalPath() method wherever possible since it resolves the aliases, shortcuts or symbolic links across all platforms. The value of the alias is not included in the returned value. Moreover, relative references like the double period (..) are also removed. The getCanonicalPath() method throws a security exception when used within applets since it reveals too much information about the host machine. The getCanonicalFile() method (Java 2) behaves like getCanonicalPath() but returns a new File object instead of a String.

public static void main(String[] args) {

  try {	
    File f = new File("/tmp/" + args[1]);
    String canonicalPath = f.getCanonicalPath();
  }
  catch(IOException ie) {}
}

Risk Assessment

Using path names from untrusted sources without first canonicalizing the filenames involved may seriously compromise the security of a Java application.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

FIO01-J

high

probable

high

P6

L2

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

[[Harold 99]]

  • No labels