Page History

Propagating the contents of exceptions without explicitly filtering Failure to filter sensitive information when propagating exceptions often results in information leaks and lets an attacker build the attack surfacethat can assist an attacker's efforts to develop further exploits. An attacker may craft input parameters such that underlying arguments to expose internal structures and mechanisms of the application are inadvertently exposed. Information leaks can result from both - . Both the exception message text and the type of an exception can leak information. For example, with the FileNotFoundException, the message reveals information about the file system layout while , and the exception type conveys reveals the absence of the requested file.unmigrated-wiki-markup

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 {{rule applies to server-side applications as well as to clients. Attackers can glean sensitive information not only from vulnerable web servers but also from victims who use vulnerable web browsers. In 2004, Schönefeld discovered an exploit for the Opera v7.54 web browser in which 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. Bibliography#Schoenefeld 04]\[Schönefeld 2004].

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

Printing the stack trace can also result in unintentionally leaking information about the structure and state of the process to an attacker. When a Java program that is run within a console terminates because of an uncaught exception, the exception's message and stack trace are displayed on the console; the stack trace may itself contain sensitive information about the program's internal structure. Consequently, any program that may be run on a console accessible to an untrusted user must never abort due to an uncaught exception.

Noncompliant Code Example (Leaks from Exception Message and Type)

This In 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, the program must read a file supplied by the user, but the contents and layout of the file system are sensitive. The program accepts a file name as an input argument but fails 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 
 // 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 nameWhen a requested file is absent, the FileInputStream constructor throws a FileNotFoundException, allowing an attacker to reconstruct the underlying file system by repeatedly passing fictitious path names to the program.

Noncompliant Code Example (

...

Wrapping and Rethrowing Sensitive Exception)

This noncompliant code example logs the exception and re-throws it without performing adequate message sanitization. then wraps it in a more general exception before rethrowing it:

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 when the logged exception is not accessible to the user, the original exception is still informative and can be used by an attacker to discover sensitive information about the file system layout.
Note that this example also violates FIO04-J. Release resources when they are no longer needed, as it fails to close the input stream in a finally block. Subsequent code examples also omit this finally block for brevity.

Noncompliant Code Example (

...

Sanitized Exception)

This noncompliant code example logs the exception and wraps it in an unchecked exception before re-throwing it. throws 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 SecurityIOException();
}

Although this exception is less likely than the previous noncompliant code examples to leak useful information, it still reveals that the specified file cannot be read. More specifically, the program reacts differently to nonexistent file paths than it does to valid ones, and an attacker can still infer sensitive information about the file system 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 by issuing queries that collectively cover the space of possible file names. File names that cause the program to return the sanitized exception indicate nonexistent files, whereas file names that do not return exceptions reveal existing files.

Compliant Solution (Security Policy)

This compliant solution implements the policy that only files that live in c:\homepath may be opened by the user and that the user is not allowed to discover anything about files outside this directory. The solution issues a terse error message when the file cannot be opened or the file does not live in the proper directory. Any information about files outside c:\homepath is concealed.

The compliant solution also uses the File.getCanonicalFile() method to canonicalize the file to simplify subsequent path name comparisons (see FIO16-J. Canonicalize path names before validating them for more information).

class ExceptionExample {
  public static void main(String[] args) {

    File file = null;
    try {
      file = new RuntimeException("Unable to retrieve file", e);
}

Compliant Solution (Forward to Dedicated Handler or Reporter)

 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 permitted by exception ERR08-J-EX2(see ERR08-J. Do not catch NullPointerException or any of its ancestors). It uses the MyExceptionReporter class described in ERR00-J. Do not suppress or ignore checked exceptions, which filters sensitive information from any resulting exceptionsThe 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 guideline 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) {
    tryFileInputStream {
fis = null;
    FileInputStream fis = null;try {
      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 Compliant solutions must ensure 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 guideline EXC03-J. Use a logging API to log critical security exceptions.) The MyExceptionReporter class prescribes a logging method to deal with this condition continue to be logged and sanitized appropriately (see ERR02-J. Prevent exceptions while logging data for additional information). The MyExceptionReporter class from ERR00-J. Do not suppress or ignore checked exceptions demonstrates an acceptable approach for this logging and sanitization.

For scalability, the switch statement should be replaced with some sort of mapping from integers to valid file names or at least an enum type representing valid files.

Risk Assessment

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

Automated Detection

...

Tool	Version	Checker	Description
Parasoft Jtest	Include Page Parasoft_V Parasoft_V	CERT.ERR01.ACPST CERT.ERR01.CETS CERT.ERR01.ACW	Do not call the 'printStackTrace()' method of "Throwable" objects Catch all exceptions which may be thrown within Servlet methods Avoid writing to Consoles
SonarQube	Include Page SonarQube_V SonarQube_V	S1989	Exceptions should not be thrown from servlet methods

Related Vulnerabilities

CVE-2009-2897

Other Languages

...

describes several cross-site scripting (XSS) vulnerabilities in several versions of SpringSource Hyperic HQ. These vulnerabilities allow remote attackers to inject arbitrary web script or HTML via invalid values for numerical parameters. They are demonstrated by an uncaught java.lang.NumberFormatException exception resulting from entering several invalid numeric parameters to the web interface.

CVE-2015-2080 describes a vulnerability in the Jetty web server, versions 9.2.3 to 9.2.8, where an illegal character passed in an HTML request causes the server to respond with an error message containing the text with the illegal character. But this error message can also contain sensitive information, such as cookies from previous web requests.

Related Guidelines

...

...

\[[SCG 2007|AA. Bibliography#SCG 07]\] Guideline 3-4 Purge sensitive information from exceptions
\[[Gong 2003|AA. Bibliography#Gong 03]\] 9.1 Security Exceptions
\[[MITRE 2009|AA. Bibliography#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"

Bibliography

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