Description
The software does not handle or incorrectly handles inputs that are related to complex structures.
Modes of Introduction:
Related Weaknesses
Consequences
Integrity: Unexpected State
The software does not handle or incorrectly handles inputs that are related to complex structures.
Modes of Introduction:
Integrity: Unexpected State
The software does not handle or incorrectly handles when a particular structural element is not completely specified.
Modes of Introduction:
– Architecture and Design
Integrity: Unexpected State
The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
Modes of Introduction:
– Architecture and Design
Likelihood of Exploit: High
Confidentiality: Read Application Data
Phase: Architecture and Design
Description:
The code transmits data to another actor, but a portion of the data includes sensitive information that should not be accessible to that actor.
Sensitive information could include data that is sensitive in and of itself (such as credentials or private messages), or otherwise useful in the further exploitation of the system (such as internal file system structure).
Modes of Introduction:
– Implementation
Confidentiality: Read Files or Directories, Read Memory, Read Application Data
Sensitive data may be exposed to attackers.
Phase: Requirements
Description:
Specify which data in the software should be regarded as sensitive. Consider which types of users should have access to which types of data.
Phase: Implementation
Description:
Ensure that any possibly sensitive data specified in the requirements is verified with designers to ensure that it is either a calculated risk or mitigated elsewhere. Any information that is not necessary to the functionality should be removed in order to lower both the overhead and the possibility of security sensitive data being sent.
Phase: System Configuration
Description:
Setup default error messages so that unexpected errors do not disclose sensitive information.
Phase: Architecture and Design
Description:
When trying to keep information confidential, an attacker can often infer some of the information by using statistics.
In situations where data should not be tied to individual users, but a large number of users should be able to make queries that “scrub” the identity of users, it may be possible to get information about a user — e.g., by specifying search terms that are known to be unique to that user.
Modes of Introduction:
– Architecture and Design
Likelihood of Exploit: Medium
Confidentiality: Read Files or Directories, Read Application Data
Sensitive information may possibly be leaked through data queries accidentally.
Phase: Architecture and Design
Description:
This is a complex topic. See the book Translucent Databases for a good discussion of best practices.
The product behaves differently or sends different responses under different circumstances in a way that is observable to an unauthorized actor, which exposes security-relevant information about the state of the product, such as whether a particular operation was successful or not.
Discrepancies can take many forms, and variations may be detectable in timing, control flow, communications such as replies or requests, or general behavior. These discrepancies can reveal information about the product’s operation or internal state to an unauthorized actor. In some cases, discrepancies can be used by attackers to form a side channel.
Modes of Introduction:
– Architecture and Design
Confidentiality, Access Control: Read Application Data, Bypass Protection Mechanism
An attacker can gain access to sensitive information about the system, including authentication information that may allow an attacker to gain access to the system.
Confidentiality: Read Application Data
When cryptographic primitives are vulnerable to side-channel-attacks, this could be used to reveal unencrypted plaintext in the worst case.
Phase: Architecture and Design
Description:
Phase: Implementation
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.
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 exposures can be inadvertent (bug) or intentional (design).
Modes of Introduction:
– Architecture and Design
Confidentiality, Access Control: Read Application Data, Bypass Protection Mechanism
Phase: Architecture and Design
Description:
Phase: Implementation
Description:
The product’s behaviors indicate important differences that may be observed by unauthorized actors in a way that reveals (1) its internal state or decision process, or (2) differences from other products with equivalent functionality.
Ideally, a product should provide as little information about its internal operations as possible. Otherwise, attackers could use knowledge of these internal operations to simplify or optimize their attack. In some cases, behavioral discrepancies can be used by attackers to form a side channel.
Modes of Introduction:
– Architecture and Design
Confidentiality, Access Control: Read Application Data, Bypass Protection Mechanism
The product performs multiple behaviors that are combined to produce a single result, but the individual behaviors are observable separately in a way that allows attackers to reveal internal state or internal decision points.
Ideally, a product should provide as little information as possible to an attacker. Any hints that the attacker may be making progress can then be used to simplify or optimize the attack. For example, in a login procedure that requires a username and password, ultimately there is only one decision: success or failure. However, internally, two separate actions are performed: determining if the username exists, and checking if the password is correct. If the product behaves differently based on whether the username exists or not, then the attacker only needs to concentrate on the password.
Modes of Introduction:
– Architecture and Design
Confidentiality, Access Control: Read Application Data, Bypass Protection Mechanism
Phase:
Description:
Setup generic response pages 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.
The product operates in an environment in which its existence or specific identity should not be known, but it behaves differently than other products with equivalent functionality, in a way that is observable to an attacker.
For many kinds of products, multiple products may be available that perform the same functionality, such as a web server, network interface, or intrusion detection system. Attackers often perform “fingerprinting,” which uses discrepancies in order to identify which specific product is in use. Once the specific product has been identified, the attacks can be made more customized and efficient. Often, an organization might intentionally allow the specific product to be identifiable. However, in some environments, the ability to identify a distinct product is unacceptable, and it is expected that every product would behave in exactly the same way. In these more restricted environments, a behavioral difference might pose an unacceptable risk if it makes it easier to identify the product’s vendor, model, configuration, version, etc.
Modes of Introduction:
– Architecture and Design
Confidentiality, Access Control: Read Application Data, Bypass Protection Mechanism