Leftover Debug Code |
Weakness ID: 489 (Weakness Base) | Status: Draft |
Description Summary
Scope | Effect |
---|---|
Confidentiality Integrity Availability | The severity of the exposed debug application will depend on the particular instance. At the least, it will give an attacker sensitive information about the settings and mechanics of web applications on the server. At worst, as is often the case, the debug application will allow an attacker complete control over the web application and server, as well as confidential information that either of these access. |
Example 1
Debug code can be used to bypass authentication. For example, suppose an application has a login script that receives a username and a password. Assume also that a third, optional, parameter, called "debug", is interpreted by the script as requesting a switch to debug mode, and that when this parameter is given the username and password are not checked. In such a case, it is very simple to bypass the authentication process if the special behavior of the application regarding the debug parameter is known. In a case where the form is:
Then a conforming link will look like:
An attacker can change this to:
Which will grant the attacker access to the site, bypassing the authentication process.
A common development practice is to add "back door" code specifically designed for debugging or testing purposes that is not intended to be shipped or deployed with the application. In web-based applications, debug code is used to test and modify web application properties, configuration information, and functions. If a debug application is left on a production server, an attacker may be able to use it to perform these tasks. When this sort of debug code is left in the application, the application is open to unintended modes of interaction. These back door entry points create security risks because they are not considered during design or testing and fall outside of the expected operating conditions of the application. While it is possible to leave debug code in an application in any language, in J2EE a main method may be a good indicator that debug code has been left in the application, although there may not be any direct security impact. |
Nature | Type | ID | Name | View(s) this relationship pertains to![]() |
---|---|---|---|---|
ChildOf | ![]() | 485 | Insufficient Encapsulation | Development Concepts (primary)699 Seven Pernicious Kingdoms (primary)700 Research Concepts (primary)1000 |
ChildOf | ![]() | 731 | OWASP Top Ten 2004 Category A10 - Insecure Configuration Management | Weaknesses in OWASP Top Ten (2004) (primary)711 |
MemberOf | ![]() | 630 | Weaknesses Examined by SAMATE | Weaknesses Examined by SAMATE (primary)630 |
Mapped Taxonomy Name | Node ID | Fit | Mapped Node Name |
---|---|---|---|
7 Pernicious Kingdoms | Leftover Debug Code | ||
OWASP Top Ten 2004 | A10 | CWE More Specific | Insecure Configuration Management |
A weakness where code path has a statement that defines an entry point into an application which exposes additional state and control information |
Submissions | ||||
---|---|---|---|---|
Submission Date | Submitter | Organization | Source | |
7 Pernicious Kingdoms | Externally Mined | |||
Modifications | ||||
Modification Date | Modifier | Organization | Source | |
2008-07-01 | Eric Dalci | Cigital | External | |
updated Potential Mitigations, Time of Introduction | ||||
2008-08-01 | KDM Analytics | External | ||
added/updated white box definitions | ||||
2008-09-08 | CWE Content Team | MITRE | Internal | |
updated Common Consequences, Relationships, Other Notes, Taxonomy Mappings | ||||
2009-07-27 | CWE Content Team | MITRE | Internal | |
updated Demonstrative Examples | ||||
2009-10-29 | CWE Content Team | MITRE | Internal | |
updated Common Consequences |