Page History

Propagating the contents of exceptions without explicitly filtering sensitive information often results in information leaks and lets an attacker build the attack surface. An attacker may craft input parameters such that underlying structures and mechanisms of the application are inadvertently exposed. Information leaks can result from both - the exception message text and the type of exception. For example, with FileNotFoundException, the message reveals the file system layout while the type conveys the absence of the file.

This guideline extends equally to server side applications as well as clients. Adversaries can glean sensitive information from not only vulnerable web servers but also from innocent users who use vulnerable web browsers. In 2004, Schoenefeld discovered an instance in 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|AA. Java References#Schoenefeld 04]\].

All Errors reveal information by which an attacker can carry out a denial of service against the system. 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 gain insights into the structure of the underlying file system by repeatedly passing different paths to fictitious files. When a file is not found, 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 a sanitized message when the file is not found. Failure to restrict user input can leave the code vulnerable to a brute force attack that allows the attacker to enumerate valid file names on a system by constantly monitoring the inputs that generate the sanitized message when the corresponding file is not found.

In this noncompliant example, the exception is not sanitized which enables the attacker to also learn the user's home directory and as a result, the 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)

The exception must be caught while taking special care to sanitize the message before propagating it 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, referred to as exception translation). The MyExceptionReporter class described in EXC01-J. Use a class dedicated to reporting exceptions is a good choice, as this compliant solution exemplifies.

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 Throwable is caught instead of catching specific exceptions. This is a departure from commonly suggested best practices, but is critical in cases where runtime exceptions or errors can reveal sensitive information. Moreover, this solution overcomes the issue of the brute force attack described earlier by accepting a denumerable 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.

While following this guideline, make sure that security exceptions such as java.security.AccessControlException and java.lang.SecurityException are not masked in the process. This can lead to far more pernicious effects such as missed security event log entries (see EXC03-J. Use a logging API to log critical security exceptions). The MyExceptionReporter class prescribes a logging method to deal with this condition.

Risk Assessment

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

Automated Detection

TODO

Related Vulnerabilities

CVE-2009-2897

Other Languages

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

References

\[[SCG 2007|AA. Java References#SCG 07]\] Guideline 3-4 Purge sensitive information from exceptions
\[[Gong 2003|AA. Java References#Gong 03]\] 9.1 Security Exceptions
\[[MITRE 2009|AA. Java References#MITRE 09]\] [CWE ID 209|http://cwe.mitre.org/data/definitions/209.html] "Error Message Information Leak", [CWE ID 600|http://cwe.mitre.org/data/definitions/600.html] "Failure to Catch All Exceptions (Missing Catch Block)", [CWE ID 497|http://cwe.mitre.org/data/definitions/497.html] "Information Leak of System Data"

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