Response Discrepancy Information Leak |
Weakness ID: 204 (Weakness Base) | Status: Incomplete |
Description Summary
Extended Description
This issue frequently occurs during authentication, where a difference in failed-login messages could allow an attacker to determine if the username is valid or not. These leaks can be inadvertent (bug) or intentional (design).
Example 1
The following code checks validity of the supplied username and password and notifies the user of a successful or failed login.
In the above code, there are different messages for when an incorrect username is supplied, versus when the username is correct but the password is wrong. This difference enables a potential attacker to understand the state of the login function, and could allow an attacker to discover a valid username by trying different values until the incorrect password message is returned. In essence, this makes it easier for an attacker to obtain half of the necessary authentication credentials.
While this type of information may be helpful to a user, it is also useful to a potential attacker. In the above example, the message for both failed cases should be the same, such as:
"Login Failed - incorrect username or password"
Reference | Description |
---|---|
CVE-2002-2094 | This, and others, use ".." attacks and monitor error responses, so there is overlap with directory traversal. |
CVE-2001-1483 | User enumeration by infoleak from inconsistent responses. |
CVE-2001-1528 | Account number enumeration via inconsistent response infoleak. |
CVE-2004-2150 | User enumeration via error message discrepancy infoleak. |
CVE-2005-1650 | Infoleak by inconsistent responses. |
CVE-2004-0294 | |
CVE-2004-0243 | |
CVE-2002-0514 | |
CVE-2002-0515 | |
CVE-2001-1387 | |
CVE-2004-0778 | |
CVE-2004-1428 |
Phase: Architecture and Design Compartmentalize your 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. |
Phase: Architecture and Design Setup generic response for error conditions. The error page should not disclose information about the success or failure of a sensitive operation. For instance, the login page should not confirm that the login is correct and the password incorrect. The attacker who tries random account name may be able to guess some of them. Confirming that the account exists would make the login page more susceptible to brute force attack. |
Nature | Type | ID | Name | View(s) this relationship pertains to |
---|---|---|---|---|
ChildOf | Weakness Class | 203 | Information Exposure Through Discrepancy | Development Concepts (primary)699 Research Concepts (primary)1000 |
Submissions | ||||
---|---|---|---|---|
Submission Date | Submitter | Organization | Source | |
PLOVER | Externally Mined | |||
Modifications | ||||
Modification Date | Modifier | Organization | Source | |
2008-07-01 | Eric Dalci | Cigital | External | |
updated Potential Mitigations, Time of Introduction | ||||
2008-09-08 | CWE Content Team | MITRE | Internal | |
updated Relationships, Relationship Notes, Taxonomy Mappings | ||||
2008-10-14 | CWE Content Team | MITRE | Internal | |
updated Description, Potential Mitigations | ||||
2009-12-28 | CWE Content Team | MITRE | Internal | |
updated Demonstrative Examples |