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
| Line 2: | Line 2: | ||
| − | + | 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 == | == Environments Affected == | ||
| − | All web application frameworks are vulnerable to | + | All web application frameworks are vulnerable to information leakage and improper error handling. |
== Vulnerability == | == 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 == | == Verifying Security == | ||
| − | The goal is to verify that the application | + | The goal is to verify that the application does not leak information via error messages or other means. |
| − | Automated approaches: Vulnerability scanning tools | + | 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: | + | 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 == | == 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 | + | 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 allthese 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'''. |
| − | + | *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 | |
| − | * | + | *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 == |
| − | *[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006- | + | *[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4899 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4899] |
| − | *[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006- | + | *[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3389 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3389] |
| − | *[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE- | + | *[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-0580 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-0580] |
== References == | == References == | ||
| − | *CWE: CWE- | + | *CWE: CWE-200 (Information Leak), CWE-203 (Discrepancy Information Leak), CWE-215 (Information Leak Through Debug Information), CWE-209 (Error Message Information Leak), others. |
| − | *WASC Threat Classification: [http://www.webappsec.org/projects/threat/classes/ | + | *WASC Threat Classification: |
| − | *OWASP, [http://www.owasp.org/index.php/ | + | **[http://www.webappsec.org/projects/threat/classes/information_leakage.shtml http://www.webappsec.org/projects/threat/classes/information_leakage.shtml] |
| − | *OWASP, [http://www.owasp.org/index.php/ | + | *OWASP, [http://www.owasp.org/index.php/Error_Handling http://www.owasp.org/index.php/Error_Handling] |
| − | + | *OWASP, [http://www.owasp.org/index.php/Category:Sensitive_Data_Protection_Vulnerability http://www.owasp.org/index.php/Category:Sensitive_Data_Protection_Vulnerability] | |
| − | |||
| − | |||
| − | |||
| − | |||
{{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=}} | ||
Revision as of 04:01, 15 May 2007
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 allthese 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.
- 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
- 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
- http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4899
- http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3389
- http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-0580
References
- CWE: CWE-200 (Information Leak), CWE-203 (Discrepancy Information Leak), CWE-215 (Information Leak Through Debug Information), CWE-209 (Error Message Information Leak), others.
- WASC Threat Classification:
- OWASP, http://www.owasp.org/index.php/Error_Handling
- OWASP, http://www.owasp.org/index.php/Category:Sensitive_Data_Protection_Vulnerability
