Page History

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 arguments to expose 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 the message of a FileNotFoundException reveals information regarding about 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 innocentvictims 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|AA. Bibliography#Schoenefeld 04]\].

All errors exceptions 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 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. If a Java program is run within a console, and it terminates due to because of an uncaught exception, the exception's message and stack trace are displayed on the console; the stack trace may itself indicate leak sensitive information about the program's internal structure. Therefore Consequently, command-line programs must never abort due to because of an uncaught exception.

Noncompliant Code Example (Leaks from Exception Message and Type)

Consider a In this noncompliant code example, the program that must read a file supplied by the user , but the contents and layout of the filesystem might be considered file system are sensitive. This noncompliant code example The program accepts a file name as an input argument , while doing nothing 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 
    // $HOME, Windows in %APPDATA%
    FileInputStream fis = new FileInputStream(System.getenv("APPDATA") + args[0]);  
  }
}

An 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 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)

...

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 discover sensitive information about the filesystem file system layout.

Noncompliant Code Example (Sanitized Exception)

...

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

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

While this exception is more cryptic to info disclosure less likely to leak useful information than previous noncompliant code examples, it still reveals that the specified file being specified cannot be read. More specifically, the program reacts differently to nonexistant nonexistent file paths than it does to valid ones, and an attacker can still infer sensitive information about the filesystem 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 via with repeated queries that collectively cover the space of possible filenamesfile names; 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 implements the policy that only files that live in c:\homepath may be opened by the user, and that the user must is not learn allowed to discover anything about files outside this directory. So it The solution 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 path name comparison cannot be foiled by spurious instances of "\.", or symbolic links, or capitalization.

...