Page History

...

Noncompliant Code Example (Leaks from Exception Message and Type)

Consider a program that must read a file supplied by the user, but the contents and layout of the filesystem might be considered sensitive. This noncompliant code example accepts a file name as an input argument. An attacker can learn about the structure of the underlying file system by repeatedly passing constructed paths to fictitious files. When a requested file is absent, the FileInputStream constructor throws a FileNotFoundException, while doing nothing to prevent any resulting exceptions from being presented to the user.

class ExceptionExample {
  public static void main(String[] args) throws FileNotFoundException {
    // Linux stores a user's home directory path in the environment variable 
    // $HOME, Windows in %APPDATA%
    FileInputStream fis = new FileInputStream(System.getenv("APPDATA") + args[0]);  
  }
}

This attack is possible even when the application displays only a sanitized message when the file is absent. Failure to restrict user input leaves the system vulnerable to a brute force attack in which the attacker discovers valid file names via repeated queries that collectively cover the space of possible filenames; queries that result in the sanitized message exclude the requested file, the remaining possibilities represent the actual files.

This noncompliant example fails to sanitize the exception, consequently enabling the attacker to learn the user's home directory and user nameAn attacker can learn about the structure of the underlying file system by repeatedly passing constructed paths to fictitious files to the program. When a requested file is absent, the FileInputStream constructor throws a FileNotFoundException.

Noncompliant Code Example (

...

Wrapping and Rethrowing Sensitive Exception)

This noncompliant code example logs the exception and wraps it in an unchecked exception before re-throws throwing it without performing adequate message sanitization.

try {
  FileInputStream fis = new FileInputStream(System.getenv("APPDATA") + args[0]);
} catch (FileNotFoundException e) {
  // Log the exception
  throw new IOException("Unable to retrieve file", e);
}

Even if the logged exception is not accessible to the user, the original exception is still informative and can be used by an attacker to learn sensitive information about the filesystem layout.

Noncompliant Code Example (

...

Sanitized Exception)

This noncompliant code example logs the exception and wraps it in an unchecked exception before re-throwing itthrows a custom exception that does not wrap the FileNotFoundException.

class SecurityIOException extends IOException {/* ... */};

try {
  FileInputStream fis = new FileInputStream(System.getenv("APPDATA") + args[0]);
} catch (FileNotFoundException e) {
  // Log the exception
  throw new RuntimeException("Unable to retrieve file", eSecurityIOException();
}

While this exception is more cryptic to info disclosure than previous examples, it still reveals that the file being specified cannot be read. More specifically, the program reacts differently to nonexistant file paths than it does to valid ones, and an attacker can still infer sensitive information about the filesystem from this program's behavior. Failure to restrict user input leaves the system vulnerable to a brute force attack in which the attacker discovers valid file names via repeated queries that collectively cover the space of possible filenames; queries that result in the sanitized message exclude the requested file, the remaining possibilities represent the actual files.

Compliant Solution (

...

Canonicalization)

This compliant solution operates under the policy that only files that live in c:\homepath may be opened by the user, and that the user must not learn anything about files outside this directory. So it issues a terse error message if the file cannot be opened, or the file does not live in the proper directory. This serves to conceal any information about files outside c::\homepath.

The compliant solution also uses the File.getCanonicalFile() method to canonicalize the file, so that the subsequent pathname comparison cannot be foiled by spurious instances of "\.", or symbolic links, or capitalization.

class ExceptionExample {
  public static void main(String[] args) {
    File file = null;
    try {
      file = new File(System.getenv("APPDATA") + args[0]).getCanonicalFile();
      if (!file.getPath().startsWith("c:\\homepath")) {
        System.out.println("Invalid file");
        return;
      }
    } catch (IOException x) {
      System.out.println("Invalid file");
      return;
    }

    try {
      FileInputStream fis = new FileInputStream( file);
    } catch (FileNotFoundException x) {
      System.out.println("Invalid file");
      return;
    }
  }
}

Compliant Solution (Restricted Input)

This compliant solution operates under the policy that only c:\homepath\file1 and c:\homepath\file2 are permitted to be opened by the user.

It also catches Throwable, as warranted by EX0 of ERR14-J. Catch specific exceptions rather than the more general RuntimeException or Exception, It also uses catches and sanitizes the exception and its message before allowing the exception to propagate to the caller. In cases where the exception type itself can reveal too much information, consider throwing a different exception altogether (with a different message, or possibly a higher level exception; this is exception translation). One good solution is to use the MyExceptionReporter class described in guideline ERR01-J. Use a class dedicated to reporting exceptions, as shown in this compliant solutionwhich handles responsibility for filtering sensitive information from any resulting exceptions.

class ExceptionExample {
  public static void main(String[] args) {
    try {
      FileInputStream fis = null;
      switch(Integer.valueOf(args[0])) {
        case 1: 
          fis = new FileInputStream("c:\\homepath\\file1"); 
          break;
        case 2: 
          fis = new FileInputStream("c:\\homepath\\file2");
          break;
        //...
        default:
          System.out.println("Invalid option"); 
          break;
      }      
    } catch(Throwable t) { 
      MyExceptionReporter.report(t); // Sanitize 
    } 
  }
}

...

Compliant solutions must ensure that security exceptions such as java.security.AccessControlException and java.lang.SecurityException continue to be logged and sanitized appropriately. See guideline ERR03-J. Use a logging API to log critical security exceptions for additional information. The MyExceptionReporter class from guideline ERR01-J. Use a class dedicated to reporting exceptions demonstrates an acceptable approach for this logging and sanitization.

...