This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Top 10 2007-Information Leakage and Improper Error Handling"

From OWASP
Jump to: navigation, search
 
(2 intermediate revisions by 2 users not shown)
Line 32: Line 32:
 
*'''Disable or limit detailed error handling'''. In particular, do not display debug information to end users, stack traces, or path information.
 
*'''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. If this is not possible, consider imposing a random wait time for all transactions to hide this detail from the attacker.
 
*'''Ensure that secure paths that have multiple outcomes return similar or identical error messages''' in roughly the same time. If this is not possible, consider imposing a random wait time for all transactions to hide this detail from the attacker.
*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 allthese layers are adequately checked and configured to prevent error messages from being exploited by intruders'''
+
*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 these 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'''.
 
*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'''.
*OverridingAlthough security through obscurity, choosing to override 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
+
*Overriding - Although security through obscurity, choosing to override 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
+
*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.
  
 
== Samples ==
 
== Samples ==
Line 52: Line 52:
 
**[http://www.webappsec.org/projects/threat/classes/information_leakage.shtml http://www.webappsec.org/projects/threat/classes/information_leakage.shtml]  
 
**[http://www.webappsec.org/projects/threat/classes/information_leakage.shtml http://www.webappsec.org/projects/threat/classes/information_leakage.shtml]  
 
{{Top_10_2007:BottomTemplate|usenext=NextLink|next=-Broken Authentication and Session Management|useprev=PrevLink|prev=-Cross Site Request Forgery|usemain=MainLink|main=}}
 
{{Top_10_2007:BottomTemplate|usenext=NextLink|next=-Broken Authentication and Session Management|useprev=PrevLink|prev=-Cross Site Request Forgery|usemain=MainLink|main=}}
 +
 +
[[Category:OWASP Top Ten Project]]

Latest revision as of 02:44, 19 April 2010

«««« Main
()
»»»»


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.

Environments Affected

All web application frameworks are vulnerable to information leakage and improper error handling.

Vulnerability

Applications frequently generate error messages and display them to users. Many times these error messages are quite useful to attackers, as they reveal implementation details or information that is useful in exploiting a vulnerability. There are several common examples of this:

  • Detailed error handling, where inducing an error displays too much information, such as stack traces, failed SQL statements, or other debugging information
  • Functions that produce different results based upon different inputs. For example, supplying the same username but different passwords to a login function should produce the same text for no such user, and bad password. However, many systems produce different error codes

Verifying Security

The goal is to verify that the application does not leak information via error messages or other means.

Automated approaches: Vulnerability scanning tools will usually cause error messages to be generated. Static analysis tools can search for the use of APIs that leak information, but will not be able to verify the meaning of those messages.

Manual approaches: A code review can search for improper error handling and other patterns that leak information, but it is time-consuming. Testing will also generate error messages, but knowing what error paths were covered is a challenge.

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 attackers.

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. If this is not possible, consider imposing a random wait time for all transactions to hide this detail from the attacker.
  • 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 these 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 - Although security through obscurity, choosing to override 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.

Samples

Related Articles

References

«««« Main
()
»»»»

© 2002-2007 OWASP Foundation This document is licensed under the Creative Commons Attribution-ShareAlike 2.5 license. Some rights reserved.