Failure to filter sensitive information when propagating exceptions often results in information leaks that can assist an attacker's efforts to expand the attack surfacedevelop further exploits. An attacker may craft input arguments to expose internal structures and mechanisms of the application. Both the exception message text and the type of an exception can leak information. For example, the message of a FileNotFoundException
reveals information about the file system layout, and the exception type reveals the absence of the requested file.
Wiki Markup |
---|
This 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, SchoenefeldSchönefeld 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}}" \[[SchoenefeldSchönefeld 2004|AA. Bibliography#Schoenefeld 04]\]. |
All exceptions reveal information that can assist an attacker'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 several problematic exceptions:
Exception Name | Description of information leak or threat |
---|---|
| Underlying file system structure, user name enumeration |
| Database structure, user name enumeration |
| Enumeration of open ports when untrusted client can choose server port |
| May provide information about thread-unsafe code |
| Insufficient server resources (may aid DoS) |
| Resource enumeration |
| Underlying file system structure |
| Owner enumeration |
| Denial of service ( DoS) |
| Denial of service ( DoS) |
Printing the stack trace can also result in unintentionally leaking information about the structure and state of the process to an attacker. If When a Java program that is run within a console , and it terminates because of an uncaught exception, the exception's message and stack trace are displayed on the console; the stack trace may itself leak sensitive information about the program's internal structure. Consequently, command-line programs must never abort because of an uncaught exception.
...
In this noncompliant code example, the program that 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.
Code Block | ||
---|---|---|
| ||
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]); } } |
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.
...
This noncompliant code example logs the exception and then wraps it in a more general exception before re-throwing rethrowing it.
Code Block | ||
---|---|---|
| ||
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 if 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 rule FIO04-J, as it does not close the input stream in a finally
block. Subsequent code examples also omit this finally
block for brevity.
Noncompliant Code Example (Sanitized Exception)
...
Code Block | ||
---|---|---|
| ||
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 less likely to leak useful information 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, file names that don't, do not reveal existing files.
Compliant Solution (Canonicalization)
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 if the file cannot be opened , or the file does not live in the proper directory. This serves to conceal any Any information about files outside c::\homepath
is concealed.
The compliant solution also uses the File.getCanonicalFile()
method to canonicalize the file, so that the subsequent path name comparison cannot be foiled by spurious instances of " \. ", or by symbolic links , or capitalization.
Code Block | ||
---|---|---|
| ||
class ExceptionExample { public static void main(String[] args) { File file = null; try { file = new 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; } } } |
...
It also catches Throwable
, as warranted permitted by EX0 of exception ERR08-J. Do not catch NullPointerException or any of its ancestors, . It also uses the MyExceptionReporter
class described in rule ERR00-J. Do not suppress or ignore checked exceptions, which handles responsibility for filtering filters sensitive information from any resulting exceptions.
Code Block | ||
---|---|---|
| ||
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 } } } |
Compliant solutions must ensure that security exceptions such as java.security.AccessControlException
and java.lang.SecurityException
continue to be logged and sanitized appropriately. See rule ERR02-J. Prevent exceptions while logging data for additional information. The MyExceptionReporter
class from rule ERR00-J. Do not suppress or ignore checked exceptions demonstrates an acceptable approach for this logging and sanitization.
For scalablityscalability, 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.
...
Related Vulnerabilities
CVE-2009-2897 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.
Related Guidelines
C++ Secure Coding Standard | ERR12-CPP. Do not allow exceptions to transmit sensitive information. |
CWE-209, "Information Exposure Through an Error Message" . Information exposure through an error message | |
| CWE-600, ". Uncaught Exception exception in Servlet" servlet |
| CWE-497, ". Exposure of System Data system data to an Unauthorized Control Sphere" unauthorized control sphere |
Bibliography
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="70ac28ededb15590-0b286a69-4d1145a4-a450ac71-2e8b0d00d6420093a8044edd"><ac:plain-text-body><![CDATA[ | [[Gong 2003 | AA. Bibliography#Gong 03]] | 9.1, Security Exceptions | ]]></ac:plain-text-body></ac:structured-macro> |
...