EXC06-J. Do not allow exceptions to expose sensitive information

Failure to filter sensitive information when propagating exceptions often results in information leaks that can assist an attacker's efforts to expand the attack surface. An attacker may craft input parameters that attempt to provoke exposure of internal structures and mechanisms of the application. Both the exception message text and the type of an exception can leak information information. For example, given an exception of type FileNotFoundException, the message reveals information regarding the file system layout and the exception type reveals the absence of the requested file.

This guideline applies to server side applications as well as to clients. Adversaries can glean sensitive information not only from vulnerable web servers but also from innocent users who use vulnerable web browsers. In 2004, Schoenefeld discovered an exploit for the Opera v7.54 web browser, wherein an attacker could use the sun.security.krb5.Credentials class in an applet as an oracle to "retrieve the name of the currently logged in user and parse his home directory from the information which is provided by the thrown java.security.AccessControlException" [[Schoenefeld 2004]].

All errors reveal information that can assist an attacker's efforts to carry out a denial of service against the system. Consequently, programs must filter both exception messages and exception types that can propagate across trust boundaries. The table shown below lists a few sensitive errors and exceptions:

Noncompliant Code Example (Leaks from Exception Message and Type)

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.

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 name.

Noncompliant Code Example (rethrowing sensitive exception)

This noncompliant code example logs the exception and re-throws it without performing adequate message sanitization.

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

Noncompliant Code Example (Wrapping and Rethrowing Sensitive Exception)

This noncompliant code example logs the exception and wraps it in an unchecked exception before re-throwing it.

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

Compliant Solution (Forward to Dedicated Handler or Reporter)

This compliant solution 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 solution.

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 
    } 
  }
}

Notice that this example catches Throwable rather than a more specific exception. This departure from commonly suggested best practices is critical in cases where runtime exceptions or errors can reveal sensitive information. This solution overcomes the potential brute force attack described earlier by accepting only an enumerated set of file name choices with the help of a switch-case clause. Consequently, the actual file names and paths are hidden from the user of the application.

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.

Risk Assessment

Exceptions may inadvertently reveal sensitive information unless care is taken to limit the information disclosure.

Related Vulnerabilities

CVE-2009-2897

Other Languages

This guideline appears in the C++ Secure Coding Standard as ERR12-CPP. Do not allow exceptions to transmit sensitive information.

Bibliography

[[Gong 2003]] 9.1 Security Exceptions
[[MITRE 2009]] CWE ID 209 "Error Message Information Leak", CWE ID 600 "Failure to Catch All Exceptions (Missing Catch Block)", CWE ID 497 "Information Leak of System Data"
[[SCG 2007]] Guideline 3-4 Purge sensitive information from exceptions

ERR05-J. Handle checked exceptions that can be thrown within a finally block      06. Exceptional Behavior (EXC)      EXC07-J. Prevent exceptions while logging data