Page History

Propagating the contents of exceptions without performing explicit 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 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. It is also possible for the user's home directory and as a result the user name, to get exposed.This noncompliant code example also violates the condition that user supplied input must never occur in file names or as a constituting element of file paths. Failure to restrict user input can leave the

...

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("HOMEAPPDATA") + args[0]);  
  }
}

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 a system defined sanitized message. On the other hand, if the system does not sanitize the exception information, the user's home directory and as a result the user name is also exposed.

Noncompliant Code Example

...

Compliant Solution

To overcome the problemproblems, 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.

Notice how 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 shielded hidden from the user of the application.

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

While following this guideline, make sure that security exceptions such as java.security.AccessControlException and java.lang.SecurityException are not swallowed or 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.

...