CWE-497: Exposure of System Data to an Unauthorized Control Sphere
Exposure of System Data to an Unauthorized Control Sphere
Weakness ID: 497 (Weakness Variant)
Status: Incomplete
Description
Description Summary
Exposing system data or debugging information helps an adversary learn about the system and form an attack plan.
Extended Description
An information exposure occurs when system data or debugging information leaves the program through an output stream or logging function that makes it accessible to unauthorized parties. An attacker can also cause errors to occur by submitting unusual requests to the web application. The response to these errors can reveal detailed system information, deny service, cause security mechanisms to fail, and crash the server. An attacker can use error messages that reveal technologies, operating systems, and product versions to tune the attack against known vulnerabilities in these technologies. An application may use diagnostic methods that provide significant implementation details such as stack traces as part of its error handling mechanism.
Time of Introduction
Implementation
Applicable Platforms
Languages
All
Common Consequences
Scope
Effect
Confidentiality
Technical Impact: Read application
data
Demonstrative Examples
Example 1
The following code prints the path environment variable to the
standard error stream:
(Bad Code)
Example
Language: C
char* path = getenv("PATH");
...
sprintf(stderr, "cannot find exe on path %s\n", path);
Example 2
The following code prints an exception to the standard error
stream:
(Bad Code)
Example
Language: Java
try {
...
} catch (Exception e) {
e.printStackTrace();
}
(Bad Code)
try {
...
} catch (Exception e) {
Console.Writeline(e);
}
Depending upon the system configuration, this information can be
dumped to a console, written to a log file, or exposed to a remote user.
In some cases the error message tells the attacker precisely what sort
of an attack the system will be vulnerable to. For example, a database
error message can reveal that the application is vulnerable to a SQL
injection attack. Other error messages can reveal more oblique clues
about the system. In the example above, the search path could imply
information about the type of operating system, the applications
installed on the system, and the amount of care that the administrators
have put into configuring the program.
Example 3
The following code constructs a database connection string, uses it
to create a new connection to the database, and prints it to the
console.
Depending on the system configuration, this information can be dumped
to a console, written to a log file, or exposed to a remote user. In
some cases the error message tells the attacker precisely what sort of
an attack the system is vulnerable to. For example, a database error
message can reveal that the application is vulnerable to a SQL injection
attack. Other error messages can reveal more oblique clues about the
system. In the example above, the search path could imply information
about the type of operating system, the applications installed on the
system, and the amount of care that the administrators have put into
configuring the program.
Potential Mitigations
Phases: Architecture and Design; Implementation
Production applications should never use methods that generate
internal details such as stack traces and error messages unless that
information is directly committed to a log that is not viewable by the
end user. All error message text should be HTML entity encoded before
being written to the log file to protect against potential cross-site
scripting attacks against the viewer of the logs
Description
