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

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

View ID: 1358

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

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.

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.Incorrect Resource Transfer Between Spheres - (669)

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.

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.

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.

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.

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.Use of a Broken or Risky Cryptographic Algorithm - (327)

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.

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.Improperly Implemented Security Check for Standard - (358)

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.

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.

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)

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) > 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.

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.Reliance on Insufficiently Trustworthy Component - (1357)

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.

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

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.Externally Controlled Reference to a Resource in Another Sphere - (610)

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.

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.Reliance on Insufficiently Trustworthy Component - (1357)

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.

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.

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.Generation of Predictable IV with CBC Mode - (329)

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.

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.Reliance on Insufficiently Trustworthy Component - (1357)

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.

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) > 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) > 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) > 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.

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.

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.

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.Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') - (362)

The product contains a code sequence that can run concurrently with other code, and the code sequence 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 that is operating concurrently.

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.

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.User Interface (UI) Misrepresentation of Critical Information - (451)

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.

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)

A web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a Redirect. This simplifies phishing attacks.Open RedirectCross-site RedirectCross-domain 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.

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	45	out of	933
Categories	26	out of	352
Views	0	out of	47
Total	71	out of	1332

Content History

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

View Components

Weakness ID: 362

Abstraction: Class
Structure: Simple

View customized information:

Description

Extended Description

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.

A race condition occurs within concurrent environments, and 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. 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).

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.

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	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

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

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.	367	Time-of-check Time-of-use (TOCTOU) Race Condition

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
Implementation

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

C (Sometimes Prevalent)

C++ (Sometimes Prevalent)

Java (Sometimes Prevalent)

Technologies

Class: Mobile (Undetermined Prevalence)

Class: ICS/OT (Undetermined Prevalence)

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
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 (CWE-400).
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).

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).

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.

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

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	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	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
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.	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

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. <http://www.ddj.com/cpp/184403766>.

[REF-350] Steven Devijver. "Thread-safe webapps using Spring". <http://www.javalobby.org/articles/thread-safe/index.jsp>.

[REF-351] David Wheeler. "Prevent race conditions". 2007-10-04. <http://www.ibm.com/developerworks/library/l-sprace.html>.

[REF-352] Matt Bishop. "Race Conditions, Files, and Security Flaws; or the Tortoise and the Hare Redux". 1995-09. <http://www.cs.ucdavis.edu/research/tech-reports/1995/CSE-95-9.pdf>.

[REF-353] David Wheeler. "Secure Programming for Linux and Unix HOWTO". 2003-03-03. <http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/avoid-race.html>.

[REF-354] Blake Watts. "Discovering and Exploiting Named Pipe Security Flaws for Fun and Profit". 2002-04. <http://www.blakewatts.com/namedpipepaper.html>.

