CWE-209: Information Exposure Through an Error Message
Information Exposure Through an Error Message
Weakness ID: 209 (Weakness Base)
Status: Draft
Description
Description Summary
The software generates an error message that includes sensitive information about its environment, users, or associated data.
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.
Time of Introduction
Architecture and Design
Implementation
System Configuration
Operation
Applicable Platforms
Languages
PHP: (Often)
All
Common Consequences
Scope
Effect
Confidentiality
Technical Impact: 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.
Likelihood of Exploit
High
Detection Methods
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
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.
Effectiveness: 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.
Demonstrative Examples
Example 1
In the following example, sensitive information might be printed
depending on the exception that occurs.
(Bad Code)
Example
Language: Java
try {
/.../
}
catch (Exception e) {
System.out.println(e);
}
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
This code tries to open a database connection, and prints any
exceptions that occur.
(Bad Code)
Example
Language: PHP
try {
openDbConnection();
}
//print exception message that includes exception message and
configuration file location
echo 'Check credentials in config file at: ',
$Mysql_config_location, '\n';
}
If an exception occurs, the printed message exposes the location of
the configuration file the script is using. An attacker can use this
information to target the configuration file (perhaps exploiting a Path
Traversal weakness). If the file can be read, the attacker could gain
credentials for accessing the database. The attacker may also be able to
replace the file with a malicious one, causing the application to use an
arbitrary database.
Example 3
The following code generates an error message that leaks the full
pathname of the configuration file.
(Bad Code)
Example
Language: Perl
$ConfigDir = "/home/myprog/config";
$uname = GetUserInput("username");
# avoid CWE-22, CWE-78, others.
ExitError("Bad hacker!") if ($uname !~ /^\w+$/);
$file = "$ConfigDir/$uname.txt";
if (! (-e $file)) {
ExitError("Error: $file does not exist");
}
...
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.
Example 4
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.
(Bad Code)
Example
Language: Java
public BankAccount getUserBankAccount(String username, String
accountNumber) {
BankAccount userAccount = null;
String query = null;
try {
if (isAuthorizedUser(username)) {
query = "SELECT * FROM accounts WHERE owner = "
+ username + " AND accountID = " +
accountNumber;
DatabaseManager dbManager = new
DatabaseManager();
The error message that is created includes information about the database query that may contain sensitive information about the database or query logic. In this case, the error message will expose the table name and column names used in the database. This data could be used to simplify other attacks, such as SQL injection (CWE-89) to directly access the database.
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.
Malformed regexp syntax leads to information
exposure in error message.
Potential Mitigations
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 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.
Phase: Implementation
Handle exceptions internally and do not display errors containing
potentially sensitive information to a user.
Phase: Implementation
Strategy: 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.
Effectiveness: Defense in Depth
This makes it easier to spot places in the code where data is being
used that is unencrypted.
Phases: Implementation; Build and Compilation
Strategies: Compilation or Build Hardening; Environment Hardening
Debugging information should not make its way into a production
release.
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.
Brian Chess and
Jacob West. "Secure Programming with Static Analysis". Section 9.2, page 326.. Addison-Wesley. 2007.
[REF-8] 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
183. McGraw-Hill. 2010.
[REF-17] Michael Howard, David LeBlanc
and John Viega. "24 Deadly Sins of Software Security". "Sin 12: Information Leakage." Page 191. McGraw-Hill. 2010.
[REF-7] Mark Dowd, John McDonald
and Justin Schuh. "The Art of Software Security Assessment". Chapter 3, "Overly Verbose Error Messages", Page
75.. 1st Edition. Addison Wesley. 2006.
Description
