logo

Observable Response Discrepancy

Incomplete Base
Structure: Simple
Description

This vulnerability occurs when an application responds differently to similar requests, unintentionally leaking details about its internal state or logic to unauthorized users.

This vulnerability occurs when an application responds differently to similar requests, unintentionally leaking details about its internal state or logic to unauthorized users.
Extended Description

Observable Response Discrepancy happens when an application's output—such as error messages, timing, or even subtle differences in page content—changes based on internal conditions. Attackers can probe these differences to infer sensitive information, like whether a username exists, if a file is present on the server, or the structure of a backend database, without triggering standard access controls. To prevent this, developers must ensure their applications provide consistent, generic responses in all scenarios that could reveal system state. This involves standardizing error messages, implementing uniform response times for all outcomes (success or failure), and avoiding any output that changes based on hidden internal data. Treating all failed operations identically from the user's perspective closes this common information leak.
Common Consequences 1
Scope: ConfidentialityAccess Control

Impact: Read Application DataBypass Protection Mechanism
Potential Mitigations 2
Phase: Architecture and Design

Strategy: Separation of Privilege

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 privilege to decide the appropriate time to use privileges and the time to drop privileges.
Phase: Implementation
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 errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files. Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.
Demonstrative Examples 1

ID : DX-38

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

Code Example:

Bad
Perl
perl
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:

Code Example:

Result
bash
Observed Examples 12
CVE-2002-2094This, and others, use ".." attacks and monitor error responses, so there is overlap with directory traversal.
CVE-2001-1483Enumeration of valid usernames based on inconsistent responses
CVE-2001-1528Account number enumeration via inconsistent responses.
CVE-2004-2150User enumeration via discrepancies in error messages.
CVE-2005-1650User enumeration via discrepancies in error messages.
CVE-2004-0294Bulletin 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-0243Operating 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-0514Product allows remote attackers to determine if a port is being filtered because the response packet TTL is different than the default TTL.
CVE-2002-0515Product 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-1387Product may generate different responses than specified by the administrator, possibly leading to an information leak.
CVE-2004-0778Version 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 be returned.
CVE-2004-1428FTP 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.
References 1
24 Deadly Sins of Software Security
Michael Howard, David LeBlanc, and John Viega
McGraw-Hill
2010
ID: REF-44
Applicable Platforms
Languages:
Not Language-Specific : Undetermined
Modes of Introduction
Architecture and Design
Implementation
Related Attack Patterns
Related Weaknesses
ChildOf: Observable Discrepancy (CWE-203)
Taxonomy Mapping
  • PLOVER
Notes
Relationshipcan overlap errors related to escalated privileges