[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. <http://developer.apple.com/documentation/Security/Conceptual/SecureCodingGuide/Articles/RaceConditions.html>.

[REF-357] Johannes Ullrich. "Top 25 Series - Rank 25 - Race Conditions". SANS Software Security Institute. 2010-03-26. <http://blogs.sans.org/appsecstreetfighter/2010/03/26/top-25-series-rank-25-race-conditions/>.

[REF-76] Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14. <https://www.cisa.gov/uscert/bsi/articles/knowledge/principles/least-privilege>.

[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	PLOVER
2006-07-19
Contributions
Contribution Date	Contributor	Organization
2010-04-30	Martin Sebor	Cisco Systems, Inc.
2010-04-30	Provided Demonstrative Example
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
Previous Entry Names
Change Date	Previous Entry Name
2008-04-11	Race Conditions

2010-12-13	Race Condition

Weakness ID: 668

Abstraction: Class
Structure: Simple

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.

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	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.	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
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

Common Consequences

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

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	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
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

Notes

Mapping

Use for Mapping: Discouraged (this CWE ID should not be used to map to real-world vulnerabilities).

Rationale: CWE-668 is high-level and can be used 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.

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>.

Content History

Submissions
Submission Date	Submitter	Organization
2008-04-11	CWE Content Team	MITRE
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

Weakness ID: 610

Abstraction: Class
Structure: Simple

View customized information:

Description

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

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	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	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.	384	Session Fixation
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.	441	Unintended Proxy or Intermediary ('Confused Deputy')
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	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.	601	URL Redirection to Untrusted Site ('Open Redirect')
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.	611	Improper Restriction of XML External Entity Reference
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.	386	Symbolic Name not Mapping to Correct Object

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

Nature	Type	ID	Name
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.	384	Session Fixation
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.	601	URL Redirection to Untrusted Site ('Open Redirect')
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.	611	Improper Restriction of XML External Entity Reference
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.	918	Server-Side Request Forgery (SSRF)
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.	1021	Improper Restriction of Rendered UI Layers or Frames

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.	1015	Limit Access

Modes Of Introduction

Phase	Note
Architecture and Design	COMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.

Common Consequences

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

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	980	SFP Secondary Cluster: Link in Resource Name Resolution
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
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	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1368	ICS Dependencies (& Architecture): External Digital Systems

Notes

Relationship

This is a general class of weakness, but most research is focused on more specialized cases, such as path traversal (CWE-22) and symlink following (CWE-61). A symbolic link has a name; in general, it appears like any other file in the file system. However, the link includes a reference to another file, often in another directory - perhaps in another sphere of control. Many common library functions that accept filenames will "follow" a symbolic link and use the link's target instead.

Maintenance

The relationship between CWE-99 and CWE-610 needs further investigation and clarification. They might be duplicates. CWE-99 "Resource Injection," as originally defined in Seven Pernicious Kingdoms taxonomy, emphasizes the "identifier used to access a system resource" such as a file name or port number, yet it explicitly states that the "resource injection" term does not apply to "path manipulation," which effectively identifies the path at which a resource can be found and could be considered to be one aspect of a resource identifier. Also, CWE-610 effectively covers any type of resource, whether that resource is at the system layer, the application layer, or the code layer.

Related Attack Patterns

CAPEC-ID	Attack Pattern Name
CAPEC-219	XML Routing Detour Attacks

Content History

Submissions
Submission Date	Submitter	Organization
2007-05-07	Anonymous Tool Vendor (under NDA)
2007-05-07
Modifications
Modification Date	Modifier	Organization
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Relationships, Other_Notes, Taxonomy_Mappings
2009-10-29	CWE Content Team	MITRE
2009-10-29	updated Other_Notes, Relationship_Notes
2010-04-05	CWE Content Team	MITRE
2010-04-05	updated Related_Attack_Patterns
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 Maintenance_Notes
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, 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 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
Previous Entry Names
Change Date	Previous Entry Name
2008-04-11	Externally Controlled Reference to an Internal Resource

Weakness ID: 284

Abstraction: Pillar
Structure: Simple

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.

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)

Common Consequences

Scope	Impact	Likelihood
Other	Technical Impact: Varies by Context

Observed Examples

Reference	Description
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-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.

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.

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

Notes

Mapping

Use for Mapping: Discouraged (this CWE ID should not be used to map to real-world vulnerabilities).

Rationale: CWE-284 is extremely high-level, a Pillar. Its name, "Improper Access Control," is often used in low-information vulnerability reports [REF-1287]. 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.

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	PLOVER
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
Previous Entry Names
Change Date	Previous Entry Name
2008-09-09	Access Control Issues

2011-03-29	Access Control (Authorization) Issues

Weakness ID: 710

Abstraction: Pillar
Structure: Simple

View customized information:

Description

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

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	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
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.	477	Use of Obsolete 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.	484	Omitted Break Statement in Switch
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.	489	Active Debug 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.	570	Expression is Always False
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.	571	Expression is Always True
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.	573	Improper Following of Specification by Caller
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.	594	J2EE Framework: Saving Unserializable Objects to Disk
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.	657	Violation of Secure Design Principles
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.	684	Incorrect Provision of Specified Functionality
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.	758	Reliance on Undefined, Unspecified, or Implementation-Defined Behavior
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.	1041	Use of Redundant 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.	1044	Architecture with Number of Horizontal Layers 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.	1048	Invokable Control Element with Large Number of Outward Calls
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.	1059	Insufficient Technical Documentation
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.	1061	Insufficient Encapsulation
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.	1065	Runtime Resource Management Control Element in a Component Built to Run on Application Servers
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.	1066	Missing Serialization Control 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.	1068	Inconsistency Between Implementation and Documented Design
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.	1070	Serializable Data Element Containing non-Serializable Item Elements
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.	1076	Insufficient Adherence to Expected Conventions
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.	1092	Use of Same Invokable Control Element in Multiple Architectural Layers
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.	1093	Excessively Complex Data Representation
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.	1101	Reliance on Runtime Component in Generated Code
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.	1120	Excessive Code Complexity
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.	1126	Declaration of Variable with Unnecessarily Wide Scope
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.	1127	Compilation with Insufficient Warnings or Errors
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.	1164	Irrelevant Code
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.	1177	Use of Prohibited 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.	1209	Failure to Disable Reserved Bits
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.	1357	Reliance on Insufficiently Trustworthy Component

Modes Of Introduction

Phase	Note
Architecture and Design
Implementation

Applicable Platforms

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Class: Not Technology-Specific (Undetermined Prevalence)

Common Consequences

Scope	Impact	Likelihood
Other	Technical Impact: Other

Potential Mitigations

Phase: Implementation

Document and closely follow coding standards.

Phases: Testing; Implementation

Where possible, use automated tools to enforce the standards.

Memberships

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	978	SFP Secondary Cluster: Implementation
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1383	ICS Operations (& Maintenance): Compliance/Conformance with Regulatory Requirements

Content History

Submissions
Submission Date	Submitter	Organization
2008-09-09	CWE Content Team	MITRE
2008-09-09
Modifications
Modification Date	Modifier	Organization
2009-03-10	CWE Content Team	MITRE
2009-03-10	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
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 Relationships
2017-01-19	CWE Content Team	MITRE
2017-01-19	updated Relationships
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated Applicable_Platforms, Name, Relationships
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Relationships
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated Applicable_Platforms, Relationships, Type
2022-04-28	CWE Content Team	MITRE
2022-04-28	updated Relationships
2023-01-31	CWE Content Team	MITRE
2023-01-31	updated Description
Previous Entry Names
Change Date	Previous Entry Name
2017-11-08	Coding Standards Violation

Weakness ID: 285

Abstraction: Class
Structure: Simple

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.

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)

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.

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.

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.

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

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 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

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". <http://csrc.nist.gov/groups/SNS/rbac/>.

