Information Exposure Through an Error Message |
Weakness ID: 209 (Weakness Base) | Status: Draft |
Description Summary
Extended Description
The sensitive information may be valuable information on its own (such as a password), or it may be useful for launching other, more deadly attacks. If an attack fails, an attacker may use error information provided by the server to launch another more focused attack. For example, an attempt to exploit a path traversal weakness (CWE-22) might yield the full pathname of the installed application. In turn, this could be used to select the proper number of ".." sequences to navigate to the targeted file. An attack using SQL injection (CWE-89) might not initially succeed, but an error message could reveal the malformed query, which would expose query logic and possibly even passwords or other sensitive information used within the query.
Scope | Effect |
---|---|
Confidentiality | Often this will either reveal sensitive information which may be used for a later attack or private information stored in the server. |
Manual Analysis This weakness generally requires domain-specific interpretation using manual analysis. However, the number of potential error conditions may be too large to cover completely within limited time constraints. Effectiveness: High |
Automated Analysis Automated methods may be able to detect certain idioms automatically, such as exposed stack traces or pathnames, but violation of business rules or privacy requirements is not typically feasible. Effectiveness: Moderate |
Example 1
In the following example, sensitive information might be printed depending on the exception that occurs.
If an exception related to SQL is handled by the catch, then the output might contain sensitive information such as SQL query structure or private information. If this output is redirected to a web user, this may represent a security problem.
Example 2
The following code generates an error message that leaks the full pathname of the configuration file.
If this code is running on a server, such as a web application, then the person making the request should not know what the full pathname of the configuration directory is. By submitting a username that does not produce a $file that exists, an attacker could get this pathname. It could then be used to exploit path traversal or symbolic link following problems that may exist elsewhere in the application.
Reference | Description |
---|---|
CVE-2008-2049 | POP3 server reveals a password in an error message after multiple APOP commands are sent. Might be resultant from another weakness. |
CVE-2007-5172 | Program reveals password in error message if attacker can trigger certain database errors. |
CVE-2008-4638 | Composite: application running with high privileges allows user to specify a restricted file to process, which generates a parsing error that leaks the contents of the file. |
CVE-2008-1579 | Existence of user names can be determined by requesting a nonexistent blog and reading the error message. |
CVE-2007-1409 | Direct request to library file in web application triggers pathname leak in error message. |
CVE-2008-3060 | Malformed input to login page causes leak of full path when IMAP call fails. |
Phase: Implementation Ensure that error messages only contain minimal details that are useful to the intended audience, and nobody else. The messages need to strike the balance between being too cryptic and not being cryptic enough. They should not necessarily reveal the methods that were used to determine the error. Such detailed information can help an attacker craft another attack that now will pass through the validation filters. If errors must be tracked in some detail, capture them in log messages - but consider what could occur if the log messages can be viewed by attackers. Avoid recording highly sensitive information such as passwords in any form. Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a username is valid or not. |
Phase: Implementation Handle exceptions internally and do not display errors containing potentially sensitive information to a user. |
Phase: Build and Compilation Debugging information should not make its way into a production release. |
Phase: Testing Identify error conditions that are not likely to occur during normal usage and trigger them. For example, run the program under low memory conditions, run with insufficient privileges or permissions, interrupt a transaction before it is completed, or disable connectivity to basic network services such as DNS. Monitor the software for any unexpected behavior. If you trigger an unhandled exception or similar error that was discovered and handled by the application's environment, it may still indicate unexpected conditions that were not handled by the application itself. |
Phase: Testing Stress-test the software by calling it simultaneously from a large number of threads or processes, and look for evidence of any unexpected behavior. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results. |
Phase: System Configuration Where available, configure the environment to use less verbose error messages. For example, in PHP, disable the display_errors setting during configuration, or at runtime using the error_reporting() function. |
Phase: System Configuration Create default error pages or messages that do not leak any information. |
Nature | Type | ID | Name | View(s) this relationship pertains to |
---|---|---|---|---|
ChildOf | Weakness Class | 200 | Information Exposure | Development Concepts (primary)699 Research Concepts (primary)1000 |
ChildOf | Category | 717 | OWASP Top Ten 2007 Category A6 - Information Leakage and Improper Error Handling | Weaknesses in OWASP Top Ten (2007) (primary)629 |
ChildOf | Category | 728 | OWASP Top Ten 2004 Category A7 - Improper Error Handling | Weaknesses in OWASP Top Ten (2004) (primary)711 |
ChildOf | Category | 731 | OWASP Top Ten 2004 Category A10 - Insecure Configuration Management | Weaknesses in OWASP Top Ten (2004)711 |
ChildOf | Category | 751 | 2009 Top 25 - Insecure Interaction Between Components | Weaknesses in the 2009 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)750 |
ChildOf | Weakness Class | 755 | Improper Handling of Exceptional Conditions | Research Concepts1000 |
ChildOf | Category | 801 | 2010 Top 25 - Insecure Interaction Between Components | Weaknesses in the 2010 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)800 |
ParentOf | Weakness Base | 210 | Product-Generated Error Message Information Leak | Development Concepts (primary)699 Research Concepts (primary)1000 |
ParentOf | Weakness Base | 211 | Product-External Error Message Information Leak | Development Concepts (primary)699 Research Concepts (primary)1000 |
CanFollow | Weakness Base | 600 | Failure to Catch All Exceptions in Servlet | Research Concepts1000 |
CanFollow | Weakness Class | 756 | Missing Custom Error Page | Research Concepts1000 |
CanAlsoBe | Weakness Variant | 81 | Improper Sanitization of Script in an Error Message Web Page | Research Concepts1000 |
CanAlsoBe | Weakness Variant | 201 | Information Leak Through Sent Data | Research Concepts1000 |
Mapped Taxonomy Name | Node ID | Fit | Mapped Node Name |
---|---|---|---|
CLASP | Accidental leaking of sensitive information through error messages | ||
OWASP Top Ten 2007 | A6 | CWE More Specific | Information Leakage and Improper Error Handling |
OWASP Top Ten 2004 | A7 | CWE More Specific | Improper Error Handling |
OWASP Top Ten 2004 | A10 | CWE More Specific | Insecure Configuration Management |
Web Application Security Consortium. "Information Leakage". <http://www.webappsec.org/projects/threat/classes/information_leakage.shtml>. |
Brian Chess and Jacob West. "Secure Programming with Static Analysis". Section 9.2, page 326.. Addison-Wesley. 2007. |
M. Howard and D. LeBlanc. "Writing Secure Code". Chapter 16, "General Good Practices." Page 415. 1st Edition. Microsoft. 2002. |
[REF-17] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 11: Failure to Handle Errors Correctly." Page 185. McGraw-Hill. 2010. |
[REF-17] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 12: Information Leakage." Page 194. McGraw-Hill. 2010. |
Submissions | ||||
---|---|---|---|---|
Submission Date | Submitter | Organization | Source | |
CLASP | Externally Mined | |||
Modifications | ||||
Modification Date | Modifier | Organization | Source | |
2008-07-01 | Eric Dalci | Cigital | External | |
updated Time of Introduction | ||||
2008-08-15 | Veracode | External | ||
Suggested OWASP Top Ten 2004 mapping | ||||
2008-09-08 | CWE Content Team | MITRE | Internal | |
updated Applicable Platforms, Common Consequences, Relationships, Other Notes, Taxonomy Mappings | ||||
2008-10-14 | CWE Content Team | MITRE | Internal | |
updated Relationships | ||||
2009-01-12 | CWE Content Team | MITRE | Internal | |
updated Demonstrative Examples, Description, Name, Observed Examples, Other Notes, Potential Mitigations, Relationships, Time of Introduction | ||||
2009-03-10 | CWE Content Team | MITRE | Internal | |
updated Demonstrative Examples, Potential Mitigations, Relationships | ||||
2009-12-28 | CWE Content Team | MITRE | Internal | |
updated Demonstrative Examples, Name, Potential Mitigations, References, Time of Introduction | ||||
Previous Entry Names | ||||
Change Date | Previous Entry Name | |||
2009-01-12 | Error Message Information Leaks | |||
2009-12-28 | Error Message Information Leak | |||