Description
The product provides different responses to incoming requests in a way that reveals internal state information to an unauthorized actor outside of the intended control sphere.
Potential Impact
Confidentiality, Access Control
Read Application Data, Bypass Protection Mechanism
Demonstrative Examples
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";
}"Login Failed - incorrect username or password"Mitigations & Prevention
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
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
Real-World CVE Examples
| CVE ID | Description |
|---|---|
| CVE-2002-2094 | This, and others, use ".." attacks and monitor error responses, so there is overlap with directory traversal. |
| CVE-2001-1483 | Enumeration of valid usernames based on inconsistent responses |
| CVE-2001-1528 | Account number enumeration via inconsistent responses. |
| CVE-2004-2150 | User enumeration via discrepancies in error messages. |
| CVE-2005-1650 | User enumeration via discrepancies in error messages. |
| CVE-2004-0294 | Bulletin Board displays different error messages when a user exists or not, which makes it easier for remote attackers to identify valid users and conduct a brute force password guessing attack. |
| CVE-2004-0243 | Operating System, when direct remote login is disabled, displays a different message if the password is correct, which allows remote attackers to guess the password via brute force methods. |
| CVE-2002-0514 | Product allows remote attackers to determine if a port is being filtered because the response packet TTL is different than the default TTL. |
| CVE-2002-0515 | Product sets a different TTL when a port is being filtered than when it is not being filtered, which allows remote attackers to identify filtered ports by comparing TTLs. |
| CVE-2001-1387 | Product may generate different responses than specified by the administrator, possibly leading to an information leak. |
| CVE-2004-0778 | Version control system allows remote attackers to determine the existence of arbitrary files and directories via the -X command for an alternate history file, which causes different error messages to |
| CVE-2004-1428 | FTP server generates an error message if the user name does not exist instead of prompting for a password, which allows remote attackers to determine valid usernames. |
Related Weaknesses
Taxonomy Mappings
- PLOVER: — Response discrepancy infoleak
Frequently Asked Questions
What is CWE-204?
CWE-204 (Observable Response Discrepancy) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Base-level weakness. The product provides different responses to incoming requests in a way that reveals internal state information to an unauthorized actor outside of the intended control sphere.
How can CWE-204 be exploited?
Attackers can exploit CWE-204 (Observable Response Discrepancy) to read application data, bypass protection mechanism. This weakness is typically introduced during the Architecture and Design, Implementation phase of software development.
How do I prevent CWE-204?
Key mitigations include: 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 interfaci
What is the severity of CWE-204?
CWE-204 is classified as a Base-level weakness (Medium abstraction). It has been observed in 12 real-world CVEs.