[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. <http://blogs.sans.org/appsecstreetfighter/2010/03/04/top-25-series-rank-5-improper-access-control-authorization/>.

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

[REF-233] Rahul Bhattacharjee. "Authentication using JAAS". <http://www.javaranch.com/journal/2008/04/authentication-using-JAAS.html>.

[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	7 Pernicious Kingdoms
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
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

Abstraction: Base
Structure: Simple

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.

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)

Common Consequences

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

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.

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.

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

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 Community
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
Previous Entry Names
Change Date	Previous Entry Name
2013-02-21	Certificate Issues

Common Weakness Enumeration

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

View Components

CWE-349: Acceptance of Extraneous Untrusted Data With Trusted Data

CWE-489: Active Debug Code

CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')

CWE-440: Expected Behavior Violation

CWE-668: Exposure of Resource to Wrong Sphere

CWE-15: External Control of System or Configuration Setting

CWE-610: Externally Controlled Reference to a Resource in Another Sphere

CWE-329: Generation of Predictable IV with CBC Mode

CWE-912: Hidden Functionality

CWE CATEGORY: ICS Communications

CWE CATEGORY: ICS Communications: Frail Security in Protocols

CWE CATEGORY: ICS Communications: Unreliability

CWE CATEGORY: ICS Communications: Zone Boundary Failures

CWE CATEGORY: ICS Dependencies (& Architecture)

CWE CATEGORY: ICS Dependencies (& Architecture): External Digital Systems

CWE CATEGORY: ICS Dependencies (& Architecture): External Physical Systems

CWE CATEGORY: ICS Engineering (Construction/Deployment): Gaps in Details/Data

CWE CATEGORY: ICS Engineering (Construction/Deployment): Inherent Predictability in Design

CWE CATEGORY: ICS Engineering (Construction/Deployment): Maker Breaker Blindness

CWE CATEGORY: ICS Engineering (Construction/Deployment): Security Gaps in Commissioning

CWE CATEGORY: ICS Engineering (Construction/Deployment): Trust Model Problems

CWE CATEGORY: ICS Engineering (Constructions/Deployment)

CWE CATEGORY: ICS Operations (& Maintenance)

CWE CATEGORY: ICS Operations (& Maintenance): Compliance/Conformance with Regulatory Requirements

CWE CATEGORY: ICS Operations (& Maintenance): Emerging Energy Technologies

CWE CATEGORY: ICS Operations (& Maintenance): Exploitable Standard Operational Procedures

CWE CATEGORY: ICS Operations (& Maintenance): Gaps in obligations and training

CWE CATEGORY: ICS Operations (& Maintenance): Human factors in ICS environments

CWE CATEGORY: ICS Operations (& Maintenance): Post-analysis changes

CWE CATEGORY: ICS Supply Chain

CWE CATEGORY: ICS Supply Chain: Common Mode Frailties

CWE CATEGORY: ICS Supply Chain: IT/OT Convergence/Expansion

CWE CATEGORY: ICS Supply Chain: OT Counterfeit and Malicious Corruption

CWE CATEGORY: ICS Supply Chain: Poorly Documented or Undocumented Features

CWE-284: Improper Access Control

CWE-710: Improper Adherence to Coding Standards

CWE-285: Improper Authorization

CWE-295: Improper Certificate Validation

CWE-754: Improper Check for Unusual or Exceptional Conditions