Page History

...

This noncompliant code example accepts a file name as an input argument. An attacker can gain insights into learn about the structure of the underlying file system by repeatedly passing different constructed paths to fictitious files. When a requested file is not foundabsent, the FileInputStream constructor throws a FileNotFoundException.

...

This attack is possible even when the application displays only a sanitized message when the file is not foundabsent. Failure to restrict user input leaves the system vulnerable to a brute force attack in which the attacker enumerates discovers valid file names by constantly monitoring the specific inputs that generate via repeated queries that collectively cover the space of possible filenames; queries that result in the sanitized message because exclude the corresponding file was not foundrequested 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.

...

This compliant solution catches and sanitizes the exception and its message before propagating it 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, referred to as ; this is exception translation). The One good solution is to use the MyExceptionReporter class described in guideline EXC01-J. Use a class dedicated to reporting exceptions is a good choice, as shown in 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 this example catches Throwable rather than a more specific exception. This departure from commonly suggested best practices , but is critical in cases where runtime exceptions or errors can reveal sensitive information. Moreover, this This solution overcomes the issue of the potential brute force attack described earlier by accepting a denumerable 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.

While following this guideline, make sure 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. ( continue to be logged and sanitized appropriately. See guideline EXC03-J. Use a logging API to log critical security exceptions for additional information. ) The MyExceptionReporter class prescribes a logging method to deal with this conditionfrom guideline EXC01-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.

Automated Detection

TODO

Related Vulnerabilities

CVE-2009-2897

...

Bibliography

\[[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"
\[[SCG 2007|AA. Bibliography#SCG 07]\] Guideline 3-4 Purge sensitive information from exceptions

...

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