Information Leakage and Improper Error Handling

Definition:

Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems. Applications can also leak internal state via how long they take to process certain operations or via different responses to differing inputs, such as displaying the same error text with different error numbers. Web applications will often leak information about their internal state through detailed or debug error messages. Often, this information can be leveraged to launch or even automate more powerful attacks.

Error conditions that occur during normal operation are not handled properly. If an attacker can cause errors to occur that the web application does not handle, they can gain detailed system information, deny service, cause security mechanisms to fail, or crash the server.

Protection:

Developers should use tools like OWASP's WebScarab to try to make their application generate errors. Applications that have not been tested in this way will almost certainly generate unexpected error output.

Applications should also include a standard exception handling architecture to prevent unwanted information from leaking to attacker.

Preventing information leakage requires discipline. The following practices have proven effective:

• Ensure that the entire software development team shares a common approach to exception handling.

• Disable or limit detailed error handling. In particular, do not display debug information to end users, stack traces, or path information.

• Ensure that secure paths that have multiple outcomes return similar or identical error messages in roughly the same time.

• Various layers may return fatal or exceptional results, such as the database layer, the underlying web server (IIS, Apache, etc). It is vital that errors from all layers are adequately checked and configured to prevent error messages from being exploited by intruders.

• Be aware that common frameworks return different HTTP error codes depending on if the error is within your custom code or within the framework’s code. It is worthwhile creating a default error handler which returns an appropriately sanitized error message for most users in production for all error paths.

• Overriding the default error handler so that it always returns “200” (OK) error screens reduces the ability of automated scanning tools from determining if a serious error occurred. While this is “security through obscurity,” it can provide an extra layer of defense.

• Some larger organizations have chosen to include random / unique error codes amongst all their applications. This can assist the help desk with finding the correct solution for a particular error, but it may also allow attackers to determine exactly which path an application failed.

• Always give the error message that “The username/password is not correct” instead of “The password is not correct” for failed logins.

.Net Overview:
On .Net we set the web.config’s customErrors mode attirubute to RemoteOnly and redirect to an custom error page for all errors. We do not show any custom error message. Becuse we know it is a clue for the attacker.

configuration>
customErrors mode="RemoteOnly" defaultRedirect="GenericErrorPage.htm">
error statusCode="403" redirect="NoAccess.htm" />
error statusCode="404" redirect="FileNotFound.htm" />
/customErrors>
/configuration>

We catch the application error and inform ourself via logging exeption message but we never inform users. We give general exception message like “Sorry we have a problem. We are going to fix this as soon as possible…”

protected void Application_Error(Object sender, EventArgs e)
{
HttpContext ctx = HttpContext.Current;
Exception ex = ctx.Server.GetLastError().InnerException;

// ex.Message to inform yourself not users or attackers…
}