Response Discrepancy Information Leak
Weakness ID: 204 (Weakness Base)Status: Incomplete
+ Description

Description Summary

The software provides different responses to incoming requests in a way that allows an actor to determine system state information that is outside of that actor's control sphere.

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).

+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms

Languages

All

+ Demonstrative Examples

Example 1

The following code checks validity of the supplied username and password and notifies the user of a successful or failed login.

(Bad Code)
Example Language: Perl 
my $username=param('username');
my $password=param('password');

if (IsValidUsername($username) == 1)
{
if (IsValidPassword($username, $password) == 1)
{
print "Login Successful";
}
else
{
print "Login Failed - incorrect password";
}
}
else
{
print "Login Failed - unknown username";
}

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"

+ Observed Examples
ReferenceDescription
CVE-2002-2094This, and others, use ".." attacks and monitor error responses, so there is overlap with directory traversal.
CVE-2001-1483User enumeration by infoleak from inconsistent responses.
CVE-2001-1528Account number enumeration via inconsistent response infoleak.
CVE-2004-2150User enumeration via error message discrepancy infoleak.
CVE-2005-1650Infoleak by inconsistent responses.
CVE-2004-0294
CVE-2004-0243
CVE-2002-0514
CVE-2002-0515
CVE-2001-1387
CVE-2004-0778
CVE-2004-1428
+ Potential Mitigations

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.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class203Information Exposure Through Discrepancy
Development Concepts (primary)699
Research Concepts (primary)1000
+ Relationship Notes

can overlap errors related to escalated privileges

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERResponse discrepancy infoleak
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Potential Mitigations, Time of Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Relationship Notes, Taxonomy Mappings
2008-10-14CWE Content TeamMITREInternal
updated Description, Potential Mitigations
2009-12-28CWE Content TeamMITREInternal
updated Demonstrative Examples
Back to top