CWE 209: Information Exposure Through an Error Message

Flaw

CWE 209: Information Exposure Through an Error Message is a security weakness where an application or system reveals sensitive information to end users (and therefore, to attackers) in error messages. This information could pose a direct risk (it is sensitive information) or an indirect risk (it can help an attacker conduct their attacks).

Examples of direct risk of exposure include exposing:

• user credentials (passwords, tokens, other secrets)
• private user information

Examples of indirect risk of exposure include exposing:

• database error messages -- this can make SQL Injection significantly easier
• application environment/configuration -- this allows attackers to easily find configuration errors they may be able to exploit
• software version information -- this allows attackers to easily find unpatched software they can exploit

In the following example, a warning message is shown to external users of a public-facing site.

warningDialogBox = this.myWidgetFactoryWrapper.createHtmlDialogBox()
warningDialogBox.setText("WARNING: Could not connect to app server at " + serverAddress)

This warning benefits internal troubleshooters, but provides no benefit to a typical end user. Internal IP addresses are valuable information to a malicious user gathering information on this site and its environment before attempting an attack. Based on the information in this error message, an attacker may focus on that server, and proceed to scan for weaknesses there. Further vulnerabilities could facilitate wider compromise.

In the next example, another method displays information in the event of an exception.

public static void insufficientFundsException() throws Throwable {

      Throwable t = new Throwable("Error: Insufficient funds in your account.");
      StackTraceElement[] myStackTrace = new StackTraceElement[] {
         new StackTraceElement("class","method","filename",90)
      };
      t.setStackTrace(myStackTrace);
      throw t;
    }

The application throws this exception if a user tries to purchase something, but lacks funds in their account. To communicate this, a dialog box would suffice. Instead, the application displays an entire stack trace. As in the previous example, this output contains abundant information for an attacker. Perhaps this stack trace was left in code during QA; regardless, once in production, it poses a risk.

Fix

In general, fixing Information Leakage flaws means removing the offending information from user-facing output.

To do this, you could amend the first example like this:

warningDialogBox = this.myWidgetFactoryWrapper.createHtmlDialogBox()
LOGGER.warning("WARNING: Could not connect to app server at " + serverAddress)
warningDialogBox.setText("Unable to connect to application server, please contact support.")

warningDialogBox = this.myWidgetFactoryWrapper.createHtmlDialogBox()
-warningDialogBox.setText("WARNING: Could not connect to app server at " + serverAddress)
+LOGGER.warning("WARNING: Could not connect to app server at " + serverAddress)
+warningDialogBox.setText("Unable to connect to application server, please contact support.")

The amount of information that the user sees has been adjusted to reflect what they need to know. You should consider which types of users need access to what data, and to account for all data that is shared with them. Any other information should be removed.

The details, which can be useful for troubleshooting, are instead preserved in the application log.

Here are some additional steps to take to minimize the risk of information leakage:

• During the testing phase, regularly force the application to generate errors. Applications that have not been tested in this way will almost certainly write unexpected error output, which could contain unwanted information.
• Set up a standard exception handling system and default error messages, so that unexpected errors do not disclose sensitive information. In production, detailed error handling should be disabled or limited for end users. There’s usually no reason to show them things like debug information, stack traces, or path information.
• Because errors can originate from layers beyond the application layer, such as the database or web server, make sure not to overlook the messages they produce.

References

CWE ↪ WASC ↪