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

From OWASP
Jump to: navigation, search
 
(4 intermediate revisions by 3 users not shown)
Line 2: Line 2:
  
  
{{FIXUP|Neil Smithline|Replace With Final Text Here}}
+
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.
 
+
 
+
 
+
 
+
Proper authentication and session management is critical to web application security. Flaws in this area most frequently involve the failure to protect credentials and session tokens through their lifecycle. These flaws can lead to the hijacking of user or administrative accounts, undermine authorization and accountability controls, and cause privacy violations.
+
  
 
== Environments Affected ==
 
== Environments Affected ==
  
All web application frameworks are vulnerable to authentication and session management flaws.  
+
All web application frameworks are vulnerable to information leakage and improper error handling.  
  
 
== Vulnerability ==
 
== Vulnerability ==
  
Flaws in the main authentication mechanism are not uncommon, but weaknesses are more often introduced through ancillary authentication functions such as logout, password management, timeout, remember me, secret question, and account update.
+
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 properly authenticates users and properly protects identities and their associated credentials.
+
The goal is to verify that the application does not leak information via error messages or other means.
  
Automated approaches: Vulnerability scanning tools have a very difficult time detecting vulnerabilities in custom authentication and session management schemes. Static analysis tools are also not likely to detect authentication and session management problems in custom code.
+
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: Code review and testing, especially in combination, are quite effective at verifying that the authentication, session management, and ancillary functions are all implemented properly.
+
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 ==
  
Authentication relies on secure communication and credential storage. First ensure that SSL is the only option for all authenticated parts of the application (see A9 – Insecure Communications) and that all credentials are stored in hashed or encrypted form (see A8 – Insecure Cryptographic Storage).
+
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 authentication flaws takes careful planning. Among the most important considerations are:  
+
Preventing information leakage requires discipline. The following practices have proven effective:
  
*'''Only use the inbuilt session management mechanism.''' Do not write or use secondary session handlers under any circumstances.
+
*'''Ensure that the entire software development team shares a''' '''common approach to exception handling'''.
*'''Do not accept new, preset or invalid session identifiers''' from the URL or in the request. This is called a session fixation attack.
+
*'''Disable or limit detailed error handling'''. In particular, do not display debug information to end users, stack traces, or path information.
*'''Limit or rid your code of custom cookies for authentication or session management '''purposes, such as "remember me" type functionality or home grown single-sign on functionality. This does not apply to robust, well proven SSO or federated authentication solutions.
+
*'''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.
*'''Use a single authentication mechanism''' with appropriate strength and number of factors. Make sure that this mechanism is not easily subjected to spoofing or replay attacks. Do not make this mechanism overly complex, which then may become subject to its own attack.
+
*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'''.
*'''Do not allow the login process to start from an unencrypted page.''' Always start the login process from a second, encrypted page with a fresh or new session token to prevent credential or session stealing, phishing attacks and session fixation attacks.
+
*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'''.
*Consider '''regenerating a new session upon successful authentication''' or privilege level change.
+
*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.
*'''Ensure that every page has a logout link.''' Logout should destroy all server side session state and client side cookies. Consider human factors: do not ask for confirmation as users will end up just closing the tab or window rather than logging out successfully.
+
*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.
*'''Use a timeout period''' that automatically logs out an inactive session as per the value of the data being protected (shorter is always better).
+
*'''Use only strong ancillary authentication functions''' (questions and answers, password reset) as these are credentials in the same way usernames and passwords or tokens are credentials. One way hash answers to prevent disclosure attacks.
+
*'''Do not expose any session identifiers''' or any portion of valid credentials in URLs or logs (no session rewriting or storing the user's password in log files).
+
*'''Do not rely upon spoofable credentials as the sole form of authentication,''' such as IP addresses or address range masks, DNS  or reverse DNS lookups, referrer headers or similar.
+
*'''Be careful of sending secrets to registered e-mail addresses''' (see RSNAKE01 in the references) as a mechanism for password resets. Use limited time only random numbers to reset access and send a follow up e-mail as soon as the password has been reset. Be careful of allowing self-registered users changing their e-mail address - send a message to the previous e-mail address before enacting the change.
+
  
== Samples ==
+
== Samples ==
  
*[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6145 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6145]  
+
*[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-6229 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6229]    
+
*[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-2006-6528 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6528]    
+
*[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-0580 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-0580]  
  
 +
== Related Articles ==
 +
* [[Error Handling]]
 +
* [[:Category:Sensitive Data Protection Vulnerability]]
 
== References ==
 
== References ==
  
*CWE: CWE-287 (Authentication Issues), CWE-522 (Insufficiently Protected Credentials), CWE-311 (Reflection attack in an authentication protocol), others.
+
*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/insufficient_authentication.shtml http://www.webappsec.org/projects/threat/classes/insufficient_authentication.shtml] [http://www.webappsec.org/projects/threat/classes/credential_session_prediction.shtml http://www.webappsec.org/projects/threat/classes/credential_session_prediction.shtml] [http://www.webappsec.org/projects/threat/classes/session_fixation.shtml http://www.webappsec.org/projects/threat/classes/session_fixation.shtml]
+
*WASC Threat Classification:  
*OWASP, [http://www.owasp.org/index.php/Guide_to_Authentication http://www.owasp.org/index.php/Guide_to_Authentication]
+
**[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/Reviewing_Code_for_Authentication http://www.owasp.org/index.php/Reviewing_Code_for_Authentication]
+
{{Top_10_2007:BottomTemplate|usenext=NextLink|next=-Broken Authentication and Session Management|useprev=PrevLink|prev=-Cross Site Request Forgery|usemain=MainLink|main=}}
*OWASP, [http://www.owasp.org/index.php/Testing_for_authentication http://www.owasp.org/index.php/Testing_for_authentication]
+
*RSnake01 - http://ha.ckers.org/blog/20070122/ip-trust-relationships-xss-and-you
+
  
 
+
[[Category:OWASP Top Ten Project]]
 
+
 
+
{{Top_10_2007:BottomTemplate|usenext=NextLink|next=-Broken Authentication and Session Management|useprev=PrevLink|prev=-Cross Site Request Forgery|usemain=MainLink|main=}}
+

Latest revision as of 21:44, 18 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.

Contents

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.