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 be a direct risk if it is sensitive information or an indirect risk if 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 -- makes SQL Injection significantly easier
• Application environment/configuration -- allows attackers to easily find configuration errors they may be able to exploit
• Software version information -- allows attackers to easily find unpatched software they can exploit

In the following example, the details of a System.Exception display to external users of a public-facing site by writing directly to the output.

public class OrderController : Controller
{
    ...
    [HttpPost]
    [ValidateAntiForgeryToken]
    public ActionResult ProcessOrder(ProcessOrderViewModel orderData)
    {
        if (ModelState.IsValid)
        {
            try
            {
                if (!ProcessOrderData(orderData))
                {
                    ModelState.AddModelError("Order", "Unable to process the order");
                }
            }
            catch (Exception ex)
            {
                Response.Write(ex.ToString());
            }
        }

        return View();
    }
    ...
}

The warning is helpful to internal troubleshooters, but provides no benefit to a typical end-user. A full stack trace contains valuable information to a malicious user gathering information on this site and its environment before attempting an attack. Based on the information in this System.Exception message, an attacker may focus on that server and proceed to scan for weaknesses there. Further vulnerabilities could facilitate wider compromise. This stack trace may have been left in the code during QA. However, when is present in production, the stack trace presents a risk.

Fix

In general, fixing Information Leakage flaws involves removing the offending information from user-facing output. The information is valuable for further trouble-shooting, so it is important to store this information in the application log.

To do this, you could amend the first example as follows:

public class OrderController : Controller
{
    ...
    [HttpPost]
    [ValidateAntiForgeryToken]
    public ActionResult ProcessOrder(ProcessOrderViewModel orderData)
    {
        if (ModelState.IsValid)
        {
            try
            {
                if (!ProcessOrderData(orderData))
                {
                    ModelState.AddModelError("Order", "Unable to process the order");
                }
            }
            catch (Exception ex)
            {
                LogError(ex);
                ModelState.AddModelError("Order", "Unable to process the order");
            }
        }

        return View();
    }
    ...
}

}
             catch (Exception ex)
             {
-                Response.Write(ex.ToString());
+                LogError(ex);
+                ModelState.AddModelError("Order", "Unable to process the order");
             }
         }

The amount of information that the user sees is adjusted to reflect only what they need to know. You should consider which types of users need access to what data, to account for all data shared with them. You should remove any other information.

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 you not have tested in this way almost certainly write unexpected error output, which could contain unwanted information.
• Make sure to use a standard exception handling system and default create error messages, so that unexpected errors do not disclose sensitive information. In production, you should disable or limit detailed error handling for end users. There usually is no reason to show details such as debug information, stack traces, or path information.
• Because errors can originate from layers beyond the application layer, such as the database or web server, be sure to overlook the messages they produce.

References

CWE ↪ WASC ↪