535
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.
Automated Static Analysis
Automated static analysis, commonly referred to as Static Application Security Testing (SAST),
can find some instances of this weakness by analyzing source code (or binary/compiled code)
without having to execute it. Typically, this is done by building a model of data flow and control
flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input)
with "sinks" (destinations where the data interacts with external components, a lower layer such
as the OS, etc.)
Potential Mitigations
Phase: Implementation
Ensure that error messages only contain minimal details that are useful to the intended audience
and no one else. The messages need to strike the balance between being too cryptic (which
can confuse users) or being too detailed (which may reveal more than intended). The messages
should not reveal the methods that were used to determine the error. Attackers can use detailed
information to refine or optimize their original attack, thereby increasing their chances of success.
If errors must be captured in some detail, record them in log messages, but consider what
could occur if the log messages can be viewed by attackers. Highly sensitive information such
as passwords should never be saved to log files. Avoid inconsistent messaging that might
accidentally tip off an attacker about internal state, such as whether a user account exists or not.
Phase: Implementation
Handle exceptions internally and do not display errors containing potentially sensitive information
to a user.
Phase: Implementation
Strategy = Attack Surface Reduction
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.
Phase: Implementation
Phase: Build and Compilation
Strategy = Compilation or Build Hardening
Debugging information should not make its way into a production release.
Phase: Implementation
Phase: Build and Compilation
CWE Version 4.14
CWE-209: Generation of Error Message Containing Sensitive Information
CWE-209: Generation of Error Message Containing Sensitive Information