The software does not properly anticipate or handle exceptional conditions that rarely occur during normal operation of the software.
Modes of Introduction:
– Architecture and Design
Likelihood of Exploit:
Confidentiality, Availability, Integrity: Read Application Data, DoS: Crash, Exit, or Restart, Unexpected State
The default error page of a web application should not display sensitive information about the software system.
Modes of Introduction:
– Architecture and Design
Likelihood of Exploit:
Confidentiality: Read Application Data
A stack trace might show the attacker a malformed SQL query string, the type of database being used, and the version of the application container. This information enables the attacker to target known vulnerabilities in these components.
Phase: Implementation
Effectiveness:
Description:
Handle exceptions appropriately in source code.
Phase: Implementation, System Configuration
Effectiveness:
Description:
Always define appropriate error pages. The application configuration should specify a default error page in order to guarantee that the application will never leak error messages to an attacker. Handling standard HTTP error codes is useful and user-friendly in addition to being a good security practice, and a good configuration will also define a last-chance error handler that catches any exception that could possibly be thrown by the application.
Phase: Implementation
Effectiveness:
Description:
Do not attempt to process an error or attempt to mask it.
Phase: Implementation
Effectiveness:
Description:
Verify return values are correct and do not supply sensitive information about the system.
The web application sends a redirect to another location, but instead of exiting, it executes additional code.
Modes of Introduction:
– Implementation
Likelihood of Exploit:
Other, Confidentiality, Integrity, Availability: Alter Execution Logic, Execute Unauthorized Code or Commands
This weakness could affect the control flow of the application and allow execution of untrusted code.
The software compares two entities in a security-relevant context, but the comparison is incorrect, which may lead to resultant weaknesses.
Modes of Introduction:
– Implementation
Likelihood of Exploit:
Other: Varies by Context
The product performs multiple related behaviors, but the behaviors are performed in the wrong order in ways which may produce resultant weaknesses.
Modes of Introduction:
– Architecture and Design
Likelihood of Exploit:
Integrity: Alter Execution Logic
The software uses low-level functionality that is explicitly prohibited by the framework or specification under which the software is supposed to operate.
The use of low-level functionality can violate the specification in unexpected ways that effectively disable built-in protection mechanisms, introduce exploitable inconsistencies, or otherwise expose the functionality to attack.
Modes of Introduction:
– Architecture and Design
Likelihood of Exploit:
Other: Other
The software uses multiple resources that can have the same identifier, in a context in which unique identifiers are required.
If the software assumes that each resource has a unique identifier, the software could operate on the wrong resource if attackers can cause multiple resources to be associated with the same identifier.
Modes of Introduction:
– Architecture and Design
Likelihood of Exploit:
Access Control: Bypass Protection Mechanism
If unique identifiers are assumed when protecting sensitive resources, then duplicate identifiers might allow attackers to bypass the protection.
Other: Quality Degradation
Phase: Architecture and Design
Effectiveness:
Description:
Where possible, use unique identifiers. If non-unique identifiers are detected, then do not operate any resource with a non-unique identifier and report the error appropriately.
The product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product.
This weakness covers three distinct situations. A “missing” protection mechanism occurs when the application does not define any mechanism against a certain class of attack. An “insufficient” protection mechanism might provide some defenses – for example, against the most common attacks – but it does not protect against everything that is intended. Finally, an “ignored” mechanism occurs when a mechanism is available and in active use within the product, but the developer has not applied it in some code path.
Modes of Introduction:
– Architecture and Design
Likelihood of Exploit:
Access Control: Bypass Protection Mechanism
The product uses a denylist-based protection mechanism to defend against XSS attacks, but the denylist is incomplete, allowing XSS variants to succeed.
While XSS might seem simple to prevent, web browsers vary so widely in how they parse web pages, that a denylist cannot keep track of all the variations. The “XSS Cheat Sheet” [REF-714] contains a large number of attacks that are intended to bypass incomplete denylists.
Modes of Introduction:
Likelihood of Exploit:
Confidentiality, Integrity, Availability: Execute Unauthorized Code or Commands
The code does not sufficiently manage its control flow during execution, creating conditions in which the control flow can be modified in unexpected ways.
Modes of Introduction:
– Architecture and Design
Likelihood of Exploit:
Other: Alter Execution Logic