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

From OWASP
Jump to: navigation, search
Line 2: Line 2:
  
  
{{FIXUP|Neil Smithline|Replace Final Text Here}}
+
{{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.  
+
 
 +
 
 +
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 information leakage and improper error handling.  
+
All web application frameworks are vulnerable to authentication and session management flaws.  
  
 
== 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:
+
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.
 
+
*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 does not leak information via error messages or other means.
+
The goal is to verify that the application properly authenticates users and properly protects identities and their associated credentials.
  
Automated approaches: Vulnerability scanning tools can and probably will 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. Some of the issues.
+
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.
  
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.
+
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.
  
 
== 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.  
+
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).
  
Preventing information leakage requires discipline. The following practices have proven effective:
+
Preventing authentication flaws takes careful planning. Among the most important considerations are:  
  
*Ensure that the entire software development team shares a common approach to exception handling.
+
*'''Only use the inbuilt session management mechanism.''' Do not write or use secondary session handlers under any circumstances.
*Disable or limit detailed error handling. In particular, do not display debug information to end users, stack traces, or path information.
+
*'''Do not accept new, preset or invalid session identifiers''' from the URL or in the request. This is called a session fixation attack.
*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.
+
*'''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.
*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 these layers are adequately checked and configured to prevent error messages from being exploited by intruders
+
*'''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.
*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.
+
*'''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.
*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.
+
*Consider '''regenerating a new session upon successful authentication''' or privilege level change.
*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.  
+
*'''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.
 +
*'''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-4899 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4899]  
+
*[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-3389 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3389]  
+
*[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-2002-0580 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-0580]  
+
*[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6528 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6528]    
  
 
== References ==
 
== 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.
+
*CWE: CWE-287 (Authentication Issues), CWE-522 (Insufficiently Protected Credentials), CWE-311 (Reflection attack in an authentication protocol), others.
*WASC Threat Classification: http://www.webappsec.org/projects/threat/classes/information_leakage.shtml
+
*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]
*OWASP, [http://www.owasp.org/index.php/Error_Handling http://www.owasp.org/index.php/Error_Handling]  
+
*OWASP, [http://www.owasp.org/index.php/Guide_to_Authentication http://www.owasp.org/index.php/Guide_to_Authentication]
*OWASP, [http://www.owasp.org/index.php/Category:Sensitive_Data_Protection_Vulnerability http://www.owasp.org/index.php/Category:Sensitive_Data_Protection_Vulnerability]  
+
*OWASP, [http://www.owasp.org/index.php/Reviewing_Code_for_Authentication http://www.owasp.org/index.php/Reviewing_Code_for_Authentication]
 +
*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
  
  

Revision as of 18:35, 13 May 2007

«««« Main
()
»»»»


FIXUP: {{{1}}}: {{{2}}}




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

All web application frameworks are vulnerable to authentication and session management flaws.

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.

Verifying Security

The goal is to verify that the application properly authenticates users and properly protects identities and their associated credentials.

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.

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.

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

Preventing authentication flaws takes careful planning. Among the most important considerations are:

  • Only use the inbuilt session management mechanism. Do not write or use secondary session handlers under any circumstances.
  • Do not accept new, preset or invalid session identifiers from the URL or in the request. This is called a session fixation attack.
  • 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.
  • 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.
  • 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.
  • Consider regenerating a new session upon successful authentication or privilege level change.
  • 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.
  • 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

References



«««« Main
()
»»»»

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