Description
The product inserts sensitive information into debugging code, which could expose this information if the debugging code is not disabled in production.
When debugging, it may be necessary to report detailed information to the programmer. However, if the debugging code is not disabled when the product is operating in a production environment, then this sensitive information may be exposed to attackers.
Potential Impact
Confidentiality
Read Application Data
Demonstrative Examples
<% if (Boolean.getBoolean("debugEnabled")) {
%>User account number: <%= acctNo %><%} %>Mitigations & Prevention
Do not leave debug statements that could be executed in the source code. Ensure that all debug information is eradicated before releasing the software.
Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least
Detection Methods
- Automated Static Analysis High — 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 sea
Real-World CVE Examples
| CVE ID | Description |
|---|---|
| CVE-2004-2268 | Password exposed in debug information. |
| CVE-2002-0918 | CGI script includes sensitive information in debug messages when an error is triggered. |
| CVE-2003-1078 | FTP client with debug option enabled shows password to the screen. |
Related Weaknesses
Taxonomy Mappings
- PLOVER: — Infoleak Using Debug Information
- OWASP Top Ten 2007: A6 — Information Leakage and Improper Error Handling
- OWASP Top Ten 2004: A10 — Insecure Configuration Management
- Software Fault Patterns: SFP23 — Exposed Data
Frequently Asked Questions
What is CWE-215?
CWE-215 (Insertion of Sensitive Information Into Debugging Code) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Base-level weakness. The product inserts sensitive information into debugging code, which could expose this information if the debugging code is not disabled in production.
How can CWE-215 be exploited?
Attackers can exploit CWE-215 (Insertion of Sensitive Information Into Debugging Code) to read application data. This weakness is typically introduced during the Implementation phase of software development.
How do I prevent CWE-215?
Key mitigations include: Do not leave debug statements that could be executed in the source code. Ensure that all debug information is eradicated before releasing the software.
What is the severity of CWE-215?
CWE-215 is classified as a Base-level weakness (Medium abstraction). It has been observed in 3 real-world CVEs.