Information Exposure Through an Error Message
|ID: 209||Date: (C)2012-05-14 (M)2020-02-19|
|Type: weakness||Status: DRAFT|
|Abstraction Type: Base|
The software generates an error message that includes sensitive
information about its environment, users, or associated
Extended DescriptionThe 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
Likelihood of Exploit: High
Applicable PlatformsLanguage: OftenLanguage: PHPLanguage Class: All
Time Of Introduction
- Architecture and Design
- System Configuration
Related Attack Patterns
|Confidentiality ||Read application
data ||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. ||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. ||Moderate || |
|Automated Dynamic Analysis ||This weakness can be detected using dynamic tools and techniques that
interact with the software using large test suites with many diverse
inputs, such as fuzz testing (fuzzing), robustness testing, and fault
injection. The software's operation may slow down, but it should not
become unstable, crash, or generate incorrect results.Error conditions may be triggered with a stress-test by calling the
software simultaneously from a large number of threads or processes, and
look for evidence of any unexpected behavior. ||Moderate || |
|Manual Dynamic Analysis ||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. || || |
|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 be used to refine the
original attack to increase the chances of success.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. || || |
|Implementation || ||Handle exceptions internally and do not display errors containing
potentially sensitive information to a user. || || |
|Implementation ||Identify and Reduce Attack Surface ||Use naming conventions and strong types to make it easier to spot when
sensitive data is being used. When creating structures, objects, or
other complex entities, separate the sensitive and non-sensitive data as
much as possible. ||Defense in Depth ||This makes it easier to spot places in the code where data is being
used that is unencrypted. |
|ImplementationBuild and Compilation ||Compilation or Build HardeningEnvironment Hardening ||Debugging information should not make its way into a production
release. || || |
|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. || || |
|System Configuration || ||Create default error pages or messages that do not leak any
information. || || |
|CWE-209 ChildOf CWE-895 ||Category ||CWE-888 || |
Demonstrative Examples (Details)
- In the example below, the method getUserBankAccount retrieves a bank
account object from a database using the supplied username and account
number to query the database. If an SQLException is raised when querying the
database, an error message is created and output to a log file.
- In the following example, sensitive information might be printed
depending on the exception that occurs.
- The following code generates an error message that leaks the full
pathname of the configuration file.
- This code tries to open a database connection, and prints any
exceptions that occur.
- 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.
- CVE-2005-0603 : Malformed regexp syntax leads to information exposure in error message.
For more examples, refer to CVE relations in the bottom box.
White Box Definitions None
Black Box Definitions None
|CLASP || ||Accidental leaking of sensitive information through error
messages || |
|OWASP Top Ten 2007 ||A6 ||Information Leakage and Improper Error
Handling ||CWE_More_Specific |
|OWASP Top Ten 2004 ||A7 ||Improper Error Handling ||CWE_More_Specific |
|OWASP Top Ten 2004 ||A10 ||Insecure Configuration Management ||CWE_More_Specific |
|CERT Java Secure Coding ||ERR01-J ||Do not allow exceptions to expose sensitive
information || |
|CERT C++ Secure Coding ||ERR12-CPP ||Do not allow exceptions to transmit sensitive
information || |
- Web Application Security Consortium .Information Leakage.
- Brian Chess Jacob West .Secure Programming with Static Analysis. Addison-Wesley. Section:'Section 9.2, page 326.'. Published on 2007.
- M. Howard D. LeBlanc .Writing Secure Code 1st Edition. Microsoft. Section:'Chapter 16, "General Good Practices." Page
415'. Published on 2002.
- Michael Howard David LeBlanc John Viega .24 Deadly Sins of Software Security. McGraw-Hill. Section:'"Sin 11: Failure to Handle Errors Correctly." Page
183'. Published on 2010.
- Michael Howard David LeBlanc John Viega .24 Deadly Sins of Software Security. McGraw-Hill. Section:'"Sin 12: Information Leakage." Page 191'. Published on 2010.
- Johannes Ullrich .Top 25 Series - Rank 16 - Information Exposure Through an Error
Message. SANS Software Security Institute. 2010-03-17.
- Mark Dowd John McDonald Justin Schuh .The Art of Software Security Assessment 1st Edition. Addison Wesley. Section:'Chapter 3, "Overly Verbose Error Messages", Page
75.'. Published on 2006.