CWE

Common Weakness Enumeration

A community-developed list of SW & HW weaknesses that can become vulnerabilities

New to CWE? click here!
CWE Most Important Hardware Weaknesses
CWE Top 25 Most Dangerous Weaknesses
Home > CWE List > VIEW SLICE: CWE-701: Weaknesses Introduced During Design (4.17)  
ID

CWE VIEW: Weaknesses Introduced During Design

View ID: 701
Vulnerability Mapping: PROHIBITED This CWE ID must not be used to map to real-world vulnerabilities
Type: Implicit
Downloads: Booklet | CSV | XML
+ Objective
This view (slice) lists weaknesses that can be introduced during design.
+ Filter
/Weakness_Catalog/Weaknesses/Weakness[(@Abstraction='Base') or (@Abstraction='Class')][./Modes_Of_Introduction/Introduction/Phase='Architecture and Design']
+ Membership
Nature Type ID Name
HasMember ClassClass - 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. 20 Improper Input Validation
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember ClassClass - 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. 99 Improper Control of Resource Identifiers ('Resource Injection')
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 115 Misinterpretation of Input
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 184 Incomplete List of Disallowed Inputs
HasMember ClassClass - 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 201 Insertion of Sensitive Information Into Sent Data
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 202 Exposure of Sensitive Information Through Data Queries
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 203 Observable Discrepancy
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 204 Observable Response Discrepancy
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 205 Observable Behavioral Discrepancy
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 208 Observable Timing Discrepancy
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 209 Generation of Error Message Containing Sensitive Information
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 210 Self-generated Error Message Containing Sensitive Information
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 211 Externally-Generated Error Message Containing Sensitive Information
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 212 Improper Removal of Sensitive Information Before Storage or Transfer
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 213 Exposure of Sensitive Information Due to Incompatible Policies
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 214 Invocation of Process Using Visible Sensitive Information
HasMember ClassClass - 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. 221 Information Loss or Omission
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 223 Omission of Security-relevant Information
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 250 Execution with Unnecessary Privileges
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 256 Plaintext Storage of a Password
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 257 Storing Passwords in a Recoverable Format
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 260 Password in Configuration File
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 261 Weak Encoding for Password
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 262 Not Using Password Aging
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 263 Password Aging with Long Expiration
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 267 Privilege Defined With Unsafe Actions
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 268 Privilege Chaining
HasMember ClassClass - 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 270 Privilege Context Switching Error
HasMember ClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 271 Privilege Dropping / Lowering Errors
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 276 Incorrect Default Permissions
HasMember ClassClass - 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 283 Unverified Ownership
HasMember ClassClass - 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
HasMember ClassClass - 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
HasMember ClassClass - 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 289 Authentication Bypass by Alternate Name
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 294 Authentication Bypass by Capture-replay
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 295 Improper Certificate Validation
HasMember ClassClass - 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. 300 Channel Accessible by Non-Endpoint
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 301 Reflection Attack in an Authentication Protocol
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 302 Authentication Bypass by Assumed-Immutable Data
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 306 Missing Authentication for Critical Function
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 307 Improper Restriction of Excessive Authentication Attempts
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 308 Use of Single-factor Authentication
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 309 Use of Password System for Primary Authentication
HasMember ClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 311 Missing Encryption of Sensitive Data
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 312 Cleartext Storage of Sensitive Information
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 319 Cleartext Transmission of Sensitive Information
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 323 Reusing a Nonce, Key Pair in Encryption
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 324 Use of a Key Past its Expiration Date
HasMember ClassClass - 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. 326 Inadequate Encryption Strength
HasMember ClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 327 Use of a Broken or Risky Cryptographic Algorithm
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 328 Use of Weak Hash
HasMember ClassClass - 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. 330 Use of Insufficiently Random Values
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 331 Insufficient Entropy
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 334 Small Space of Random Values
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 338 Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG)
HasMember ClassClass - 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. 340 Generation of Predictable Numbers or Identifiers
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 341 Predictable from Observable State
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 342 Predictable Exact Value from Previous Values
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 343 Predictable Value Range from Previous Values
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 344 Use of Invariant Value in Dynamically Changing Context
HasMember ClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 345 Insufficient Verification of Data Authenticity
HasMember ClassClass - 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 347 Improper Verification of Cryptographic Signature
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 348 Use of Less Trusted Source
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 353 Missing Support for Integrity Check
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 354 Improper Validation of Integrity Check Value
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 356 Product UI does not Warn User of Unsafe Actions
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 357 Insufficient UI Warning of Dangerous Operations
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 358 Improperly Implemented Security Check for Standard
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 359 Exposure of Private Personal Information to an Unauthorized Actor
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 360 Trust of System Event Data
HasMember ClassClass - 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. 362 Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 363 Race Condition Enabling Link Following
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 385 Covert Timing Channel
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember ClassClass - 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. 400 Uncontrolled Resource Consumption
HasMember ClassClass - 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')
HasMember ClassClass - 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. 405 Asymmetric Resource Consumption (Amplification)
HasMember ClassClass - 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. 406 Insufficient Control of Network Message Volume (Network Amplification)
HasMember ClassClass - 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. 407 Inefficient Algorithmic Complexity
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 408 Incorrect Behavior Order: Early Amplification
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 409 Improper Handling of Highly Compressed Data (Data Amplification)
HasMember ClassClass - 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. 410 Insufficient Resource Pool
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 412 Unrestricted Externally Accessible Lock
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 413 Improper Resource Locking
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 414 Missing Lock Check
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 419 Unprotected Primary Channel
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 420 Unprotected Alternate Channel
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember ClassClass - 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. 424 Improper Protection of Alternate Path
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 434 Unrestricted Upload of File with Dangerous Type
HasMember ClassClass - 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. 436 Interpretation Conflict
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 437 Incomplete Model of Endpoint Features
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 439 Behavioral Change in New Version or Environment
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 440 Expected Behavior Violation
HasMember ClassClass - 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')
HasMember ClassClass - 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. 446 UI Discrepancy for Security Feature
HasMember ClassClass - 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. 451 User Interface (UI) Misrepresentation of Critical Information
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 454 External Initialization of Trusted Variables or Data Stores
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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')
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 471 Modification of Assumed-Immutable Data (MAID)
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 475 Undefined Behavior for Input to API
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 494 Download of Code Without Integrity Check
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 501 Trust Boundary Violation
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 502 Deserialization of Untrusted Data
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 510 Trapdoor
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 511 Logic/Time Bomb
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 512 Spyware
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 521 Weak Password Requirements
HasMember ClassClass - 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 523 Unprotected Transport of Credentials
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 532 Insertion of Sensitive Information into Log File
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 544 Missing Standardized Error Handling Mechanism
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 565 Reliance on Cookies without Validation and Integrity Checking
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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')
HasMember ClassClass - 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. 602 Client-Side Enforcement of Server-Side Security
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 603 Use of Client-Side Authentication
HasMember ClassClass - 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. 610 Externally Controlled Reference to a Resource in Another Sphere
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 612 Improper Authorization of Index Containing Sensitive Information
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 613 Insufficient Session Expiration
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 620 Unverified Password Change
HasMember ClassClass - 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. 636 Not Failing Securely ('Failing Open')
HasMember ClassClass - 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. 637 Unnecessary Complexity in Protection Mechanism (Not Using 'Economy of Mechanism')
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 640 Weak Password Recovery Mechanism for Forgotten Password
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 641 Improper Restriction of Names for Files and Other Resources
HasMember ClassClass - 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 645 Overly Restrictive Account Lockout Mechanism
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 648 Incorrect Use of Privileged APIs
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 649 Reliance on Obfuscation or Encryption of Security-Relevant Inputs without Integrity Checking
HasMember ClassClass - 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. 653 Improper Isolation or Compartmentalization
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 654 Reliance on a Single Factor in a Security Decision
HasMember ClassClass - 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. 655 Insufficient Psychological Acceptability
HasMember ClassClass - 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. 656 Reliance on Security Through Obscurity
HasMember ClassClass - 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
HasMember ClassClass - 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
HasMember ClassClass - 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. 667 Improper Locking
HasMember ClassClass - 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. 668 Exposure of Resource to Wrong Sphere
HasMember ClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 669 Incorrect Resource Transfer Between Spheres
HasMember ClassClass - 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. 671 Lack of Administrator Control over Security
HasMember ClassClass - 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. 673 External Influence of Sphere Definition
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 694 Use of Multiple Resources with Duplicate Identifier
HasMember ClassClass - 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. 696 Incorrect Behavior Order
HasMember ClassClass - 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. 706 Use of Incorrectly-Resolved Name or Reference
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 708 Incorrect Ownership Assignment
HasMember ClassClass - 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 757 Selection of Less-Secure Algorithm During Negotiation ('Algorithm Downgrade')
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 770 Allocation of Resources Without Limits or Throttling
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 798 Use of Hard-coded Credentials
HasMember ClassClass - 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. 799 Improper Control of Interaction Frequency
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 804 Guessable CAPTCHA
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 807 Reliance on Untrusted Inputs in a Security Decision
HasMember ClassClass - 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
HasMember ClassClass - 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
HasMember ClassClass - 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. 912 Hidden Functionality
HasMember ClassClass - 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. 913 Improper Control of Dynamically-Managed Code Resources
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 915 Improperly Controlled Modification of Dynamically-Determined Object Attributes
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 916 Use of Password Hash With Insufficient Computational Effort
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 917 Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection')
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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)
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 920 Improper Restriction of Power Consumption
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 921 Storage of Sensitive Data in a Mechanism without Access Control
HasMember ClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 922 Insecure Storage of Sensitive Information
HasMember ClassClass - 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 924 Improper Enforcement of Message Integrity During Transmission in a Communication Channel
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 940 Improper Verification of Source of a Communication Channel
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 941 Incorrectly Specified Destination in a Communication Channel
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1007 Insufficient Visual Distinction of Homoglyphs Presented to User
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1037 Processor Optimization Removal or Modification of Security-critical Code
HasMember ClassClass - 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. 1038 Insecure Automated Optimizations
HasMember ClassClass - 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. 1039 Inadequate Detection or Handling of Adversarial Input Perturbations in Automated Recognition Mechanism
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember ClassClass - 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1173 Improper Use of Validation Framework
HasMember ClassClass - 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. 1176 Inefficient CPU Computation
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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)
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1190 DMA Device Enabled Too Early in Boot Phase
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1192 Improper Identifier for IP Block used in System-On-Chip (SOC)
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1232 Improper Lock Behavior After Power State Transition
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1234 Hardware Internal or Debug Modes Allow Override of Locks
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1240 Use of a Cryptographic Primitive with a Risky Implementation
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1241 Use of Predictable Algorithm in Random Number Generator
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1243 Sensitive Non-Volatile Information Not Protected During Debug
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1244 Internal Asset Exposed to Unsafe Debug Access Level or State
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1245 Improper Finite State Machines (FSMs) in Hardware Logic
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1246 Improper Write Handling in Limited-write Non-Volatile Memories
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1249 Application-Level Admin Tool with Inconsistent View of Underlying Operating System
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1253 Incorrect Selection of Fuse Values
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1254 Incorrect Comparison Logic Granularity
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1258 Exposure of Sensitive System Information Due to Uncleared Debug Information
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1261 Improper Handling of Single Event Upsets
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember ClassClass - 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1264 Hardware Logic with Insecure De-Synchronization between Control and Data Channels
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1266 Improper Scrubbing of Sensitive Data from Decommissioned Device
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1272 Sensitive Information Uncleared Before Debug/Power State Transition
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1277 Firmware Not Updateable
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1278 Missing Protection Against Hardware Reverse Engineering Using Integrated Circuit (IC) Imaging Techniques
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1279 Cryptographic Operations are run Before Supporting Units are Ready
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1281 Sequence of Processor Instructions Leads to Unexpected Behavior
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1293 Missing Source Correlation of Multiple Independent Data
HasMember ClassClass - 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1299 Missing Protection Mechanism for Alternate Hardware Interface
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1302 Missing Source Identifier in Entity Transactions on a System-On-Chip (SOC)
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1303 Non-Transparent Sharing of Microarchitectural Resources
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1310 Missing Ability to Patch ROM Code
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1314 Missing Write Protection for Parametric Data Values
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1318 Missing Support for Security Features in On-chip Fabrics or Buses
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1319 Improper Protection against Electromagnetic Fault Injection (EM-FI)
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1326 Missing Immutable Root of Trust in Hardware
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1329 Reliance on Component That is Not Updateable
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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)
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1332 Improper Handling of Faults that Lead to Instruction Skips
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1336 Improper Neutralization of Special Elements Used in a Template Engine
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1338 Improper Protections Against Hardware Overheating
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1342 Information Exposure through Microarchitectural State after Transient Execution
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1351 Improper Handling of Hardware Behavior in Exceptionally Cold Environments
HasMember ClassClass - 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
HasMember ClassClass - 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. 1384 Improper Handling of Physical or Environmental Conditions
HasMember ClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 1390 Weak Authentication
HasMember ClassClass - 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. 1391 Use of Weak Credentials
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1392 Use of Default Credentials
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1393 Use of Default Password
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1394 Use of Default Cryptographic Key
HasMember ClassClass - 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. 1395 Dependency on Vulnerable Third-Party Component
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1420 Exposure of Sensitive Information during Transient Execution
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1421 Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1422 Exposure of Sensitive Information caused by Incorrect Data Forwarding during Transient Execution
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1423 Exposure of Sensitive Information caused by Shared Microarchitectural Predictor State that Influences Transient Execution
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1426 Improper Validation of Generative AI Output
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1427 Improper Neutralization of Input Used for LLM Prompting
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1428 Reliance on HTTP instead of HTTPS
HasMember BaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1429 Missing Security-Relevant Feedback for Unexecuted Operations in Hardware Interface
+ Vulnerability Mapping Notes

Usage: PROHIBITED

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

Reason: View

Rationale:

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

Comments:

Use this View or other Views to search and navigate for the appropriate weakness.
+ View Metrics
CWEs in this view Total CWEs
Weaknesses 276 out of 943
Categories 0 out of 374
Views 0 out of 51
Total 276 out of 1368
+ Content History
+ Submissions
Submission Date Submitter Organization
2008-09-09
(CWE 1.0, 2008-09-09)
CWE Content Team MITRE
+ Modifications
Modification Date Modifier Organization
2009-02-10 CWE Content Team MITRE
Updated the View_Filter to reflect new structure in CWE Schema v4.2
2009-03-10 CWE Content Team MITRE
updated View_Filter
2017-01-19 CWE Content Team MITRE
updated Relationships
2023-04-27 CWE Content Team MITRE
updated View_Filter
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes

View Components

A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z

CWE-770: Allocation of Resources Without Limits or Throttling

Weakness ID: 770
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor.
+ Extended Description

Code frequently has to work with limited resources, so programmers must be careful to ensure that resources are not consumed too quickly, or too easily. Without use of quotas, resource limits, or other protection mechanisms, it can be easy for an attacker to consume many resources by rapidly making many requests, or causing larger resources to be used than is needed. When too many resources are allocated, or if a single resource is too large, then it can prevent the code from working correctly, possibly leading to a denial of service.

+ Common Consequences
Section HelpThis 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.
Impact Details

DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory); DoS: Resource Consumption (Other)

Scope: Availability

When allocating resources without limits, an attacker could prevent other systems, applications, or processes from accessing the same type of resource.
+ Potential Mitigations
Phase(s) Mitigation

Requirements

Clearly specify the minimum and maximum expectations for capabilities, and dictate which behaviors are acceptable when resource allocation reaches limits.

Architecture and Design

Limit the amount of resources that are accessible to unprivileged users. Set per-user limits for resources. Allow the system administrator to define these limits. Be careful to avoid CWE-410.

Architecture and Design

Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place, and it will help the administrator to identify who is committing the abuse. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.

Implementation

Strategy: Input Validation

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

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

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

Note: This will only be applicable to cases where user input can influence the size or frequency of resource allocations.

Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Architecture and Design

Mitigation of resource exhaustion attacks requires that the target system either:

  • recognizes the attack and denies that user further access for a given amount of time, typically by using increasing time delays
  • uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.

The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question.

The second solution can be difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply requires more resources on the part of the attacker.

Architecture and Design

Ensure that protocols have specific limits of scale placed on them.

Architecture and Design; Implementation

If the program must fail, ensure that it fails gracefully (fails closed). There may be a temptation to simply let the program fail poorly in cases such as low memory conditions, but an attacker may be able to assert control before the software has fully exited. Alternately, an uncontrolled failure could cause cascading problems with other downstream components; for example, the program could send a signal to a downstream process so the process immediately knows that a problem has occurred and has a better chance of recovery.

Ensure that all failures in resource allocation place the system into a safe posture.

Operation; Architecture and Design

Strategy: Resource Limitation

Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems.

When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users.

Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).

+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 400 Uncontrolled Resource Consumption
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 665 Improper Initialization
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 774 Allocation of File Descriptors or Handles Without Limits or Throttling
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 789 Memory Allocation with Excessive Size Value
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1325 Improperly Controlled Sequential Memory Allocation
CanFollow Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 20 Improper Input Validation
+ Relevant to the view "Software Development" (View-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 399 Resource Management Errors
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 840 Business Logic Errors
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 400 Uncontrolled Resource Consumption
+ Relevant to the view "Architectural Concepts" (View-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1011 Authorize Actors
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Implementation
Operation
System Configuration
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Often Prevalent)

+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1


This code allocates a socket and forks each time it receives a new connection.

(bad code)
Example Language:
sock=socket(AF_INET, SOCK_STREAM, 0);
while (1) {
newsock=accept(sock, ...);
printf("A connection has been accepted\n");
pid = fork();
}

The program does not track how many connections have been made, and it does not limit the number of connections. Because forking is a relatively expensive operation, an attacker would be able to cause the system to run out of CPU, processes, or memory by making a large number of connections. Alternatively, an attacker could consume all available connections, preventing others from accessing the system remotely.



Example 2


In the following example a server socket connection is used to accept a request to store data on the local file system using a specified filename. The method openSocketConnection establishes a server socket to accept requests from a client. When a client establishes a connection to this service the getNextMessage method is first used to retrieve from the socket the name of the file to store the data, the openFileToWrite method will validate the filename and open a file to write to on the local file system. The getNextMessage is then used within a while loop to continuously read data from the socket and output the data to the file until there is no longer any data from the socket.

(bad code)
Example Language:
int writeDataFromSocketToFile(char *host, int port)
{

char filename[FILENAME_SIZE];
char buffer[BUFFER_SIZE];
int socket = openSocketConnection(host, port);

if (socket < 0) {
printf("Unable to open socket connection");
return(FAIL);
}
if (getNextMessage(socket, filename, FILENAME_SIZE) > 0) {
if (openFileToWrite(filename) > 0) {
while (getNextMessage(socket, buffer, BUFFER_SIZE) > 0){
if (!(writeToFile(buffer) > 0))
break;
}
}
closeFile();
}
closeSocket(socket);
}

This example creates a situation where data can be dumped to a file on the local file system without any limits on the size of the file. This could potentially exhaust file or disk resources and/or limit other clients' ability to access the service.



Example 3


In the following example, the processMessage method receives a two dimensional character array containing the message to be processed. The two-dimensional character array contains the length of the message in the first character array and the message body in the second character array. The getMessageLength method retrieves the integer value of the length from the first character array. After validating that the message length is greater than zero, the body character array pointer points to the start of the second character array of the two-dimensional character array and memory is allocated for the new body character array.

(bad code)
Example Language:

/* process message accepts a two-dimensional character array of the form [length][body] containing the message to be processed */
int processMessage(char **message)
{
char *body;

int length = getMessageLength(message[0]);

if (length > 0) {
body = &message[1][0];
processMessageBody(body);
return(SUCCESS);
}
else {
printf("Unable to process message; invalid message length");
return(FAIL);
}
}

This example creates a situation where the length of the body character array can be very large and will consume excessive memory, exhausting system resources. This can be avoided by restricting the length of the second character array with a maximum length check

Also, consider changing the type from 'int' to 'unsigned int', so that you are always guaranteed that the number is positive. This might not be possible if the protocol specifically requires allowing negative values, or if you cannot control the return value from getMessageLength(), but it could simplify the check to ensure the input is positive, and eliminate other errors such as signed-to-unsigned conversion errors (CWE-195) that may occur elsewhere in the code.

(good code)
Example Language:
unsigned int length = getMessageLength(message[0]);
if ((length > 0) && (length < MAX_LENGTH)) {...}


Example 4


In the following example, a server object creates a server socket and accepts client connections to the socket. For every client connection to the socket a separate thread object is generated using the ClientSocketThread class that handles request made by the client through the socket.

(bad code)
Example Language: Java 
public void acceptConnections() {
try {
ServerSocket serverSocket = new ServerSocket(SERVER_PORT);
int counter = 0;
boolean hasConnections = true;
while (hasConnections) {
Socket client = serverSocket.accept();
Thread t = new Thread(new ClientSocketThread(client));
t.setName(client.getInetAddress().getHostName() + ":" + counter++);
t.start();
}
serverSocket.close();


} catch (IOException ex) {...}
}

In this example there is no limit to the number of client connections and client threads that are created. Allowing an unlimited number of client connections and threads could potentially overwhelm the system and system resources.

The server should limit the number of client connections and the client threads that are created. This can be easily done by creating a thread pool object that limits the number of threads that are generated.

(good code)
Example Language: Java 
public static final int SERVER_PORT = 4444;
public static final int MAX_CONNECTIONS = 10;
...

public void acceptConnections() {
try {
ServerSocket serverSocket = new ServerSocket(SERVER_PORT);
int counter = 0;
boolean hasConnections = true;
while (hasConnections) {
hasConnections = checkForMoreConnections();
Socket client = serverSocket.accept();
Thread t = new Thread(new ClientSocketThread(client));
t.setName(client.getInetAddress().getHostName() + ":" + counter++);
ExecutorService pool = Executors.newFixedThreadPool(MAX_CONNECTIONS);
pool.execute(t);
}
serverSocket.close();


} catch (IOException ex) {...}
}


Example 5


An unnamed web site allowed a user to purchase tickets for an event. A menu option allowed the user to purchase up to 10 tickets, but the back end did not restrict the actual number of tickets that could be purchased.

Example 5 References:
[REF-667] Rafal Los. "Real-Life Example of a 'Business Logic Defect' (Screen Shots!)". 2011. <http://h30501.www3.hp.com/t5/Following-the-White-Rabbit-A/Real-Life-Example-of-a-Business-Logic-Defect-Screen-Shots/ba-p/22581>.


Example 6


Here the problem is that every time a connection is made, more memory is allocated. So if one just opened up more and more connections, eventually the machine would run out of memory.

(bad code)
Example Language:
bar connection() {
foo = malloc(1024);
return foo;
}

endConnection(bar foo) {
free(foo);
}

int main() {
while(1) {
foo=connection();
}

endConnection(foo)
}


+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
Chain: Python library does not limit the resources used to process images that specify a very large number of bands (CWE-1284), leading to excessive memory consumption (CWE-789) or an integer overflow (CWE-190).
Language interpreter does not restrict the number of temporary files being created when handling a MIME request with a large number of parts..
Driver does not use a maximum width when invoking sscanf style functions, causing stack consumption.
Large integer value for a length property in an object causes a large amount of memory allocation.
Product allows exhaustion of file descriptors when processing a large number of TCP packets.
Communication product allows memory consumption with a large number of SIP requests, which cause many sessions to be created.
Product allows attackers to cause a denial of service via a large number of directives, each of which opens a separate window.
CMS does not restrict the number of searches that can occur simultaneously, leading to resource exhaustion.
web application scanner attempts to read an excessively large file created by a user, causing process termination
Go-based workload orchestrator does not limit resource usage with unauthenticated connections, allowing a DoS by flooding the service
+ Detection Methods
Method Details

Manual Static Analysis

Manual static analysis can be useful for finding this weakness, but it might not achieve desired code coverage within limited time constraints. If denial-of-service is not considered a significant risk, or if there is strong emphasis on consequences such as code execution, then manual analysis may not focus on this weakness at all.

Fuzzing

While fuzzing is typically geared toward finding low-level implementation bugs, it can inadvertently find uncontrolled resource allocation problems. This can occur when the fuzzer generates a large number of test cases but does not restart the targeted product in between test cases. If an individual test case produces a crash, but it does not do so reliably, then an inability to limit resource allocation may be the cause.

When the allocation is directly affected by numeric inputs, then fuzzing may produce indications of this weakness.

Effectiveness: Opportunistic

Automated Dynamic Analysis

Certain automated dynamic analysis techniques may be effective in producing side effects of uncontrolled resource allocation problems, especially with resources such as processes, memory, and connections. The technique may involve generating a large number of requests to the product within a short time frame. Manual analysis is likely required to interpret the results.

Automated Static Analysis

Specialized configuration or tuning may be required to train automated tools to recognize this weakness.

Automated static analysis typically has limited utility in recognizing unlimited allocation problems, except for the missing release of program-independent system resources such as files, sockets, and processes, or unchecked arguments to memory. For system resources, automated static analysis may be able to detect circumstances in which resources are not released after they have expired, or if too much of a resource is requested at once, as can occur with memory. Automated analysis of configuration files may be able to detect settings that do not specify a maximum value.

Automated static analysis tools will not be appropriate for detecting exhaustion of custom resources, such as an intended security policy in which a bulletin board user is only allowed to make a limited number of posts per day.

+ Memberships
Section HelpThis 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 802 2010 Top 25 - Risky Resource Management
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 857 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 858 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - Serialization (SER)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 861 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 18 - Miscellaneous (MSC)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 867 2011 Top 25 - Weaknesses On the Cusp
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 876 CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOf CategoryCategory - 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 ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 985 SFP Secondary Cluster: Unrestricted Consumption
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1147 SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1148 SEI CERT Oracle Secure Coding Standard for Java - Guidelines 14. Serialization (SER)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1152 SEI CERT Oracle Secure Coding Standard for Java - Guidelines 49. Miscellaneous (MSC)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1416 Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

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

Comments

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

Relationship

This entry is different from uncontrolled resource consumption (CWE-400) in that there are other weaknesses that are related to inability to control resource consumption, such as holding on to a resource too long after use, or not correctly keeping track of active resources so that they can be managed and released when they are finished (CWE-771).

Theoretical

Vulnerability theory is largely about how behaviors and resources interact. "Resource exhaustion" can be regarded as either a consequence or an attack, depending on the perspective. This entry is an attempt to reflect one of the underlying weaknesses that enable these attacks (or consequences) to take place.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
The CERT Oracle Secure Coding Standard for Java (2011) FIO04-J Close resources when they are no longer needed
The CERT Oracle Secure Coding Standard for Java (2011) SER12-J Avoid memory and resource leaks during serialization
The CERT Oracle Secure Coding Standard for Java (2011) MSC05-J Do not exhaust heap space
ISA/IEC 62443 Part 4-2 Req CR 7.2
ISA/IEC 62443 Part 4-2 Req CR 2.7
ISA/IEC 62443 Part 4-1 Req SI-1
ISA/IEC 62443 Part 4-1 Req SI-2
ISA/IEC 62443 Part 3-3 Req SR 7.2
ISA/IEC 62443 Part 3-3 Req SR 2.7
+ References
[REF-386] Joao Antunes, Nuno Ferreira Neves and Paulo Verissimo. "Detection and Prediction of Resource-Exhaustion Vulnerabilities". Proceedings of the IEEE International Symposium on Software Reliability Engineering (ISSRE). 2008-11.
<http://homepages.di.fc.ul.pt/~nuno/PAPERS/ISSRE08.pdf>.
[REF-387] D.J. Bernstein. "Resource exhaustion".
<http://cr.yp.to/docs/resources.html>.
[REF-388] Pascal Meunier. "Resource exhaustion". Secure Programming Educational Material. 2004.
<http://homes.cerias.purdue.edu/~pmeunier/secprog/sanitized/class1/6.resource%20exhaustion.ppt>.
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 17, "Protecting Against Denial of Service Attacks" Page 517. 2nd Edition. Microsoft Press. 2002-12-04.
<https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
[REF-667] Rafal Los. "Real-Life Example of a 'Business Logic Defect' (Screen Shots!)". 2011.
<http://h30501.www3.hp.com/t5/Following-the-White-Rabbit-A/Real-Life-Example-of-a-Business-Logic-Defect-Screen-Shots/ba-p/22581>.
[REF-672] Frank Kim. "Top 25 Series - Rank 22 - Allocation of Resources Without Limits or Throttling". SANS Software Security Institute. 2010-03-23.
<https://web.archive.org/web/20170113055136/https://software-security.sans.org/blog/2010/03/23/top-25-series-rank-22-allocation-of-resources-without-limits-or-throttling/>. (URL validated: 2023-04-07)
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 10, "Resource Limits", Page 574. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission Date Submitter Organization
2009-05-13
(CWE 1.4, 2009-05-27)
CWE Content Team MITRE
+ Contributions
Contribution Date Contributor Organization
2023-11-14
(CWE 4.14, 2024-02-29)
participants in the CWE ICS/OT SIG 62443 Mapping Fall Workshop
Contributed or reviewed taxonomy mappings for ISA/IEC 62443
+ Modifications
Modification Date Modifier Organization
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Taxonomy_Mappings
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated References, Relationships
2023-01-31 CWE Content Team MITRE
updated Description, Detection_Factors
2022-10-13 CWE Content Team MITRE
updated Observed_Examples, References
2021-07-20 CWE Content Team MITRE
updated Observed_Examples
2020-12-10 CWE Content Team MITRE
updated Relationships
2020-06-25 CWE Content Team MITRE
updated Applicable_Platforms, Description, Maintenance_Notes, Potential_Mitigations, Relationship_Notes, Relationships
2020-02-24 CWE Content Team MITRE
updated Potential_Mitigations, Related_Attack_Patterns, Relationships
2019-06-20 CWE Content Team MITRE
updated Related_Attack_Patterns, Relationships
2019-01-03 CWE Content Team MITRE
updated Demonstrative_Examples, Description, Relationships, Taxonomy_Mappings
2018-03-27 CWE Content Team MITRE
updated References
2017-11-08 CWE Content Team MITRE
updated Demonstrative_Examples, Likelihood_of_Exploit, Modes_of_Introduction, Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2017-05-03 CWE Content Team MITRE
updated Related_Attack_Patterns
2015-12-07 CWE Content Team MITRE
updated Related_Attack_Patterns
2014-07-30 CWE Content Team MITRE
updated Relationships
2014-06-23 CWE Content Team MITRE
updated Related_Attack_Patterns
2014-02-18 CWE Content Team MITRE
updated Related_Attack_Patterns
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2012-05-11 CWE Content Team MITRE
updated Demonstrative_Examples, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2011-09-13 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2011-06-27 CWE Content Team MITRE
updated Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-03-29 CWE Content Team MITRE
updated Demonstrative_Examples, Detection_Factors, Relationships
2010-09-27 CWE Content Team MITRE
updated Demonstrative_Examples, Potential_Mitigations
2010-06-21 CWE Content Team MITRE
updated Common_Consequences, Potential_Mitigations, References
2010-04-05 CWE Content Team MITRE
updated Common_Consequences, Demonstrative_Examples, Related_Attack_Patterns
2010-02-16 CWE Content Team MITRE
updated Common_Consequences, Detection_Factors, Potential_Mitigations, References, Related_Attack_Patterns, Relationships
2009-12-28 CWE Content Team MITRE
updated Applicable_Platforms, Demonstrative_Examples, Detection_Factors, Observed_Examples, References, Time_of_Introduction
2009-10-29 CWE Content Team MITRE
updated Relationships
2009-07-27 CWE Content Team MITRE
updated Related_Attack_Patterns

CWE-1249: Application-Level Admin Tool with Inconsistent View of Underlying Operating System

Weakness ID: 1249
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product provides an application for administrators to manage parts of the underlying operating system, but the application does not accurately identify all of the relevant entities or resources that exist in the OS; that is, the application's model of the OS's state is inconsistent with the OS's actual state.
+ Extended Description

Many products provide web-based applications or other interfaces for managing the underlying operating system. This is common with cloud, network access devices, home networking, and other systems. When the management tool does not accurately represent what is in the OS - such as user accounts - then the administrator might not see suspicious activities that would be noticed otherwise.

For example, numerous systems utilize a web front-end for administrative control. They also offer the ability to add, alter, and drop users with various privileges as it relates to the functionality of the system. A potential architectural weakness may exist where the user information reflected in the web interface does not mirror the users in the underlying operating system. Many web UI or REST APIs use the underlying operating system for authentication; the system's logic may also track an additional set of user capabilities within configuration files and datasets for authorization capabilities. When there is a discrepancy between the user information in the UI or REST API's interface system and the underlying operating system's user listing, this may introduce a weakness into the system. For example, if an attacker compromises the OS and adds a new user account - a "ghost" account - then the attacker could escape detection if the management tool does not list the newly-added account.

This discrepancy could be exploited in several ways:

  • A rogue admin could insert a new account into a system that will persist if they are terminated or wish to take action on a system that cannot be directly associated with them.
  • An attacker can leverage a separate command injection attack available through the web interface to insert a ghost account with shell privileges such as ssh.
  • An attacker can leverage existing web interface APIs, manipulated in such a way that a new user is inserted into the operating system, and the user web account is either partially created or not at all.
  • An attacker could create an admin account which is viewable by an administrator, use this account to create the ghost account, delete logs and delete the first created admin account.

Many of these attacker scenarios can be realized by leveraging separate vulnerabilities related to XSS, command injection, authentication bypass, or logic flaws on the various systems.

+ Alternate Terms
Ghost in the Shell
+ Common Consequences
Section HelpThis 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.
Impact Details

Varies by Context

Scope: Access Control

Hide Activities

Scope: Accountability

Unexpected State

Scope: Other

+ Potential Mitigations
Phase(s) Mitigation

Architecture and Design

Ensure that the admin tool refreshes its model of the underlying OS on a regular basis, and note any inconsistencies with configuration files or other data sources that are expected to have the same data.

+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1250 Improper Preservation of Consistency Between Independent Representations of Shared State
+ Modes Of Introduction
Section HelpThe 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 The design might assume that the underlying OS does not change.
Implementation Assumptions about the underlying OS might be hard-coded into the application or otherwise in external data stores in a way that is not updated when the OS's state changes.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

Operating Systems

Class: Not OS-Specific (Undetermined Prevalence)

Technologies

Class: Web Based (Undetermined Prevalence)

+ Demonstrative Examples

Example 1


Suppose that an attacker successfully gains root privileges on a Linux system and adds a new 'user2' account:

(attack code)
Example Language: Other 
echo "user2:x:0:0::/root:/" >> /etc/passwd;
echo "user2:\$6\$IdvyrM6VJnG8Su5U\$1gmW3Nm.IO4vxTQDQ1C8urm72JCadOHZQwqiH/nRtL8dPY80xS4Ovsv5bPCMWnXKKWwmsocSWXupUf17LB3oS.:17256:0:99999:7:::" >> /etc/shadow;

This new user2 account would not be noticed on the web interface, if the interface does not refresh its data of available users.

It could be argued that for this specific example, an attacker with root privileges would be likely to compromise the admin tool or otherwise feed it with false data. However, this example shows how the discrepancy in critical data can help attackers to escape detection.



+ Memberships
Section HelpThis 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1415 Comprehensive Categorization: Resource Control
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

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

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ References
[REF-1070] Tony Martin. "Ghost in the Shell Weakness". 2020-02-13.
<https://friendsglobal.com/ghost-in-the-shell/ghost-in-the-shell-weakness/>. (URL validated: 2023-04-07)
+ Content History
+ Submissions
Submission Date Submitter Organization
2019-06-06
(CWE 4.0, 2020-02-24)
Tony Martin
+ Modifications
Modification Date Modifier Organization
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated References, Relationships
2023-01-31 CWE Content Team MITRE
updated Description
2020-06-25 CWE Content Team MITRE
updated Demonstrative_Examples

CWE-1044: Architecture with Number of Horizontal Layers Outside of Expected Range

Weakness ID: 1044
Vulnerability Mapping: PROHIBITED This CWE ID must not be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product's architecture contains too many - or too few - horizontal layers.
+ Extended Description

This issue makes it more difficult to maintain the product, which indirectly affects security by making it more difficult or time-consuming to find and/or fix vulnerabilities. It also might make it easier to introduce vulnerabilities.

While the interpretation of "expected range" may vary for each product or developer, CISQ recommends a default minimum of 4 layers and maximum of 8 layers.

+ Common Consequences
Section HelpThis 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.
Impact Details

Reduce Maintainability

Scope: Other

+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Pillar Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things. 710 Improper Adherence to Coding Standards
+ Relevant to the view "Software Development" (View-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1006 Bad Coding Practices
+ Modes Of Introduction
Section HelpThe 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
+ Weakness Ordinalities
Ordinality Description
Indirect
(where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect)
+ Memberships
Section HelpThis 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1130 CISQ Quality Measures (2016) - Maintainability
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1412 Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes
Usage PROHIBITED
(this CWE ID must not be used to map to real-world vulnerabilities)
Reason Other

Rationale

This entry is primarily a quality issue with no direct security implications.

Comments

Look for weaknesses that are focused specifically on insecure behaviors that have more direct security implications.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
OMG ASCMM ASCMM-MNT-9
+ References
[REF-960] Object Management Group (OMG). "Automated Source Code Maintainability Measure (ASCMM)". ASCMM-MNT-9. 2016-01.
<https://www.omg.org/spec/ASCMM/>. (URL validated: 2023-04-07)
+ Content History
+ Submissions
Submission Date Submitter Organization
2018-07-02
(CWE 3.2, 2019-01-03)
CWE Content Team MITRE
Entry derived from Common Quality Enumeration (CQE) Draft 0.9.
+ Modifications
Modification Date Modifier Organization
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Mapping_Notes
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated References, Relationships
2023-01-31 CWE Content Team MITRE
updated Description

CWE-405: Asymmetric Resource Consumption (Amplification)

Weakness ID: 405
Vulnerability Mapping: ALLOWED This CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product does not properly control situations in which an adversary can cause the product to consume or produce excessive resources without requiring the adversary to invest equivalent work or otherwise prove authorization, i.e., the adversary's influence is "asymmetric."
+ Extended Description
This can lead to poor performance due to "amplification" of resource consumption, typically in a non-linear fashion. This situation is worsened if the product allows malicious users or attackers to consume more resources than their access level permits.
+ Common Consequences
Section HelpThis 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.
Impact Details

DoS: Amplification; DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory); DoS: Resource Consumption (Other)

Scope: Availability

Likelihood: High

Sometimes this is a factor in "flood" attacks, but other types of amplification exist.
+ Potential Mitigations
Phase(s) Mitigation

Architecture and Design

An application must make resources available to a client commensurate with the client's access level.

Architecture and Design

An application must, at all times, keep track of allocated resources and meter their usage appropriately.

System Configuration

Consider disabling resource-intensive algorithms on the server side, such as Diffie-Hellman key exchange.

Effectiveness: High

Note: Business requirements may prevent disabling resource-intensive algorithms.
+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 400 Uncontrolled Resource Consumption
ParentOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 406 Insufficient Control of Network Message Volume (Network Amplification)
ParentOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 407 Inefficient Algorithmic Complexity
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 408 Incorrect Behavior Order: Early Amplification
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 409 Improper Handling of Highly Compressed Data (Data Amplification)
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 776 Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion')
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1050 Excessive Platform Resource Consumption within a Loop
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1072 Data Resource Access without Use of Connection Pooling
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1073 Non-SQL Invokable Control Element with Excessive Number of Data Resource Accesses
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1084 Invokable Control Element with Excessive File or Data Access Operations
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1089 Large Data Table with Excessive Number of Indices
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1094 Excessive Index Range Scan for a Data Resource
ParentOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 1176 Inefficient CPU Computation
PeerOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 404 Improper Resource Shutdown or Release
+ Modes Of Introduction
Section HelpThe 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
Operation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

Operating Systems

Class: Not OS-Specific (Undetermined Prevalence)

Architectures

Class: Not Architecture-Specific (Undetermined Prevalence)

Technologies

Class: Not Technology-Specific (Undetermined Prevalence)

Class: Client Server (Undetermined Prevalence)

+ Demonstrative Examples

Example 1


This code listens on a port for DNS requests and sends the result to the requesting address.

(bad code)
Example Language: Python 
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind( (UDP_IP,UDP_PORT) )
while true:
data = sock.recvfrom(1024)
if not data:
break

(requestIP, nameToResolve) = parseUDPpacket(data)
record = resolveName(nameToResolve)
sendResponse(requestIP,record)

This code sends a DNS record to a requesting IP address. UDP allows the source IP address to be easily changed ('spoofed'), thus allowing an attacker to redirect responses to a target, which may be then be overwhelmed by the network traffic.



Example 2


This function prints the contents of a specified file requested by a user.

(bad code)
Example Language: PHP 
function printFile($username,$filename){

//read file into string
$file = file_get_contents($filename);
if ($file && isOwnerOf($username,$filename)){
echo $file;
return true;
}
else{
echo 'You are not authorized to view this file';
}
return false;
}

This code first reads a specified file into memory, then prints the file if the user is authorized to see its contents. The read of the file into memory may be resource intensive and is unnecessary if the user is not allowed to see the file anyway.



Example 3


The DTD and the very brief XML below illustrate what is meant by an XML bomb. The ZERO entity contains one character, the letter A. The choice of entity name ZERO is being used to indicate length equivalent to that exponent on two, that is, the length of ZERO is 2^0. Similarly, ONE refers to ZERO twice, therefore the XML parser will expand ONE to a length of 2, or 2^1. Ultimately, we reach entity THIRTYTWO, which will expand to 2^32 characters in length, or 4 GB, probably consuming far more data than expected.

(attack code)
Example Language: XML 
<?xml version="1.0"?>
<!DOCTYPE MaliciousDTD [
<!ENTITY ZERO "A">
<!ENTITY ONE "&ZERO;&ZERO;">
<!ENTITY TWO "&ONE;&ONE;">
...
<!ENTITY THIRTYTWO "&THIRTYONE;&THIRTYONE;">
]>
<data>&THIRTYTWO;</data>


Example 4


This example attempts to check if an input string is a "sentence" [REF-1164].

(bad code)
Example Language: JavaScript 
var test_string = "Bad characters: $@#";
var bad_pattern = /^(\w+\s?)*$/i;
var result = test_string.search(bad_pattern);

The regular expression has a vulnerable backtracking clause inside (\w+\s?)*$ which can be triggered to cause a Denial of Service by processing particular phrases.

To fix the backtracking problem, backtracking is removed with the ?= portion of the expression which changes it to a lookahead and the \2 which prevents the backtracking. The modified example is:

(good code)
Example Language: JavaScript 
var test_string = "Bad characters: $@#";
var good_pattern = /^((?=(\w+))\2\s?)*$/i;
var result = test_string.search(good_pattern);

Note that [REF-1164] has a more thorough (and lengthy) explanation of everything going on within the RegEx.



Example 5


An adversary can cause significant resource consumption on a server by filtering the cryptographic algorithms offered by the client to the ones that are the most resource-intensive on the server side. After discovering which cryptographic algorithms are supported by the server, a malicious client can send the initial cryptographic handshake messages that contains only the resource-intensive algorithms. For some cryptographic protocols, these messages can be completely prefabricated, as the resource-intensive part of the handshake happens on the server-side first (such as TLS), rather than on the client side. In the case of cryptographic protocols where the resource-intensive part should happen on the client-side first (such as SSH), a malicious client can send a forged/precalculated computation result, which seems correct to the server, so the resource-intensive part of the handshake is going to happen on the server side. A malicious client is required to send only the initial messages of a cryptographic handshake to initiate the resource-consuming part of the cryptographic handshake. These messages are usually small, and generating them requires minimal computational effort, enabling a denial-of-service attack. An additional risk is the fact that higher key size increases the effectiveness of the attack. Cryptographic protocols where the clients have influence over the size of the used key (such as TLS 1.3 or SSH) are most at risk, as the client can enforce the highest key size supported by the server.



+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
Classic "Smurf" attack, using spoofed ICMP packets to broadcast addresses.
Parsing library allows XML bomb
Tool creates directories before authenticating user.
Python has "quadratic complexity" issue when converting string to int with many digits in unexpected bases
server allows ReDOS with crafted User-Agent strings, due to overlapping capture groups that cause excessive backtracking.
composite: NTP feature generates large responses (high amplification factor) with spoofed UDP source addresses.
Diffie-Hellman (DHE) Key Agreement Protocol allows attackers to send arbitrary numbers that are not public keys, which causes the server to perform expensive, unnecessary computation of modular exponentiation.
The Diffie-Hellman Key Agreement Protocol allows use of long exponents, which are more computationally expensive than using certain "short exponents" with particular properties.
+ Memberships
Section HelpThis 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 730 OWASP Top Ten 2004 Category A9 - Denial of Service
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 855 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 12 - Thread Pools (TPS)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 857 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 977 SFP Secondary Cluster: Design
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1145 SEI CERT Oracle Secure Coding Standard for Java - Guidelines 11. Thread Pools (TPS)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1147 SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1416 Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes
Usage ALLOWED-WITH-REVIEW
(this CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review)
Reason Abstraction

Rationale

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

Comments

Examine children of this entry to see if there is a better fit
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER Asymmetric resource consumption (amplification)
OWASP Top Ten 2004 A9 CWE More Specific Denial of Service
WASC 41 XML Attribute Blowup
The CERT Oracle Secure Coding Standard for Java (2011) TPS00-J Use thread pools to enable graceful degradation of service during traffic bursts
The CERT Oracle Secure Coding Standard for Java (2011) FIO04-J Release resources when they are no longer needed
+ References
[REF-1164] Ilya Kantor. "Catastrophic backtracking". 2020-12-13.
<https://javascript.info/regexp-catastrophic-backtracking>.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution Date Contributor Organization
2021-11-11 Szilárd Pfeiffer Balasys IT Security
Submitted content that led to modifications in applicable platforms, common consequences, potential mitigations, demonstrative examples, observed examples.
+ Modifications
Modification Date Modifier Organization
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Demonstrative_Examples
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes, Relationships
2023-04-27 CWE Content Team MITRE
updated Relationships
2023-01-31 CWE Content Team MITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Observed_Examples, Potential_Mitigations, References, Time_of_Introduction
2020-02-24 CWE Content Team MITRE
updated Relationships
2019-06-20 CWE Content Team MITRE
updated Relationships
2019-01-03 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Functional_Areas
2015-12-07 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2012-05-11 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2011-06-27 CWE Content Team MITRE
updated Common_Consequences
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2010-12-13 CWE Content Team MITRE
updated Description
2010-02-16 CWE Content Team MITRE
updated Taxonomy_Mappings
2009-07-27 CWE Content Team MITRE
updated Common_Consequences, Other_Notes
2008-10-14 CWE Content Team MITRE
updated Description
2008-09-08 CWE Content Team MITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction

CWE-289: Authentication Bypass by Alternate Name

Weakness ID: 289
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product performs authentication based on the name of a resource being accessed, or the name of the actor performing the access, but it does not properly check all possible names for that resource or actor.
+ Common Consequences
Section HelpThis 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.
Impact Details

Bypass Protection Mechanism

Scope: Access Control

+ Potential Mitigations
Phase(s) Mitigation

Architecture and Design

Strategy: Input Validation

Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.

Implementation

Strategy: Input Validation

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

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

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

Implementation

Strategy: Input Validation

Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.
+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 1390 Weak Authentication
CanFollow Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 46 Path Equivalence: 'filename ' (Trailing Space)
CanFollow Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 52 Path Equivalence: '/multiple/trailing/slash//'
CanFollow Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 173 Improper Handling of Alternate Encoding
CanFollow Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 178 Improper Handling of Case Sensitivity
+ Relevant to the view "Software Development" (View-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1211 Authentication Errors
+ Relevant to the view "Architectural Concepts" (View-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1010 Authenticate Actors
+ Modes Of Introduction
Section HelpThe 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 COMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
Implementation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
Protection mechanism that restricts URL access can be bypassed using URL encoding.
Bypass of authentication for files using "\" (backslash) or "%5C" (encoded backslash).
+ Memberships
Section HelpThis 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 845 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 2 - Input Validation and Data Sanitization (IDS)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 947 SFP Secondary Cluster: Authentication Bypass
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1134 SEI CERT Oracle Secure Coding Standard for Java - Guidelines 00. Input Validation and Data Sanitization (IDS)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1396 Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

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

Comments

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

Relationship

Overlaps equivalent encodings, canonicalization, authorization, multiple trailing slash, trailing space, mixed case, and other equivalence issues.

Theoretical

Alternate names are useful in data driven manipulation attacks, not just for authentication.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER Authentication bypass by alternate name
The CERT Oracle Secure Coding Standard for Java (2011) IDS01-J CWE More Specific Normalize strings before validating them
SEI CERT Oracle Coding Standard for Java IDS01-J CWE More Specific Normalize strings before validating them
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification Date Modifier Organization
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Relationships
2023-01-31 CWE Content Team MITRE
updated Description, Type
2022-10-13 CWE Content Team MITRE
updated Relationships
2020-06-25 CWE Content Team MITRE
updated Potential_Mitigations
2020-02-24 CWE Content Team MITRE
updated Potential_Mitigations, Relationships
2019-01-03 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2017-05-03 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2012-05-11 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-03-29 CWE Content Team MITRE
updated Potential_Mitigations
2009-07-27 CWE Content Team MITRE
updated Other_Notes, Potential_Mitigations, Theoretical_Notes
2008-11-24 CWE Content Team MITRE
updated Observed_Examples
2008-09-08 CWE Content Team MITRE
updated Description, Relationships, Other_Notes, Relationship_Notes, Taxonomy_Mappings
2008-07-01 Eric Dalci Cigital
updated Potential_Mitigations, Time_of_Introduction

CWE-302: Authentication Bypass by Assumed-Immutable Data

Weakness ID: 302
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The authentication scheme or implementation uses key data elements that are assumed to be immutable, but can be controlled or modified by the attacker.
+ Common Consequences
Section HelpThis 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.
Impact Details

Bypass Protection Mechanism

Scope: Access Control

+ Potential Mitigations
Phase(s) Mitigation

Architecture and Design; Operation; Implementation

Implement proper protection for immutable data (e.g. environment variable, hidden form fields, etc.)
+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 807 Reliance on Untrusted Inputs in a Security Decision
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 1390 Weak Authentication
+ Relevant to the view "Architectural Concepts" (View-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1010 Authenticate Actors
+ Modes Of Introduction
Section HelpThe 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 COMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
Implementation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Demonstrative Examples

Example 1


In the following example, an "authenticated" cookie is used to determine whether or not a user should be granted access to a system.

(bad code)
Example Language: Java 
boolean authenticated = new Boolean(getCookieValue("authenticated")).booleanValue();
if (authenticated) {
...
}

Modifying the value of a cookie on the client-side is trivial, but many developers assume that cookies are essentially immutable.



+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
DebPloit
Web auth
Authentication bypass by setting certain cookies to "true".
Authentication bypass by setting certain cookies to "true".
Admin access by setting a cookie.
Gain privileges by setting cookie.
Product trusts authentication information in cookie.
Authentication bypass by setting admin-testing variable to true.
Bypass auth and gain privileges by setting a variable.
+ Memberships
Section HelpThis 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 724 OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 859 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 949 SFP Secondary Cluster: Faulty Endpoint Authentication
MemberOf CategoryCategory - 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1396 Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

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

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER Authentication Bypass via Assumed-Immutable Data
OWASP Top Ten 2004 A1 CWE More Specific Unvalidated Input
The CERT Oracle Secure Coding Standard for Java (2011) SEC02-J Do not base security checks on untrusted sources
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification Date Modifier Organization
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Relationships
2023-01-31 CWE Content Team MITRE
updated Type
2022-10-13 CWE Content Team MITRE
updated Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2021-03-15 CWE Content Team MITRE
updated Demonstrative_Examples
2020-02-24 CWE Content Team MITRE
updated Relationships
2019-01-03 CWE Content Team MITRE
updated Taxonomy_Mappings
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2017-05-03 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Demonstrative_Examples, Relationships
2012-05-11 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2010-04-05 CWE Content Team MITRE
updated Related_Attack_Patterns
2010-02-16 CWE Content Team MITRE
updated Potential_Mitigations, Relationships
2009-03-10 CWE Content Team MITRE
updated Relationships
2008-10-14 CWE Content Team MITRE
updated Demonstrative_Examples, Description
2008-09-08 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
2008-07-01 Sean Eidemiller Cigital
added/updated demonstrative examples

CWE-294: Authentication Bypass by Capture-replay

Weakness ID: 294
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
A capture-replay flaw exists when the design of the product makes it possible for a malicious user to sniff network traffic and bypass authentication by replaying it to the server in question to the same effect as the original message (or with minor changes).
+ Extended Description
Capture-replay attacks are common and can be difficult to defeat without cryptography. They are a subset of network injection attacks that rely on observing previously-sent valid commands, then changing them slightly if necessary and resending the same commands to the server.
+ Common Consequences
Section HelpThis 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.
Impact Details

Gain Privileges or Assume Identity

Scope: Access Control

Messages sent with a capture-relay attack allow access to resources which are not otherwise accessible without proper authentication.
+ Potential Mitigations
Phase(s) Mitigation

Architecture and Design

Utilize some sequence or time stamping functionality along with a checksum which takes this into account in order to ensure that messages can be parsed only once.

Architecture and Design

Since any attacker who can listen to traffic can see sequence numbers, it is necessary to sign messages with some kind of cryptography to ensure that sequence numbers are not simply doctored along with content.
+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 1390 Weak Authentication
+ Relevant to the view "Software Development" (View-699)
Nature Type ID Name
MemberOf Category 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" (View-1003)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 287 Improper Authentication
+ Relevant to the view "Architectural Concepts" (View-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1010 Authenticate Actors
+ Modes Of Introduction
Section HelpThe 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 COMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Likelihood Of Exploit
High
+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
product authentication succeeds if user-provided MD5 hash matches the hash in its database; this can be subjected to replay attacks.
Chain: cleartext transmission of the MD5 hash of password (CWE-319) enables attacks against a server that is susceptible to replay (CWE-294).
+ Memberships
Section HelpThis 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 ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 956 SFP Secondary Cluster: Channel Attack
MemberOf CategoryCategory - 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1396 Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

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

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER Authentication bypass by replay
CLASP Capture-replay
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005.
<https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>. (URL validated: 2024-11-17)
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification Date Modifier Organization
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Relationships
2023-01-31 CWE Content Team MITRE
updated Description, Related_Attack_Patterns
2022-10-13 CWE Content Team MITRE
updated Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2020-08-20 CWE Content Team MITRE
updated Related_Attack_Patterns
2020-02-24 CWE Content Team MITRE
updated References, Relationships
2019-06-20 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2017-05-03 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships
2012-05-11 CWE Content Team MITRE
updated Observed_Examples, Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Demonstrative_Examples
2009-10-29 CWE Content Team MITRE
updated Observed_Examples
2009-07-27 CWE Content Team MITRE
updated Description, Other_Notes, Potential_Mitigations
2009-05-27 CWE Content Team MITRE
updated Related_Attack_Patterns
2008-09-08 CWE Content Team MITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings

CWE-288: Authentication Bypass Using an Alternate Path or Channel

Weakness ID: 288
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product requires authentication, but the product has an alternate path or channel that does not require authentication. Diagram for CWE-288
+ Common Consequences
Section HelpThis 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.
Impact Details

Bypass Protection Mechanism

Scope: Access Control

+ Potential Mitigations
Phase(s) Mitigation

Architecture and Design

Funnel all access through a single choke point to simplify how users can access a resource. For every access, perform a check to determine if the user has permissions to access the resource.
+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 306 Missing Authentication for Critical Function
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 425 Direct Request ('Forced Browsing')
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1299 Missing Protection Mechanism for Alternate Hardware Interface
PeerOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 420 Unprotected Alternate Channel
+ Relevant to the view "Architectural Concepts" (View-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1010 Authenticate Actors
+ Relevant to the view "CISQ Data Protection Measures" (View-1340)
Nature Type ID Name
ChildOf Pillar Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things. 284 Improper Access Control
+ Modes Of Introduction
Section HelpThe 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 COMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
Architecture and Design This is often seen in web applications that assume that access to a particular CGI program can only be obtained through a "front" screen, when the supporting programs are directly accessible. But this problem is not just in web apps.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Demonstrative Examples

Example 1


Register SECURE_ME is located at address 0xF00. A mirror of this register called COPY_OF_SECURE_ME is at location 0x800F00. The register SECURE_ME is protected from malicious agents and only allows access to select, while COPY_OF_SECURE_ME is not.

Access control is implemented using an allowlist (as indicated by acl_oh_allowlist). The identity of the initiator of the transaction is indicated by the one hot input, incoming_id. This is checked against the acl_oh_allowlist (which contains a list of initiators that are allowed to access the asset).

Though this example is shown in Verilog, it will apply to VHDL as well.

(informative)
Example Language: Verilog 
module foo_bar(data_out, data_in, incoming_id, address, clk, rst_n);
output [31:0] data_out;
input [31:0] data_in, incoming_id, address;
input clk, rst_n;
wire write_auth, addr_auth;
reg [31:0] data_out, acl_oh_allowlist, q;
assign write_auth = | (incoming_id & acl_oh_allowlist) ? 1 : 0;
always @*
acl_oh_allowlist <= 32'h8312;
assign addr_auth = (address == 32'hF00) ? 1: 0;
always @ (posedge clk or negedge rst_n)
if (!rst_n)
begin
q <= 32'h0;
data_out <= 32'h0;
end
else
begin
q <= (addr_auth & write_auth) ? data_in: q;
data_out <= q;
end
end
endmodule
(bad code)
Example Language: Verilog 
assign addr_auth = (address == 32'hF00) ? 1: 0;

The bugged line of code is repeated in the Bad example above. Weakness arises from the fact that the SECURE_ME register can be modified by writing to the shadow register COPY_OF_SECURE_ME, the address of COPY_OF_SECURE_ME should also be included in the check. That buggy line of code should instead be replaced as shown in the Good Code Snippet below.

(good code)
Example Language: Verilog 
assign addr_auth = (address == 32'hF00 || address == 32'h800F00) ? 1: 0;


+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
Router allows remote attackers to read system logs without authentication by directly connecting to the login screen and typing certain control characters.
Attackers with physical access to the machine may bypass the password prompt by pressing the ESC (Escape) key.
OS allows local attackers to bypass the password protection of idled sessions via the programmer's switch or CMD-PWR keyboard sequence, which brings up a debugger that the attacker can use to disable the lock.
Direct request of installation file allows attacker to create administrator accounts.
Attackers may gain additional privileges by directly requesting the web management URL.
Bypass authentication via direct request to named pipe.
User can avoid lockouts by using an API instead of the GUI to conduct brute force password guessing.
+ Memberships
Section HelpThis 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 CategoryCategory - 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 947 SFP Secondary Cluster: Authentication Bypass
MemberOf CategoryCategory - 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1364 ICS Communications: Zone Boundary Failures
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1396 Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

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

Comments

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

Relationship

overlaps Unprotected Alternate Channel
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER Authentication Bypass by Alternate Path/Channel
OWASP Top Ten 2007 A10 CWE More Specific Failure to Restrict URL Access
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution Date Contributor Organization
2024-09-29
(CWE 4.16, 2024-11-19)
Abhi Balakrishnan
Contributed usability diagram concepts used by the CWE team
+ Modifications
Modification Date Modifier Organization
2024-11-19
(CWE 4.16, 2024-11-19)
CWE Content Team MITRE
updated Description, Diagram
2023-10-26 CWE Content Team MITRE
updated Demonstrative_Examples
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes, Relationships
2023-04-27 CWE Content Team MITRE
updated Relationships
2022-10-13 CWE Content Team MITRE
updated Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2021-07-20 CWE Content Team MITRE
updated Related_Attack_Patterns
2020-12-10 CWE Content Team MITRE
updated Relationships
2020-08-20 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2017-05-03 CWE Content Team MITRE
updated Related_Attack_Patterns, Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2012-05-11 CWE Content Team MITRE
updated Observed_Examples, Related_Attack_Patterns, Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2011-03-29 CWE Content Team MITRE
updated Relationships
2008-11-24 CWE Content Team MITRE
updated Observed_Examples
2008-09-08 CWE Content Team MITRE
updated Description, Modes_of_Introduction, Name, Relationships, Observed_Example, Relationship_Notes, Taxonomy_Mappings, Type
+ Previous Entry Names
Change Date Previous Entry Name
2008-09-09 Authentication Bypass by Alternate Path/Channel

CWE-639: Authorization Bypass Through User-Controlled Key

Weakness ID: 639
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.
+ Extended Description

Retrieval of a user record occurs in the system based on some key value that is under user control. The key would typically identify a user-related record stored in the system and would be used to lookup that record for presentation to the user. It is likely that an attacker would have to be an authenticated user in the system. However, the authorization process would not properly check the data access operation to ensure that the authenticated user performing the operation has sufficient entitlements to perform the requested data access, hence bypassing any other authorization checks present in the system.

For example, attackers can look at places where user specific data is retrieved (e.g. search screens) and determine whether the key for the item being looked up is controllable externally. The key may be a hidden field in the HTML form field, might be passed as a URL parameter or as an unencrypted cookie variable, then in each of these cases it will be possible to tamper with the key value.

One manifestation of this weakness is when a system uses sequential or otherwise easily-guessable session IDs that would allow one user to easily switch to another user's session and read/modify their data.

+ Alternate Terms
Insecure Direct Object Reference / IDOR
The "Insecure Direct Object Reference" term, as described in the OWASP Top Ten, is broader than this CWE because it also covers path traversal (CWE-22). Within the context of vulnerability theory, there is a similarity between the OWASP concept and CWE-706: Use of Incorrectly-Resolved Name or Reference.
Broken Object Level Authorization / BOLA
BOLA is used in the 2019 OWASP API Security Top 10 and is said to be the same as IDOR.
Horizontal Authorization
"Horizontal Authorization" is used to describe situations in which two users have the same privilege level, but must be prevented from accessing each other's resources. This is fairly common when using key-based access to resources in a multi-user context.
+ Common Consequences
Section HelpThis 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.
Impact Details

Bypass Protection Mechanism

Scope: Access Control

Access control checks for specific user data or functionality can be bypassed.

Gain Privileges or Assume Identity

Scope: Access Control

Horizontal escalation of privilege is possible (one user can view/modify information of another user).

Gain Privileges or Assume Identity

Scope: Access Control

Vertical escalation of privilege is possible if the user-controlled key is actually a flag that indicates administrator status, allowing the attacker to gain administrative access.
+ Potential Mitigations
Phase(s) Mitigation

Architecture and Design

For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.

Architecture and Design; Implementation

Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.

Architecture and Design

Use encryption in order to make it more difficult to guess other legitimate values of the key or associate a digital signature with the key so that the server can verify that there has been no tampering.
+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 863 Incorrect Authorization
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 566 Authorization Bypass Through User-Controlled SQL Primary Key
+ Relevant to the view "Software Development" (View-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 840 Business Logic Errors
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1212 Authorization Errors
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 863 Incorrect Authorization
+ Relevant to the view "Architectural Concepts" (View-1008)
Nature Type ID Name
MemberOf Category 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" (View-1340)
Nature Type ID Name
ChildOf Pillar Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things. 284 Improper Access Control
+ Modes Of Introduction
Section HelpThe 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 REALIZATION: This weakness is caused during implementation of an architectural security tactic.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1


The following code uses a parameterized statement, which escapes metacharacters and prevents SQL injection vulnerabilities, to construct and execute a SQL query that searches for an invoice matching the specified identifier [1]. The identifier is selected from a list of all invoices associated with the current authenticated user.

(bad code)
Example Language: C# 
...
conn = new SqlConnection(_ConnectionString);
conn.Open();
int16 id = System.Convert.ToInt16(invoiceID.Text);
SqlCommand query = new SqlCommand( "SELECT * FROM invoices WHERE id = @id", conn);
query.Parameters.AddWithValue("@id", id);
SqlDataReader objReader = objCommand.ExecuteReader();
...

The problem is that the developer has not considered all of the possible values of id. Although the interface generates a list of invoice identifiers that belong to the current user, an attacker can bypass this interface to request any desired invoice. Because the code in this example does not check to ensure that the user has permission to access the requested invoice, it will display any invoice, even if it does not belong to the current user.



+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
An educational application does not appropriately restrict file IDs to a particular user. The attacker can brute-force guess IDs, indicating IDOR.
+ Detection Methods
Method Details

Automated Static Analysis

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

Effectiveness: High

+ Memberships
Section HelpThis 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 715 OWASP Top Ten 2007 Category A4 - Insecure Direct Object Reference
MemberOf CategoryCategory - 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 813 OWASP Top Ten 2010 Category A4 - Insecure Direct Object References
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 932 OWASP Top Ten 2013 Category A4 - Insecure Direct Object References
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 945 SFP Secondary Cluster: Insecure Resource Access
MemberOf CategoryCategory - 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 CategoryCategory - 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1396 Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

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

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Content History
+ Submissions
Submission Date Submitter Organization
2008-01-30
(CWE Draft 8, 2008-01-30)
Evgeny Lebanidze Cigital
+ Modifications
Modification Date Modifier Organization
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Demonstrative_Examples
2023-10-26 CWE Content Team MITRE
updated Observed_Examples
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Detection_Factors, Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2021-03-15 CWE Content Team MITRE
updated Alternate_Terms
2020-12-10 CWE Content Team MITRE
updated Relationships
2020-06-25 CWE Content Team MITRE
updated Alternate_Terms
2020-02-24 CWE Content Team MITRE
updated Relationships
2019-06-20 CWE Content Team MITRE
updated Relationships
2018-03-27 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Description, Enabling_Factors_for_Exploitation, Modes_of_Introduction, Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships
2013-07-17 CWE Content Team MITRE
updated Relationships
2013-02-21 CWE Content Team MITRE
updated Alternate_Terms, Common_Consequences
2012-05-11 CWE Content Team MITRE
updated Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Relationships
2011-03-29 CWE Content Team MITRE
updated Alternate_Terms, Applicable_Platforms, Description, Name, Potential_Mitigations, Relationships
2010-06-21 CWE Content Team MITRE
updated Relationships
2009-10-29 CWE Content Team MITRE
updated Common_Consequences
2009-05-27 CWE Content Team MITRE
updated Relationships
2009-03-10 CWE Content Team MITRE
updated Relationships
2008-10-14 CWE Content Team MITRE
updated Description
2008-09-08 CWE Content Team MITRE
updated Common_Consequences, Relationships, Type
+ Previous Entry Names
Change Date Previous Entry Name
2011-03-29 Access Control Bypass Through User-Controlled Key

CWE-439: Behavioral Change in New Version or Environment

Weakness ID: 439
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
A's behavior or functionality changes with a new version of A, or a new environment, which is not known (or manageable) by B.
+ Alternate Terms
Functional change
+ Common Consequences
Section HelpThis 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.
Impact Details

Quality Degradation; Varies by Context

Scope: Other

+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Pillar Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things. 435 Improper Interaction Between Multiple Correctly-Behaving Entities
+ Relevant to the view "Software Development" (View-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 438 Behavioral Problems
+ Modes Of Introduction
Section HelpThe 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
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
Linux kernel 2.2 and above allow promiscuous mode using a different method than previous versions, and ifconfig is not aware of the new method (alternate path property).
Product uses defunct method from another product that does not return an error code and allows detection avoidance.
chain: Code was ported from a case-sensitive Unix platform to a case-insensitive Windows platform where filetype handlers treat .jsp and .JSP as different extensions. JSP source code may be read because .JSP defaults to the filetype "text".
+ Memberships
Section HelpThis 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1001 SFP Secondary Cluster: Use of an Improper API
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1398 Comprehensive Categorization: Component Interaction
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

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

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER CHANGE Behavioral Change
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification Date Modifier Organization
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms
2014-07-30 CWE Content Team MITRE
updated Relationships
2012-05-11 CWE Content Team MITRE
updated Relationships
2011-06-27 CWE Content Team MITRE
updated Common_Consequences
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2008-11-24 CWE Content Team MITRE
updated Observed_Examples
2008-09-08 CWE Content Team MITRE
updated Relationships, Observed_Example, Taxonomy_Mappings
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
+ Previous Entry Names
Change Date Previous Entry Name
2008-04-11 Behavioral Change

CWE-300: Channel Accessible by Non-Endpoint

Weakness ID: 300
Vulnerability Mapping: DISCOURAGED This CWE ID should not be used to map to real-world vulnerabilities
Abstraction: Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product does not adequately verify the identity of actors at both ends of a communication channel, or does not adequately ensure the integrity of the channel, in a way that allows the channel to be accessed or influenced by an actor that is not an endpoint.
+ Extended Description
In order to establish secure communication between two parties, it is often important to adequately verify the identity of entities at each end of the communication channel. Inadequate or inconsistent verification may result in insufficient or incorrect identification of either communicating entity. This can have negative consequences such as misplaced trust in the entity at the other end of the channel. An attacker can leverage this by interposing between the communicating entities and masquerading as the original entity. In the absence of sufficient verification of identity, such an attacker can eavesdrop and potentially modify the communication between the original entities.
+ Alternate Terms
Adversary-in-the-Middle / AITM
Man-in-the-Middle / MITM
Person-in-the-Middle / PITM
Monkey-in-the-Middle
Monster-in-the-Middle
Manipulator-in-the-Middle
On-path attack
Interception attack
+ Common Consequences
Section HelpThis 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.
Impact Details

Read Application Data; Modify Application Data; Gain Privileges or Assume Identity

Scope: Confidentiality, Integrity, Access Control

An attacker could pose as one of the entities and read or possibly modify the communication.
+ Potential Mitigations
Phase(s) Mitigation

Implementation

Always fully authenticate both ends of any communications channel.

Architecture and Design

Adhere to the principle of complete mediation.

Implementation

A certificate binds an identity to a cryptographic key to authenticate a communicating party. Often, the certificate takes the encrypted form of the hash of the identity of the subject, the public key, and information such as time of issue or expiration using the issuer's private key. The certificate can be validated by deciphering the certificate with the issuer's public key. See also X.509 certificate signature chains and the PGP certification structure.
+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 923 Improper Restriction of Communication Channel to Intended Endpoints
PeerOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 602 Client-Side Enforcement of Server-Side Security
PeerOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 603 Use of Client-Side Authentication
+ Relevant to the view "Architectural Concepts" (View-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1011 Authorize Actors
+ Modes Of Introduction
Section HelpThe 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 REALIZATION: This weakness is caused during implementation of an architectural security tactic.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Demonstrative Examples

Example 1


In the Java snippet below, data is sent over an unencrypted channel to a remote server.

(bad code)
Example Language: Java 
Socket sock;
PrintWriter out;

try {
sock = new Socket(REMOTE_HOST, REMOTE_PORT);
out = new PrintWriter(echoSocket.getOutputStream(), true);

// Write data to remote host via socket output stream.
...
}

By eavesdropping on the communication channel or posing as the endpoint, an attacker would be able to read all of the transmitted data.



+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
chain: incorrect "goto" in Apple SSL product bypasses certificate validation, allowing Adversry-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).
+ Detection Methods
Method Details

Automated Static Analysis

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

Effectiveness: High

+ Memberships
Section HelpThis 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 859 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC)
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 956 SFP Secondary Cluster: Channel Attack
MemberOf CategoryCategory - 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1396 Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes
Usage DISCOURAGED
(this CWE ID should not be used to map to real-world vulnerabilities)
Reason Frequent Misuse

Rationale

CWE-300 is commonly misused for vulnerabilities in which the prerequisites for exploitation require the adversary to be in a privileged "in-the-middle" position.

Comments

Consider root-cause weaknesses that allow adversary-in-the-middle attacks to happen, such as CWEs involving poor integrity protection.
+ Notes

Maintenance

The summary identifies multiple distinct possibilities, suggesting that this is a category that must be broken into more specific weaknesses.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER Man-in-the-middle (MITM)
WASC 32 Routing Detour
The CERT Oracle Secure Coding Standard for Java (2011) SEC06-J Do not rely on the default automatic signature verification provided by URLClassLoader and java.util.jar
+ References
[REF-244] M. Bishop. "Computer Security: Art and Science". Addison-Wesley. 2003.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification Date Modifier Organization
2024-07-16
(CWE 4.15, 2024-07-16)
CWE Content Team MITRE
updated Alternate_Terms
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Detection_Factors, Relationships
2023-01-31 CWE Content Team MITRE
updated Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2021-07-20 CWE Content Team MITRE
updated Alternate_Terms, Observed_Examples
2021-03-15 CWE Content Team MITRE
updated Alternate_Terms, Related_Attack_Patterns
2020-12-10 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Alternate_Terms, Name, Observed_Examples, Related_Attack_Patterns, Relationships
2019-06-20 CWE Content Team MITRE
updated Related_Attack_Patterns
2019-01-03 CWE Content Team MITRE
updated Taxonomy_Mappings
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Modes_of_Introduction, Relationships
2014-07-30 CWE Content Team MITRE
updated Demonstrative_Examples, Relationships
2014-06-23 CWE Content Team MITRE
updated Observed_Examples
2014-02-18 CWE Content Team MITRE
updated Relationships
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2012-05-11 CWE Content Team MITRE
updated Common_Consequences, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2010-12-13 CWE Content Team MITRE
updated Description
2010-02-16 CWE Content Team MITRE
updated Taxonomy_Mappings
2009-05-27 CWE Content Team MITRE
updated Name
2008-09-08 CWE Content Team MITRE
updated Description, Maintenance_Notes, Relationships, Taxonomy_Mappings
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
2008-07-01 Sean Eidemiller Cigital
added/updated demonstrative examples
+ Previous Entry Names
Change Date Previous Entry Name
2008-04-11 Man-in-the-middle (MITM)
2009-05-27 Channel Accessible by Non-Endpoint (aka 'Man-in-the-Middle')
2020-02-24 Channel Accessible by Non-Endpoint ('Man-in-the-Middle')

CWE-312: Cleartext Storage of Sensitive Information

Weakness ID: 312
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product stores sensitive information in cleartext within a resource that might be accessible to another control sphere. Diagram for CWE-312
+ Common Consequences
Section HelpThis 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.
Impact Details

Read Application Data

Scope: Confidentiality

An attacker with access to the system could read sensitive information stored in cleartext (i.e., unencrypted). Even if the information is encoded in a way that is not human-readable, certain techniques could determine which encoding is being used, then decode the information.
+ Potential Mitigations
Phase(s) Mitigation

Implementation; System Configuration; Operation

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

Implementation; System Configuration; Operation

In some systems/environments such as cloud, the use of "double encryption" (at both the software and hardware layer) might be required, and the developer might be solely responsible for both layers, instead of shared responsibility with the administrator of the broader system/environment.
+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 311 Missing Encryption of Sensitive Data
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 922 Insecure Storage of Sensitive Information
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 313 Cleartext Storage in a File or on Disk
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 314 Cleartext Storage in the Registry
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 315 Cleartext Storage of Sensitive Information in a Cookie
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 316 Cleartext Storage of Sensitive Information in Memory
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 317 Cleartext Storage of Sensitive Information in GUI
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 318 Cleartext Storage of Sensitive Information in Executable
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 526 Cleartext Storage of Sensitive Information in an Environment Variable
+ Relevant to the view "Software Development" (View-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 199 Information Management Errors
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 311 Missing Encryption of Sensitive Data
+ Relevant to the view "Architectural Concepts" (View-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1013 Encrypt Data
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Class: Cloud Computing (Undetermined Prevalence)

Class: ICS/OT (Undetermined Prevalence)

Class: Mobile (Undetermined Prevalence)

+ Demonstrative Examples

Example 1


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

(bad code)
Example Language: Java 
response.addCookie( new Cookie("userAccountID", acctID);

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



Example 2


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

(bad code)
Example Language: PHP 
function persistLogin($username, $password){
$data = array("username" => $username, "password"=> $password);
setcookie ("userdata", $data);
}

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

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



Example 3


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

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

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

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



Example 4


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

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

(bad code)
Example Language: Java 

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

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

(bad code)
Example Language: ASP.NET 
...
<connectionStrings>
<add name="ud_DEV" connectionString="connectDB=uDB; uid=db2admin; pwd=password; dbalias=uDB;" providerName="System.Data.Odbc" />
</connectionStrings>
...

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



Example 5


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

At least one OT product stored a password in plaintext.



Example 6


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

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

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

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


Example 7


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

(bad code)
Example Language: Shell 
New-AzStorageEncryptionScope -ResourceGroupName "MyResourceGroup" -AccountName "MyStorageAccount" -EncryptionScopeName testscope -StorageEncryption

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

(bad code)
Example Language: Other 
ResourceGroupName: MyResourceGroup, StorageAccountName: MyStorageAccount

Name State Source RequireInfrastructureEncryption
testscope Enabled Microsoft.Storage

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

Including the -RequireInfrastructureEncryption argument addresses the issue:

(good code)
Example Language: Shell 
New-AzStorageEncryptionScope -ResourceGroupName "MyResourceGroup" -AccountName "MyStorageAccount" -EncryptionScopeName testscope -StorageEncryption -RequireInfrastructureEncryption

This produces the report:

(result)
Example Language: Other 
ResourceGroupName: MyResourceGroup, StorageAccountName: MyStorageAccount

Name State Source RequireInfrastructureEncryption
testscope Enabled Microsoft.Keyvault True

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



+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
Remote Terminal Unit (RTU) uses a driver that relies on a password stored in plaintext.
password and username stored in cleartext in a cookie
password stored in cleartext in a file with insecure permissions
chat program disables SSL in some circumstances even when the user says to use SSL.
Chain: product uses an incorrect public exponent when generating an RSA key, which effectively disables the encryption
storage of unencrypted passwords in a database
storage of unencrypted passwords in a database
product stores a password in cleartext in memory
storage of a secret key in cleartext in a temporary file
SCADA product uses HTTP Basic Authentication, which is not encrypted
login credentials stored unencrypted in a registry key
Plaintext credentials in world-readable file.
Password in cleartext in config file.
Password in cleartext in config file.
Decrypted copy of a message written to disk given a combination of options and when user replies to an encrypted message.
Plaintext storage of private key and passphrase in log file when user imports the key.
Admin password in plaintext in a cookie.
Default configuration has cleartext usernames/passwords in cookie.
Usernames/passwords in cleartext in cookies.
Authentication information stored in cleartext in a cookie.
+ Detection Methods
Method Details

Automated Static Analysis

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

Effectiveness: High

+ Memberships
Section HelpThis 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 816 OWASP Top Ten 2010 Category A7 - Insecure Cryptographic Storage
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 934 OWASP Top Ten 2013 Category A6 - Sensitive Data Exposure
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 963 SFP Secondary Cluster: Exposed Data
MemberOf CategoryCategory - 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1348 OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1366 ICS Communications: Frail Security in Protocols
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1368 ICS Dependencies (& Architecture): External Digital Systems
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1402 Comprehensive Categorization: Encryption
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

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

Comments

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

Terminology

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

Other

When organizations adopt cloud services, it can be easier for attackers to access the data from anywhere on the Internet.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER Plaintext Storage of Sensitive Information
Software Fault Patterns SFP23 Exposed Data
ISA/IEC 62443 Part 4-2 Req CR 4.1 a)
ISA/IEC 62443 Part 3-3 Req SR 4.1
+ References
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 9, "Protecting Secret Data" Page 299. 2nd Edition. Microsoft Press. 2002-12-04.
<https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 2, "Common Vulnerabilities of Encryption", Page 43. 1st Edition. Addison Wesley. 2006.
[REF-172] Chris Wysopal. "Mobile App Top 10 List". 2010-12-13.
<https://www.veracode.com/blog/2010/12/mobile-app-top-10-list>. (URL validated: 2023-04-07)
[REF-1283] Forescout Vedere Labs. "OT:ICEFALL: The legacy of "insecure by design" and its implications for certifications and risk management". 2022-06-20.
<https://www.forescout.com/resources/ot-icefall-report/>.
[REF-1295] WizCase. "Over 80 US Municipalities' Sensitive Information, Including Resident's Personal Data, Left Vulnerable in Massive Data Breach". 2021-07-20.
<https://www.wizcase.com/blog/us-municipality-breach-report/>.
[REF-1296] Jonathan Greig. "1,000 GB of local government data exposed by Massachusetts software company". 2021-07-22.
<https://www.zdnet.com/article/1000-gb-of-local-government-data-exposed-by-massachusetts-software-company/>.
[REF-1297] Amazon. "AWS Foundational Security Best Practices controls". 2022.
<https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-controls-reference.html>. (URL validated: 2023-04-07)
[REF-1299] Microsoft. "Azure encryption overview". 2022-08-18.
<https://learn.microsoft.com/en-us/azure/security/fundamentals/encryption-overview>. (URL validated: 2022-10-11)
[REF-1301] Google Cloud. "Default encryption at rest". 2022-10-11.
<https://cloud.google.com/docs/security/encryption/default-encryption>. (URL validated: 2022-10-11)
[REF-1307] Center for Internet Security. "CIS Microsoft Azure Foundations Benchmark version 1.5.0". Section 3.2. 2022-08-16.
<https://www.cisecurity.org/benchmark/azure>. (URL validated: 2023-01-19)
[REF-1310] Microsoft. "Enable infrastructure encryption for double encryption of data". 2022-07-14.
<https://learn.microsoft.com/en-us/azure/storage/common/infrastructure-encryption-enable>. (URL validated: 2023-01-24)
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution Date Contributor Organization
2023-04-25 "Mapping CWE to 62443" Sub-Working Group CWE-CAPEC ICS/OT SIG
Suggested mappings to ISA/IEC 62443.
+ Modifications
Modification Date Modifier Organization
2025-04-03
(CWE 4.17, 2025-04-03)
CWE Content Team MITRE
updated Common_Consequences, Description, Diagram, Other_Notes, Potential_Mitigations
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Taxonomy_Mappings
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes, Relationships
2023-04-27 CWE Content Team MITRE
updated Detection_Factors, References, Relationships, Taxonomy_Mappings
2023-01-31 CWE Content Team MITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, References, Relationships
2022-10-13 CWE Content Team MITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Observed_Examples, Potential_Mitigations, References
2021-10-28 CWE Content Team MITRE
updated Relationships
2021-03-15 CWE Content Team MITRE
updated Demonstrative_Examples
2020-02-24 CWE Content Team MITRE
updated Applicable_Platforms, Relationships
2019-06-20 CWE Content Team MITRE
updated Relationships, Type
2018-03-27 CWE Content Team MITRE
updated References, Relationships, Type
2018-01-23 CWE Content Team MITRE
updated Abstraction, Relationships
2017-11-08 CWE Content Team MITRE
updated Modes_of_Introduction, References, Relationships
2017-05-03 CWE Content Team MITRE
updated Related_Attack_Patterns
2014-07-30 CWE Content Team MITRE
updated Demonstrative_Examples, Relationships, Taxonomy_Mappings
2013-07-17 CWE Content Team MITRE
updated Description, Relationships, Terminology_Notes
2013-02-21 CWE Content Team MITRE
updated Applicable_Platforms, References
2012-05-11 CWE Content Team MITRE
updated Common_Consequences, Demonstrative_Examples, Observed_Examples, References, Related_Attack_Patterns, Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2010-06-21 CWE Content Team MITRE
updated Relationships
2010-02-16 CWE Content Team MITRE
updated References
2009-01-12 CWE Content Team MITRE
updated Description, Name
2008-09-08 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
+ Previous Entry Names
Change Date Previous Entry Name
2009-01-12 Plaintext Storage of Sensitive Information

CWE-319: Cleartext Transmission of Sensitive Information

Weakness ID: 319
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors. Diagram for CWE-319
+ Common Consequences
Section HelpThis 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.
Impact Details

Read Application Data; Modify Files or Directories

Scope: Integrity, Confidentiality

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

Read Application Data; Modify Files or Directories; Other

Scope: Integrity, Confidentiality

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

Architecture and Design

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

Implementation

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

Implementation

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

Testing

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

Operation

Configure servers to use encrypted channels for communication, which may include SSL or other secure protocols.
+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 311 Missing Encryption of Sensitive Data
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 5 J2EE Misconfiguration: Data Transmission Without Encryption
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 614 Sensitive Cookie in HTTPS Session Without 'Secure' Attribute
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1428 Reliance on HTTP instead of HTTPS
+ Relevant to the view "Software Development" (View-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 199 Information Management Errors
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 311 Missing Encryption of Sensitive Data
+ Relevant to the view "Architectural Concepts" (View-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1013 Encrypt Data
+ Relevant to the view "Hardware Design" (View-1194)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1207 Debug and Test Problems
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Architecture and Design For hardware, this may be introduced when design does not plan for an attacker having physical access while a legitimate user is remotely operating the device.
Operation
System Configuration
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Class: Cloud Computing (Undetermined Prevalence)

Class: Mobile (Undetermined Prevalence)

Class: ICS/OT (Often Prevalent)

Class: System on Chip (Undetermined Prevalence)

Test/Debug Hardware (Often Prevalent)

+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1


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

(bad code)
Example Language: Java 
try {
URL u = new URL("http://www.secret.example.org/");
HttpURLConnection hu = (HttpURLConnection) u.openConnection();
hu.setRequestMethod("PUT");
hu.connect();
OutputStream os = hu.getOutputStream();
hu.disconnect();
}
catch (IOException e) {
//...
}

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



Example 2


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

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



Example 3


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



Example 4


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

(informative)
Example Language: Shell 
az storage account show -g {ResourceGroupName} -n {StorageAccountName}

The JSON result might be:

(bad code)
Example Language: JSON 
{
"name": "{StorageAccountName}",
"enableHttpsTrafficOnly": false,
"type": "Microsoft.Storage/storageAccounts"
}

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

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

(good code)
Example Language: Shell 
az storage account update -g {ResourceGroupName} -n {StorageAccountName} --https-only true

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

(good code)
Example Language: JSON 
{
"name": "{StorageAccountName}",
"enableHttpsTrafficOnly": true,
"type": "Microsoft.Storage/storageAccounts"
}

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

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



+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
Programmable Logic Controller (PLC) sends sensitive information in plaintext, including passwords and session tokens.
Building Controller uses a protocol that transmits authentication credentials in plaintext.
Programmable Logic Controller (PLC) sends password in plaintext.
Passwords transmitted in cleartext.
Chain: Use of HTTPS cookie without "secure" flag causes it to be transmitted across unencrypted HTTP.
Product sends password hash in cleartext in violation of intended policy.
Remote management feature sends sensitive information including passwords in cleartext.
Backup routine sends password in cleartext in email.
Product transmits Blowfish encryption key in cleartext.
Printer sends configuration information, including administrative password, in cleartext.
Chain: cleartext transmission of the MD5 hash of password enables attacks against a server that is susceptible to replay (CWE-294).
Product sends passwords in cleartext to a log server.
Product sends file with cleartext passwords in e-mail message intended for diagnostic purposes.
+ Detection Methods
Method Details

Black Box

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

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

Automated Static Analysis

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

Effectiveness: High

+ Memberships
Section HelpThis 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 751 2009 Top 25 - Insecure Interaction Between Components
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 818 OWASP Top Ten 2010 Category A9 - Insufficient Transport Layer Protection
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 858 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - Serialization (SER)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 859 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC)
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 934 OWASP Top Ten 2013 Category A6 - Sensitive Data Exposure
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 963 SFP Secondary Cluster: Exposed Data
MemberOf CategoryCategory - 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1148 SEI CERT Oracle Secure Coding Standard for Java - Guidelines 14. Serialization (SER)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1346 OWASP Top Ten 2021 Category A02:2021 - Cryptographic Failures
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1366 ICS Communications: Frail Security in Protocols
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1402 Comprehensive Categorization: Encryption
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

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

Comments

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

Other

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

Maintenance

The Taxonomy_Mappings to ISA/IEC 62443 were added in CWE 4.10, but they are still under review and might change in future CWE versions. These draft mappings were performed by members of the "Mapping CWE to 62443" subgroup of the CWE-CAPEC ICS/OT Special Interest Group (SIG), and their work is incomplete as of CWE 4.10. The mappings are included to facilitate discussion and review by the broader ICS/OT community, and they are likely to change in future CWE versions.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER Plaintext Transmission of Sensitive Information
The CERT Oracle Secure Coding Standard for Java (2011) SEC06-J Do not rely on the default automatic signature verification provided by URLClassLoader and java.util.jar
The CERT Oracle Secure Coding Standard for Java (2011) SER02-J Sign then seal sensitive objects before sending them outside a trust boundary
Software Fault Patterns SFP23 Exposed Data
ISA/IEC 62443 Part 3-3 Req SR 4.1
ISA/IEC 62443 Part 4-2 Req CR 4.1B
+ References
[REF-271] OWASP. "Top 10 2007-Insecure Communications". 2007.
<http://www.owasp.org/index.php/Top_10_2007-A9>.
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 9, "Protecting Secret Data" Page 299. 2nd Edition. Microsoft Press. 2002-12-04.
<https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 22: Failing to Protect Network Traffic." Page 337. McGraw-Hill. 2010.
[REF-172] Chris Wysopal. "Mobile App Top 10 List". 2010-12-13.
<https://www.veracode.com/blog/2010/12/mobile-app-top-10-list>. (URL validated: 2023-04-07)
[REF-1283] Forescout Vedere Labs. "OT:ICEFALL: The legacy of "insecure by design" and its implications for certifications and risk management". 2022-06-20.
<https://www.forescout.com/resources/ot-icefall-report/>.
[REF-1307] Center for Internet Security. "CIS Microsoft Azure Foundations Benchmark version 1.5.0". Sections 3.1 and 3.10. 2022-08-16.
<https://www.cisecurity.org/benchmark/azure>. (URL validated: 2023-01-19)
[REF-1309] Microsoft. "Require secure transfer to ensure secure connections". 2022-07-24.
<https://learn.microsoft.com/en-us/azure/storage/common/storage-require-secure-transfer>. (URL validated: 2023-01-24)
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution Date Contributor Organization
2023-01-24 Accellera IP Security Assurance (IPSA) Working Group Accellera Systems Initiative
Submitted original contents of CWE-1324 and reviewed its integration into this entry.
+ Modifications
Modification Date Modifier Organization
2025-04-03
(CWE 4.17, 2025-04-03)
CWE Content Team MITRE
updated Common_Consequences, Description, Diagram, Other_Notes, Relationships
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Demonstrative_Examples
2023-06-29 CWE Content Team MITRE
updated Description, Mapping_Notes, Relationships
2023-04-27 CWE Content Team MITRE
updated Detection_Factors, References, Relationships
2023-01-31 CWE Content Team MITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Maintenance_Notes, Modes_of_Introduction, Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2022-10-13 CWE Content Team MITRE
updated Applicable_Platforms, Demonstrative_Examples, Observed_Examples, References
2022-06-28 CWE Content Team MITRE
updated Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Applicable_Platforms, Related_Attack_Patterns, Relationships
2019-06-20 CWE Content Team MITRE
updated Relationships, Type
2019-01-03 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2018-03-27 CWE Content Team MITRE
updated References, Relationships, Type
2018-01-23 CWE Content Team MITRE
updated Abstraction
2017-11-08 CWE Content Team MITRE
updated Likelihood_of_Exploit, Modes_of_Introduction, References, Relationships
2017-05-03 CWE Content Team MITRE
updated Related_Attack_Patterns
2014-07-30 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2014-06-23 CWE Content Team MITRE
updated Relationships
2014-02-18 CWE Content Team MITRE
updated Related_Attack_Patterns
2013-07-17 CWE Content Team MITRE
updated Relationships
2013-02-21 CWE Content Team MITRE
updated Applicable_Platforms, References
2012-05-11 CWE Content Team MITRE
updated Demonstrative_Examples, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-03-29 CWE Content Team MITRE
updated Potential_Mitigations
2010-12-13 CWE Content Team MITRE
updated Observed_Examples, Related_Attack_Patterns
2010-06-21 CWE Content Team MITRE
updated Detection_Factors, Relationships
2010-04-05 CWE Content Team MITRE
updated Applicable_Platforms, Common_Consequences, Time_of_Introduction
2010-02-16 CWE Content Team MITRE
updated References
2009-05-27 CWE Content Team MITRE
updated Related_Attack_Patterns
2009-03-10 CWE Content Team MITRE
updated Potential_Mitigations
2009-01-12 CWE Content Team MITRE
updated Common_Consequences, Description, Likelihood_of_Exploit, Name, Observed_Examples, Potential_Mitigations, References, Relationships
2008-09-08 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
+ Previous Entry Names
Change Date Previous Entry Name
2009-01-12 Plaintext Transmission of Sensitive Information

CWE-602: Client-Side Enforcement of Server-Side Security

Weakness ID: 602
Vulnerability Mapping: ALLOWED This CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product is composed of a server that relies on the client to implement a mechanism that is intended to protect the server.
+ Extended Description
When the server relies on protection mechanisms placed on the client side, an attacker can modify the client-side behavior to bypass the protection mechanisms, resulting in potentially unexpected interactions between the client and server. The consequences will vary, depending on what the mechanisms are trying to protect.
+ Common Consequences
Section HelpThis 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.
Impact Details

Bypass Protection Mechanism; DoS: Crash, Exit, or Restart

Scope: Access Control, Availability

Client-side validation checks can be easily bypassed, allowing malformed or unexpected input to pass into the application, potentially as trusted data. This may lead to unexpected states, behaviors and possibly a resulting crash.

Bypass Protection Mechanism; Gain Privileges or Assume Identity

Scope: Access Control

Client-side checks for authentication can be easily bypassed, allowing clients to escalate their access levels and perform unintended actions.
+ Potential Mitigations
Phase(s) Mitigation

Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Even though client-side checks provide minimal benefits with respect to server-side security, they are still useful. First, they can support intrusion detection. If the server receives input that should have been rejected by the client, then it may be an indication of an attack. Second, client-side error-checking can provide helpful feedback to the user about the expectations for valid input. Third, there may be a reduction in server-side processing time for accidental input errors, although this is typically a small savings.

Architecture and Design

If some degree of trust is required between the two entities, then use integrity checking and strong authentication to ensure that the inputs are coming from a trusted source. Design the product so that this trust is managed in a centralized fashion, especially if there are complex or numerous communication channels, in order to reduce the risks that the implementer will mistakenly omit a check in a single code path.

Testing

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

Testing

Use tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.
+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Pillar Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things. 693 Protection Mechanism Failure
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 565 Reliance on Cookies without Validation and Integrity Checking
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 603 Use of Client-Side Authentication
PeerOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 290 Authentication Bypass by Spoofing
PeerOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 300 Channel Accessible by Non-Endpoint
PeerOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 836 Use of Password Hash Instead of Password for Authentication
CanPrecede Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 471 Modification of Assumed-Immutable Data (MAID)
+ Relevant to the view "Architectural Concepts" (View-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1012 Cross Cutting
+ Modes Of Introduction
Section HelpThe 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 COMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
Architecture and Design Consider a product that consists of two or more processes or nodes that must interact closely, such as a client/server model. If the product uses protection schemes in the client in order to defend from attacks against the server, and the server does not use the same schemes, then an attacker could modify the client in a way that bypasses those schemes. This is a fundamental design flaw that is primary to many weaknesses.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Class: ICS/OT (Undetermined Prevalence)

Class: Mobile (Undetermined Prevalence)

+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1


This example contains client-side code that checks if the user authenticated successfully before sending a command. The server-side code performs the authentication in one step, and executes the command in a separate step.

CLIENT-SIDE (client.pl)

(good code)
Example Language: Perl 
$server = "server.example.com";
$username = AskForUserName();
$password = AskForPassword();
$address = AskForAddress();
$sock = OpenSocket($server, 1234);
writeSocket($sock, "AUTH $username $password\n");
$resp = readSocket($sock);
if ($resp eq "success") {

# username/pass is valid, go ahead and update the info!
writeSocket($sock, "CHANGE-ADDRESS $username $address\n";
}
else {
print "ERROR: Invalid Authentication!\n";
}

SERVER-SIDE (server.pl):

(bad code)
Example Language: Perl 
$sock = acceptSocket(1234);
($cmd, $args) = ParseClientRequest($sock);
if ($cmd eq "AUTH") {
($username, $pass) = split(/\s+/, $args, 2);
$result = AuthenticateUser($username, $pass);
writeSocket($sock, "$result\n");
# does not close the socket on failure; assumes the

# user will try again
}
elsif ($cmd eq "CHANGE-ADDRESS") {
if (validateAddress($args)) {
$res = UpdateDatabaseRecord($username, "address", $args);
writeSocket($sock, "SUCCESS\n");
}
else {
writeSocket($sock, "FAILURE -- address is malformed\n");
}
}

The server accepts 2 commands, "AUTH" which authenticates the user, and "CHANGE-ADDRESS" which updates the address field for the username. The client performs the authentication and only sends a CHANGE-ADDRESS for that user if the authentication succeeds. Because the client has already performed the authentication, the server assumes that the username in the CHANGE-ADDRESS is the same as the authenticated user. An attacker could modify the client by removing the code that sends the "AUTH" command and simply executing the CHANGE-ADDRESS.



Example 2


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

Multiple vendors used client-side authentication in their OT products.



+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
SCADA system only uses client-side authentication, allowing adversaries to impersonate other users.
ASP program allows upload of .asp files by bypassing client-side checks.
steganography products embed password information in the carrier file, which can be extracted from a modified client.
steganography products embed password information in the carrier file, which can be extracted from a modified client.
client allows server to modify client's configuration and overwrite arbitrary files.
+ Weakness Ordinalities
Ordinality Description
Primary
(where the weakness exists independent of other weaknesses)
+ Memberships
Section HelpThis 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 722 OWASP Top Ten 2004 Category A1 - Unvalidated Input
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 753 2009 Top 25 - Porous Defenses
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 975 SFP Secondary Cluster: Architecture
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1348 OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1413 Comprehensive Categorization: Protection Mechanism Failure
+ Vulnerability Mapping Notes
Usage ALLOWED-WITH-REVIEW
(this CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review)
Reason Abstraction

Rationale

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

Comments

Examine children of this entry to see if there is a better fit
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
OWASP Top Ten 2004 A1 CWE More Specific Unvalidated Input
+ References
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 23, "Client-Side Security Is an Oxymoron" Page 687. 2nd Edition. Microsoft Press. 2002-12-04.
<https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
[REF-1283] Forescout Vedere Labs. "OT:ICEFALL: The legacy of "insecure by design" and its implications for certifications and risk management". 2022-06-20.
<https://www.forescout.com/resources/ot-icefall-report/>.
+ Content History
+ Submissions
Submission Date Submitter Organization
2007-05-07
(CWE Draft 6, 2007-05-07)
CWE Community
Submitted by members of the CWE community to extend early CWE versions
+ Modifications
Modification Date Modifier Organization
2025-04-03
(CWE 4.17, 2025-04-03)
CWE Content Team MITRE
updated Demonstrative_Examples
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Relationships
2023-01-31 CWE Content Team MITRE
updated Applicable_Platforms, Relationships, Type
2022-10-13 CWE Content Team MITRE
updated Demonstrative_Examples, Description, Observed_Examples, References, Relationships
2022-04-28 CWE Content Team MITRE
updated Research_Gaps
2021-10-28 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Applicable_Platforms, Relationships
2019-06-20 CWE Content Team MITRE
updated Related_Attack_Patterns
2018-03-27 CWE Content Team MITRE
updated References
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Enabling_Factors_for_Exploitation, Modes_of_Introduction, References, Relationships
2017-05-03 CWE Content Team MITRE
updated Related_Attack_Patterns
2014-07-30 CWE Content Team MITRE
updated Relationships
2012-05-11 CWE Content Team MITRE
updated Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2011-03-29 CWE Content Team MITRE
updated Relationships
2010-12-13 CWE Content Team MITRE
updated Related_Attack_Patterns
2010-04-05 CWE Content Team MITRE
updated Related_Attack_Patterns
2010-02-16 CWE Content Team MITRE
updated References
2009-10-29 CWE Content Team MITRE
updated Applicable_Platforms, Common_Consequences, Description
2009-07-27 CWE Content Team MITRE
updated Related_Attack_Patterns, Relationships
2009-05-27 CWE Content Team MITRE
updated Demonstrative_Examples
2009-03-10 CWE Content Team MITRE
updated Potential_Mitigations
2009-01-12 CWE Content Team MITRE
updated Demonstrative_Examples, Description, Likelihood_of_Exploit, Name, Observed_Examples, Other_Notes, Potential_Mitigations, Relationships, Research_Gaps, Time_of_Introduction
2008-09-08 CWE Content Team MITRE
updated Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
+ Previous Entry Names
Change Date Previous Entry Name
2008-04-11 Client-Side Enforcement of Server-Side Security
2009-01-12 Design Principle Violation: Client-Side Enforcement of Server-Side Security

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

Weakness ID: 362
Vulnerability Mapping: ALLOWED This CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently. Diagram for CWE-362
+ Extended Description

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

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

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

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

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

+ Alternate Terms
Race Condition
+ Common Consequences
Section HelpThis 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.
Impact Details

DoS: Resource Consumption (CPU); DoS: Resource Consumption (Memory); DoS: Resource Consumption (Other)

Scope: Availability

When a race condition makes it possible to bypass a resource cleanup routine or trigger multiple initialization routines, it may lead to resource exhaustion.

DoS: Crash, Exit, or Restart; DoS: Instability

Scope: Availability

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.

Read Files or Directories; Read Application Data

Scope: Confidentiality, Integrity

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

Execute Unauthorized Code or Commands; Gain Privileges or Assume Identity; Bypass Protection Mechanism

Scope: Access Control

This can have security implications when the expected synchronization is in security-critical code, such as recording whether a user is authenticated or modifying important state information that should not be influenced by an outsider.
+ Potential Mitigations
Phase(s) Mitigation

Architecture and Design

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

Architecture and Design

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

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

Implementation

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

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.

Implementation

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

Implementation

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

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.

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.

Architecture and Design; Operation

Strategy: Environment Hardening

Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Pillar Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things. 691 Insufficient Control Flow Management
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 364 Signal Handler Race Condition
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 366 Race Condition within a Thread
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 367 Time-of-check Time-of-use (TOCTOU) Race Condition
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 368 Context Switching Race Condition
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 421 Race Condition During Access to Alternate Channel
ParentOf Composite 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 Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 662 Improper Synchronization
CanPrecede Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 416 Use After Free
CanPrecede Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 476 NULL Pointer Dereference
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Nature Type ID Name
MemberOf View View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1003 Weaknesses for Simplified Mapping of Published Vulnerabilities
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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
Section HelpThe 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 Programmers may assume that certain code sequences execute too quickly to be affected by an interfering code sequence; when they are not, this violates atomicity. For example, the single "x++" statement may appear atomic at the code layer, but it is actually non-atomic at the instruction layer, since it involves a read (the original value of x), followed by a computation (x+1), followed by a write (save the result to x).
+ Applicable Platforms
Section HelpThis 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)

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



+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
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.
Chain: improper locking (CWE-667) leads to race condition (CWE-362), as exploited in the wild per CISA KEV.
Chain: mobile platform race condition (CWE-362) leading to use-after-free (CWE-416), as exploited in the wild per CISA KEV.
Chain: race condition (CWE-362) leads to use-after-free (CWE-416), as exploited in the wild per CISA KEV.
chain: JTAG interface is not disabled (CWE-1191) during ROM code execution, introducing a race condition (CWE-362) to extract encryption keys
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.
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
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].
Race condition leading to a crash by calling a hook removal procedure while other activities are occurring at the same time.
chain: time-of-check time-of-use (TOCTOU) race condition in program allows bypass of protection mechanism that was designed to prevent symlink attacks.
chain: time-of-check time-of-use (TOCTOU) race condition in program allows bypass of protection mechanism that was designed to prevent symlink attacks.
Unsynchronized caching operation enables a race condition that causes messages to be sent to a deallocated object.
Race condition during initialization triggers a buffer overflow.
Daemon crash by quickly performing operations and undoing them, which eventually leads to an operation that does not acquire a lock.
chain: race condition triggers NULL pointer dereference
Race condition in library function could cause data to be sent to the wrong process.
Race condition in file parser leads to heap corruption.
chain: race condition allows attacker to access an object while it is still being initialized, causing software to access uninitialized memory.
chain: race condition for an argument value, possibly resulting in NULL dereference
chain: race condition might allow resource to be released before operating on it, leading to NULL dereference
Chain: Signal handler contains too much functionality (CWE-828), introducing a race condition (CWE-362) that leads to a double free (CWE-415).
+ Detection Methods
Method Details

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

+ Affected Resources
  • File or Directory
+ Memberships
Section HelpThis 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 ViewView - 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 CategoryCategory - 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 751 2009 Top 25 - Insecure Interaction Between Components
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 801 2010 Top 25 - Insecure Interaction Between Components
MemberOf CategoryCategory - 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 867 2011 Top 25 - Weaknesses On the Cusp
MemberOf CategoryCategory - 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 CategoryCategory - 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 988 SFP Secondary Cluster: Race Condition Window
MemberOf CategoryCategory - 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1364 ICS Communications: Zone Boundary Failures
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1365 ICS Communications: Unreliability
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1366 ICS Communications: Frail Security in Protocols
MemberOf CategoryCategory - 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 ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1387 Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1401 Comprehensive Categorization: Concurrency
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1425 Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses
+ Vulnerability Mapping Notes
Usage ALLOWED-WITH-REVIEW
(this CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review)
Reason Abstraction

Rationale

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

Comments

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

Research Gap

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

Research Gap

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

Research Gap

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

Maintenance

The relationship between race conditions and synchronization problems (CWE-662) needs to be further developed. They are not necessarily two perspectives of the same core concept, since synchronization is only one technique for avoiding race conditions, and synchronization can be used for other purposes besides race condition prevention.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER Race Conditions
The CERT Oracle Secure Coding Standard for Java (2011) VNA03-J Do not assume that a group of calls to independently atomic methods is atomic
+ References
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 13: Race Conditions." Page 205. McGraw-Hill. 2010.
[REF-349] Andrei Alexandrescu. "volatile - Multithreaded Programmer's Best Friend". Dr. Dobb's. 2008-02-01.
<https://drdobbs.com/cpp/volatile-the-multithreaded-programmers-b/184403766>. (URL validated: 2023-04-07)
[REF-350] Steven Devijver. "Thread-safe webapps using Spring".
<https://web.archive.org/web/20170609174845/http://www.javalobby.org/articles/thread-safe/index.jsp>. (URL validated: 2023-04-07)
[REF-351] David Wheeler. "Prevent race conditions". 2007-10-04.
<https://www.ida.liu.se/~TDDC90/literature/papers/SP-race-conditions.pdf>. (URL validated: 2023-04-07)
[REF-352] Matt Bishop. "Race Conditions, Files, and Security Flaws; or the Tortoise and the Hare Redux". 1995-09.
<https://seclab.cs.ucdavis.edu/projects/vulnerabilities/scriv/ucd-ecs-95-08.pdf>. (URL validated: 2023-04-07)
[REF-353] David Wheeler. "Secure Programming for Linux and Unix HOWTO". 2003-03-03.
<https://dwheeler.com/secure-programs/Secure-Programs-HOWTO/avoid-race.html>. (URL validated: 2023-04-07)
[REF-354] Blake Watts. "Discovering and Exploiting Named Pipe Security Flaws for Fun and Profit". 2002-04.
<https://www.blakewatts.com/blog/discovering-and-exploiting-named-pipe-security-flaws-for-fun-and-profit>. (URL validated: 2023-04-07)
[REF-355] Roberto Paleari, Davide Marrone, Danilo Bruschi and Mattia Monga. "On Race Vulnerabilities in Web Applications".
<http://security.dico.unimi.it/~roberto/pubs/dimva08-web.pdf>.
[REF-356] "Avoiding Race Conditions and Insecure File Operations". Apple Developer Connection.
<https://web.archive.org/web/20081010155022/http://developer.apple.com/documentation/Security/Conceptual/SecureCodingGuide/Articles/RaceConditions.html>. (URL validated: 2023-04-07)
[REF-357] Johannes Ullrich. "Top 25 Series - Rank 25 - Race Conditions". SANS Software Security Institute. 2010-03-26.
<https://web.archive.org/web/20100530231203/http://blogs.sans.org:80/appsecstreetfighter/2010/03/26/top-25-series-rank-25-race-conditions/>. (URL validated: 2023-04-07)
[REF-76] Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14.
<https://web.archive.org/web/20211209014121/https://www.cisa.gov/uscert/bsi/articles/knowledge/principles/least-privilege>. (URL validated: 2023-04-07)
[REF-1237] CERT Coordination Center. "Intel BIOS locking mechanism contains race condition that enables write protection bypass". 2015-01-05.
<https://www.kb.cert.org/vuls/id/766164/>.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution Date Contributor Organization
2010-04-30 Martin Sebor Cisco Systems, Inc.
Provided Demonstrative Example
2024-02-29
(CWE 4.16, 2024-11-19)
Abhi Balakrishnan
Provided diagram to improve CWE usability
+ Modifications
Modification Date Modifier Organization
2025-04-03
(CWE 4.17, 2025-04-03)
CWE Content Team MITRE
updated Affected_Resources
2024-11-19
(CWE 4.16, 2024-11-19)
CWE Content Team MITRE
updated Alternate_Terms, Common_Consequences, Description, Diagram, Modes_of_Introduction
2024-07-16
(CWE 4.15, 2024-07-16)
CWE Content Team MITRE
updated Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes, Relationships
2023-04-27 CWE Content Team MITRE
updated References, Relationships
2023-01-31 CWE Content Team MITRE
updated Applicable_Platforms, Common_Consequences, Description
2022-10-13 CWE Content Team MITRE
updated Observed_Examples, References
2022-06-28 CWE Content Team MITRE
updated Observed_Examples, Relationships
2022-04-28 CWE Content Team MITRE
updated Observed_Examples, Relationships
2021-10-28 CWE Content Team MITRE
updated Observed_Examples, References
2021-03-15 CWE Content Team MITRE
updated Demonstrative_Examples
2020-08-20 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Applicable_Platforms, Demonstrative_Examples, Observed_Examples, Relationships
2019-06-20 CWE Content Team MITRE
updated Relationships
2019-01-03 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2017-11-08 CWE Content Team MITRE
updated Demonstrative_Examples, References, Research_Gaps, Taxonomy_Mappings
2015-12-07 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Detection_Factors, Relationships
2012-05-11 CWE Content Team MITRE
updated Potential_Mitigations, References, Relationships
2011-09-13 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2011-06-27 CWE Content Team MITRE
updated Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2010-12-13 CWE Content Team MITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Name, Potential_Mitigations, Relationships
2010-09-27 CWE Content Team MITRE
updated Observed_Examples, Potential_Mitigations, Relationships
2010-06-21 CWE Content Team MITRE
updated Common_Consequences, Demonstrative_Examples, Detection_Factors, Potential_Mitigations, References
2010-02-16 CWE Content Team MITRE
updated Detection_Factors, References, Relationships
2009-05-27 CWE Content Team MITRE
updated Relationships
2009-03-10 CWE Content Team MITRE
updated Demonstrative_Examples, Potential_Mitigations
2009-01-12 CWE Content Team MITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Likelihood_of_Exploit, Maintenance_Notes, Observed_Examples, Potential_Mitigations, References, Relationships, Research_Gaps
2008-11-24 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2008-10-14 CWE Content Team MITRE
updated Relationships
2008-09-08 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
+ Previous Entry Names
Change Date Previous Entry Name
2008-04-11 Race Conditions
2010-12-13 Race Condition

CWE-368: Context Switching Race Condition

Weakness ID: 368
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
A product performs a series of non-atomic actions to switch between contexts that cross privilege or other security boundaries, but a race condition allows an attacker to modify or misrepresent the product's behavior during the switch.
+ Extended Description
This is commonly seen in web browser vulnerabilities in which the attacker can perform certain actions while the browser is transitioning from a trusted to an untrusted domain, or vice versa, and the browser performs the actions on one domain using the trust level and resources of the other domain.
+ Common Consequences
Section HelpThis 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.
Impact Details

Modify Application Data; Read Application Data

Scope: Integrity, Confidentiality

+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 362 Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
CanAlsoBe Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 364 Signal Handler Race Condition
+ Relevant to the view "Software Development" (View-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 557 Concurrency Issues
+ Modes Of Introduction
Section HelpThe 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
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
Chain: race condition (CWE-362) from improper handling of a page transition in web client while an applet is loading (CWE-368) leads to use after free (CWE-416)
Browser updates address bar as soon as user clicks on a link instead of when the page has loaded, allowing spoofing by redirecting to another page using onUnload method. ** this is one example of the role of "hooks" and context switches, and should be captured somehow - also a race condition of sorts **
XSS when web browser executes Javascript events in the context of a new page while it's being loaded, allowing interaction with previous page in different domain.
Web browser fills in address bar of clicked-on link before page has been loaded, and doesn't update afterward.
+ Weakness Ordinalities
Ordinality Description
Primary
(where the weakness exists independent of other weaknesses)
This weakness can be primary to almost anything, depending on the context of the race condition.
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
This weakness can be resultant from insufficient compartmentalization (CWE-653), incorrect locking, improper initialization or shutdown, or a number of other weaknesses.
+ Memberships
Section HelpThis 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 986 SFP Secondary Cluster: Missing Lock
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1401 Comprehensive Categorization: Concurrency
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

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

Comments

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

Relationship

Can overlap signal handler race conditions.

Research Gap

Under-studied as a concept. Frequency unknown; few vulnerability reports give enough detail to know when a context switching race condition is a factor.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER Context Switching Race Condition
+ 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.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification Date Modifier Organization
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms
2014-07-30 CWE Content Team MITRE
updated Relationships
2012-05-11 CWE Content Team MITRE
updated References, Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2010-12-13 CWE Content Team MITRE
updated Observed_Examples
2009-07-27 CWE Content Team MITRE
updated Description, Other_Notes, Relationship_Notes, Weakness_Ordinalities
2008-09-08 CWE Content Team MITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction

CWE-385: Covert Timing Channel

Weakness ID: 385
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
Covert timing channels convey information by modulating some aspect of system behavior over time, so that the program receiving the information can observe system behavior and infer protected information.
+ Extended Description

In some instances, knowing when data is transmitted between parties can provide a malicious user with privileged information. Also, externally monitoring the timing of operations can potentially reveal sensitive data. For example, a cryptographic operation can expose its internal state if the time it takes to perform the operation varies, based on the state.

Covert channels are frequently classified as either storage or timing channels. Some examples of covert timing channels are the system's paging rate, the time a certain transaction requires to execute, and the time it takes to gain access to a shared bus.

+ Common Consequences
Section HelpThis 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.
Impact Details

Read Application Data; Other

Scope: Confidentiality, Other

Information exposure.
+ Potential Mitigations
Phase(s) Mitigation

Architecture and Design

Whenever possible, specify implementation strategies that do not introduce time variances in operations.

Implementation

Often one can artificially manipulate the time which operations take or -- when operations occur -- can remove information from the attacker.

Implementation

It is reasonable to add artificial or random delays so that the amount of CPU time consumed is independent of the action being taken by the application.
+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 514 Covert Channel
CanFollow Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 208 Observable Timing Discrepancy
+ Relevant to the view "Software Development" (View-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 417 Communication Channel Errors
+ Modes Of Introduction
Section HelpThe 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
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1


In this example, the attacker observes how long an authentication takes when the user types in the correct password.

When the attacker tries their own values, they can first try strings of various length. When they find a string of the right length, the computation will take a bit longer, because the for loop will run at least once. Additionally, with this code, the attacker can possibly learn one character of the password at a time, because when they guess the first character right, the computation will take longer than a wrong guesses. Such an attack can break even the most sophisticated password with a few hundred guesses.

(bad code)
Example Language: Python 
def validate_password(actual_pw, typed_pw):
if len(actual_pw) <> len(typed_pw):
return 0

for i in len(actual_pw):
if actual_pw[i] <> typed_pw[i]:
return 0

return 1

Note that in this example, the actual password must be handled in constant time as far as the attacker is concerned, even if the actual password is of an unusual length. This is one reason why it is good to use an algorithm that, among other things, stores a seeded cryptographic one-way hash of the password, then compare the hashes, which will always be of the same length.



+ Memberships
Section HelpThis 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 968 SFP Secondary Cluster: Covert Channel
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1415 Comprehensive Categorization: Resource Control
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

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

Comments

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

Maintenance

As of CWE 4.9, members of the CWE Hardware SIG are working to improve CWE's coverage of transient execution weaknesses, which include issues related to Spectre, Meltdown, and other attacks that create or exploit covert channels. As a result of that work, this entry might change in CWE 4.10.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
Landwehr Timing
CLASP Covert Timing Channel
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005.
<https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>. (URL validated: 2024-11-17)
[REF-1431] Carl E. Landwehr, Alan R. Bull, John P. McDermott and William S. Choi. "A Taxonomy of Computer Program Security Flaws, with Examples". 1993-11-19.
<https://cwe.mitre.org/documents/sources/ATaxonomyofComputerProgramSecurityFlawswithExamples%5BLandwehr93%5D.pdf>. (URL validated: 2024-11-17)
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
Landwehr
+ Modifications
Modification Date Modifier Organization
2024-07-16
(CWE 4.15, 2024-07-16)
CWE Content Team MITRE
updated References
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Demonstrative_Examples
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Relationships
2022-10-13 CWE Content Team MITRE
updated Maintenance_Notes
2020-02-24 CWE Content Team MITRE
updated References, Relationships
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Demonstrative_Examples
2014-07-30 CWE Content Team MITRE
updated Relationships
2012-05-11 CWE Content Team MITRE
updated Related_Attack_Patterns, Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2011-03-29 CWE Content Team MITRE
updated Description
2010-09-27 CWE Content Team MITRE
updated Common_Consequences, Description
2009-07-27 CWE Content Team MITRE
updated Description, Other_Notes, Potential_Mitigations
2008-10-14 CWE Content Team MITRE
updated Description
2008-09-08 CWE Content Team MITRE
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction

CWE-1252: CPU Hardware Not Configured to Support Exclusivity of Write and Execute Operations

Weakness ID: 1252
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The CPU is not configured to provide hardware support for exclusivity of write and execute operations on memory. This allows an attacker to execute data from all of memory.
+ Extended Description

CPUs provide a special bit that supports exclusivity of write and execute operations. This bit is used to segregate areas of memory to either mark them as code (instructions, which can be executed) or data (which should not be executed). In this way, if a user can write to a region of memory, the user cannot execute from that region and vice versa. This exclusivity provided by special hardware bit is leveraged by the operating system to protect executable space. While this bit is available in most modern processors by default, in some CPUs the exclusivity is implemented via a memory-protection unit (MPU) and memory-management unit (MMU) in which memory regions can be carved out with exact read, write, and execute permissions. However, if the CPU does not have an MMU/MPU, then there is no write exclusivity. Without configuring exclusivity of operations via segregated areas of memory, an attacker may be able to inject malicious code onto memory and later execute it.

+ Common Consequences
Section HelpThis 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.
Impact Details

Execute Unauthorized Code or Commands

Scope: Confidentiality, Integrity

+ Potential Mitigations
Phase(s) Mitigation

Architecture and Design

Implement a dedicated bit that can be leveraged by the Operating System to mark data areas as non-executable. If such a bit is not available in the CPU, implement MMU/MPU (memory management unit / memory protection unit).

Integration

If MMU/MPU are not available, then the firewalls need to be implemented in the SoC interconnect to mimic the write-exclusivity operation.

+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Pillar Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things. 284 Improper Access Control
+ Relevant to the view "Hardware Design" (View-1194)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1201 Core and Compute Issues
+ Modes Of Introduction
Section HelpThe 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
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

Operating Systems

Class: Not OS-Specific (Undetermined Prevalence)

Architectures

Class: Not Architecture-Specific (Undetermined Prevalence)

Technologies

Microcontroller Hardware (Undetermined Prevalence)

Processor Hardware (Undetermined Prevalence)

+ Demonstrative Examples

Example 1


MCS51 Microcontroller (based on 8051) does not have a special bit to support write exclusivity. It also does not have an MMU/MPU support. The Cortex-M CPU has an optional MPU that supports up to 8 regions.

(bad code)
Example Language: Other 
The optional MPU is not configured.

If the MPU is not configured, then an attacker will be able to inject malicious data into memory and execute it.



+ Memberships
Section HelpThis 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1396 Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

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

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ References
[REF-1076] ARM. "Cortex-R4 Manual".
<https://developer.arm.com/Processors/Cortex-M4>. (URL validated: 2023-04-07)
[REF-1077] Intel. "MCS 51 Microcontroller Family User's Manual".
<http://web.mit.edu/6.115/www/document/8051.pdf>.
[REF-1078] ARM. "Memory Protection Unit (MPU)".
<https://web.archive.org/web/20200630034848/https://static.docs.arm.com/100699/0100/armv8m_architecture_memory_protection_unit_100699_0100_00_en.pdf>. (URL validated: 2023-04-07)
+ Content History
+ Submissions
Submission Date Submitter Organization
2020-02-13
(CWE 4.0, 2020-02-24)
Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V Mangipudi Intel Corporation
+ Modifications
Modification Date Modifier Organization
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated References, Relationships
2022-06-28 CWE Content Team MITRE
updated Applicable_Platforms
2022-04-28 CWE Content Team MITRE
updated Applicable_Platforms, Related_Attack_Patterns
2020-08-20 CWE Content Team MITRE
updated Related_Attack_Patterns

CWE-1279: Cryptographic Operations are run Before Supporting Units are Ready

Weakness ID: 1279
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
Performing cryptographic operations without ensuring that the supporting inputs are ready to supply valid data may compromise the cryptographic result.
+ Extended Description
Many cryptographic hardware units depend upon other hardware units to supply information to them to produce a securely encrypted result. For example, a cryptographic unit that depends on an external random-number-generator (RNG) unit for entropy must wait until the RNG unit is producing random numbers. If a cryptographic unit retrieves a private encryption key from a fuse unit, the fuse unit must be up and running before a key may be supplied.
+ Common Consequences
Section HelpThis 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.
Impact Details

Varies by Context

Scope: Access Control, Confidentiality, Integrity, Availability, Accountability, Authentication, Authorization, Non-Repudiation

+ Potential Mitigations
Phase(s) Mitigation

Architecture and Design

Best practices should be used to design cryptographic systems.

Implementation

Continuously ensuring that cryptographic inputs are supplying valid information is necessary to ensure that the encrypted output is secure.
+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 665 Improper Initialization
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 696 Incorrect Behavior Order
+ Relevant to the view "Hardware Design" (View-1194)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1205 Security Primitives and Cryptography Issues
+ Modes Of Introduction
Section HelpThe 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 The decision to continue using a cryptographic unit even though the input units to it are not producing valid data will compromise the encrypted result.
+ Applicable Platforms
Section HelpThis 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

Verilog (Undetermined Prevalence)

VHDL (Undetermined Prevalence)

Class: Not Language-Specific (Undetermined Prevalence)

Operating Systems

Class: Not OS-Specific (Undetermined Prevalence)

Architectures

Class: Not Architecture-Specific (Undetermined Prevalence)

Technologies

Processor Hardware (Undetermined Prevalence)

Class: Not Technology-Specific (Undetermined Prevalence)

+ Demonstrative Examples

Example 1


The following pseudocode illustrates the weak encryption resulting from the use of a pseudo-random-number generator output.

(bad code)
Example Language: Pseudocode 
If random_number_generator_self_test_passed() == TRUE
then Seed = get_random_number_from_RNG()
else Seed = hardcoded_number

In the example above, first a check of RNG ready is performed. If the check fails, the RNG is ignored and a hard coded value is used instead. The hard coded value severely weakens the encrypted output.

(good code)
Example Language: Pseudocode 
If random_number_generator_self_test_passed() == TRUE
then Seed = get_random_number_from_RNG()
else enter_error_state()


+ Memberships
Section HelpThis 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1416 Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

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

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Content History
+ Submissions
Submission Date Submitter Organization
2020-02-12
(CWE 4.1, 2020-02-24)
Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V Mangipudi Intel Corporation
+ Modifications
Modification Date Modifier Organization
2025-04-03
(CWE 4.17, 2025-04-03)
CWE Content Team MITRE
updated Relationships
2023-10-26 CWE Content Team MITRE
updated Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Relationships
2022-10-13 CWE Content Team MITRE
updated Demonstrative_Examples
2022-06-28 CWE Content Team MITRE
updated Applicable_Platforms
2022-04-28 CWE Content Team MITRE
updated Applicable_Platforms
2021-03-15 CWE Content Team MITRE
updated Maintenance_Notes
2020-08-20 CWE Content Team MITRE
updated Common_Consequences, Demonstrative_Examples, Description, Maintenance_Notes, Modes_of_Introduction, Name, Potential_Mitigations, Related_Attack_Patterns
+ Previous Entry Names
Change Date Previous Entry Name
2020-08-20 Cryptographic Primitives used without Successful Self-Test

CWE-1395: Dependency on Vulnerable Third-Party Component

Weakness ID: 1395
Vulnerability Mapping: ALLOWED This CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product has a dependency on a third-party component that contains one or more known vulnerabilities.
+ Extended Description

Many products are large enough or complex enough that part of their functionality uses libraries, modules, or other intellectual property developed by third parties who are not the product creator. For example, even an entire operating system might be from a third-party supplier in some hardware products. Whether open or closed source, these components may contain publicly known vulnerabilities that could be exploited by adversaries to compromise the product.

+ Common Consequences
Section HelpThis 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.
Impact Details

Varies by Context

Scope: Confidentiality, Integrity, Availability

The consequences vary widely, depending on the vulnerabilities that exist in the component; how those vulnerabilities can be "reached" by adversaries, as the exploitation paths and attack surface will vary depending on how the component is used; and the criticality of the privilege levels and features for which the product relies on the component.
+ Potential Mitigations
Phase(s) Mitigation

Requirements; Policy

In some industries such as healthcare [REF-1320] [REF-1322] or technologies such as the cloud [REF-1321], it might be unclear about who is responsible for applying patches for third-party vulnerabilities: the vendor, the operator/customer, or a separate service. Clarifying roles and responsibilities can be important to minimize confusion or unnecessary delay when third-party vulnerabilities are disclosed.

Requirements

Require a Bill of Materials for all components and sub-components of the product. For software, require a Software Bill of Materials (SBOM) [REF-1247] [REF-1311].

Architecture and Design; Implementation; Integration; Manufacturing

Maintain a Bill of Materials for all components and sub-components of the product. For software, maintain a Software Bill of Materials (SBOM). According to [REF-1247], "An SBOM is a formal, machine-readable inventory of software components and dependencies, information about those components, and their hierarchical relationships."

Operation; Patching and Maintenance

Actively monitor when a third-party component vendor announces vulnerability patches; fix the third-party component as soon as possible; and make it easy for operators/customers to obtain and apply the patch.

Operation; Patching and Maintenance

Continuously monitor changes in each of the product's components, especially when the changes indicate new vulnerabilities, end-of-life (EOL) plans, etc.
+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 657 Violation of Secure Design Principles
+ Modes Of Introduction
Section HelpThe 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 The product architect or designer might choose a component that is already known to contain vulnerabilities or has a high likelihood of containing vulnerabilities in the future.
Implementation For reasons of compatibility or stability, developers might choose a third-party component, such as a library, that is already known to contain vulnerabilities.
Patching and Maintenance Since all products contain vulnerabilities, over time, a third-party component will be discovered to have a vulnerability.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

Operating Systems

Class: Not OS-Specific (Undetermined Prevalence)

Architectures

Class: Not Architecture-Specific (Undetermined Prevalence)

Technologies

Class: Not Technology-Specific (Undetermined Prevalence)

+ Demonstrative Examples

Example 1


The "SweynTooth" vulnerabilities in Bluetooth Low Energy (BLE) software development kits (SDK) were found to affect multiple Bluetooth System-on-Chip (SoC) manufacturers. These SoCs were used by many products such as medical devices, Smart Home devices, wearables, and other IoT devices. [REF-1314] [REF-1315]



Example 2


log4j, a Java-based logging framework, is used in a large number of products, with estimates in the range of 3 billion affected devices [REF-1317]. When the "log4shell" (CVE-2021-44228) vulnerability was initially announced, it was actively exploited for remote code execution, requiring urgent mitigation in many organizations. However, it was unclear how many products were affected, as Log4j would sometimes be part of a long sequence of transitive dependencies. [REF-1316]



+ Detection Methods
Method Details

Automated Analysis

For software, use Software Composition Analysis (SCA) tools, which automatically analyze products to identify third-party dependencies. Often, SCA tools can be used to link with known vulnerabilities in the dependencies that they detect. There are commercial and open-source alternatives, such as OWASP Dependency-Check [REF-1312]. Many languages or frameworks have package managers with similar capabilities, such as npm audit for JavaScript, pip-audit for Python, govulncheck for Go, and many others. Dynamic methods can detect loading of third-party components.

Effectiveness: High

Note:Software Composition Analysis (SCA) tools face a number of technical challenges that can lead to false positives and false negatives. Dynamic methods have other technical challenges.
+ Memberships
Section HelpThis 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1418 Comprehensive Categorization: Violation of Secure Design Principles
+ Vulnerability Mapping Notes
Usage ALLOWED-WITH-REVIEW
(this CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review)
Reasons Abstraction, Other

Rationale

This CWE entry is a Class, but it does not have Base-level children.

Comments

This entry is classified in a part of CWE's hierarchy that does not have sufficiently low-level coverage, which might reflect a lack of classification-oriented weakness research in the software security community. Conduct careful root cause analysis to determine the original mistake that led to this weakness. If closer analysis reveals that this weakness is appropriate, then this might be the best available CWE to use for mapping. If no other option is available, then it is acceptable to map to this CWE.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
ISA/IEC 62443 Part 4-2 Req CR 2.4
ISA/IEC 62443 Part 4-2 Req CR 6.2
ISA/IEC 62443 Part 4-2 Req CR 7.2
ISA/IEC 62443 Part 4-1 Req SM-9
ISA/IEC 62443 Part 4-1 Req SM-10
ISA/IEC 62443 Part 4-1 Req SR-2
ISA/IEC 62443 Part 4-1 Req DM-1
ISA/IEC 62443 Part 4-1 Req DM-3
ISA/IEC 62443 Part 4-1 Req DM-4
ISA/IEC 62443 Part 4-1 Req SVV-1
ISA/IEC 62443 Part 4-1 Req SVV-3
+ References
[REF-1313] Jeff Williams, Arshan Dabirsiaghi. "The Unfortunate Reality of Insecure Libraries". 2014.
<https://owasp.org/www-project-dependency-check/>. (URL validated: 2023-01-25)
[REF-1212] "A06:2021 - Vulnerable and Outdated Components". OWASP. 2021-09-24.
<https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/>.
[REF-1247] NTIA Multistakeholder Process on Software Component Transparency Framing Working Group. "Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM)". 2021-10-21.
<https://www.ntia.gov/files/ntia/publications/ntia_sbom_framing_2nd_edition_20211021.pdf>.
[REF-1311] Amélie Koran, Wendy Nather, Stewart Scott, Sara Ann Brackett. "The Cases for Using the SBOMs We Build". 2022-11.
<https://www.atlanticcouncil.org/wp-content/uploads/2022/11/AC_SBOM_IB_v2-002.pdf>. (URL validated: 2023-01-25)
[REF-1312] OWASP. "OWASP Dependency-Check".
<https://owasp.org/www-project-dependency-check/>. (URL validated: 2023-01-25)
[REF-1314] ICS-CERT. "ICS Alert (ICS-ALERT-20-063-01): SweynTooth Vulnerabilities". 2020-03-04.
<https://www.cisa.gov/news-events/ics-alerts/ics-alert-20-063-01>. (URL validated: 2023-04-07)
[REF-1315] Matheus E. Garbelini, Sudipta Chattopadhyay, Chundong Wang, Singapore University of Technology and Design. "Unleashing Mayhem over Bluetooth Low Energy". 2020-03-04.
<https://asset-group.github.io/disclosures/sweyntooth/>. (URL validated: 2023-01-25)
[REF-1316] CISA. "Alert (AA21-356A): Mitigating Log4Shell and Other Log4j-Related Vulnerabilities". 2021-12-22.
<https://www.cisa.gov/news-events/cybersecurity-advisories/aa21-356a>. (URL validated: 2023-04-07)
[REF-1317] SC Media. "What Log4Shell taught us about application security, and how to respond now". 2022-07-05.
<https://www.scmagazine.com/resource/application-security/what-log4shell-taught-us-about-appsec-and-how-to-respond>. (URL validated: 2023-01-26)
[REF-1320] Ali Youssef. "A Framework for a Medical Device Security Program at a Healthcare Delivery Organization". 2022-08-08.
<https://array.aami.org/content/news/framework-medical-device-security-program-healthcare-delivery-organization>. (URL validated: 2023-04-07)
[REF-1321] Cloud Security Alliance. "Shared Responsibility Model Explained". 2020-08-26.
<https://cloudsecurityalliance.org/blog/2020/08/26/shared-responsibility-model-explained/>. (URL validated: 2023-01-28)
[REF-1322] Melissa Chase, Steven Christey Coley, Julie Connolly, Ronnie Daldos, Margie Zuk. "Medical Device Cybersecurity Regional Incident Preparedness and Response Playbook". Section 6.1: Medical Device Procurement. 2022-11-14.
<https://www.mitre.org/news-insights/publication/medical-device-cybersecurity-regional-incident-preparedness-and-response>. (URL validated: 2023-01-28)
+ Content History
+ Submissions
Submission Date Submitter Organization
2023-01-25
(CWE 4.10, 2023-01-31)
CWE Content Team MITRE
+ Contributions
Contribution Date Contributor Organization
2022-04-18 Samreen Arshad Balochistan University of Information Technology, Engineering and Management Sciences
Submitted a request for coverage of "Vulnerable and Outdated Components"
2023-06-29
(CWE 4.12, 2023-06-29)
"Mapping CWE to 62443" Sub-Working Group CWE-CAPEC ICS/OT SIG
Suggested mappings to ISA/IEC 62443.
+ Modifications
Modification Date Modifier Organization
2025-04-03
(CWE 4.17, 2025-04-03)
CWE Content Team MITRE
updated Mapping_Notes
2023-10-26 CWE Content Team MITRE
updated Demonstrative_Examples
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes, Taxonomy_Mappings
2023-04-27 CWE Content Team MITRE
updated References, Relationships

CWE-502: Deserialization of Untrusted Data

Weakness ID: 502
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product deserializes untrusted data without sufficiently ensuring that the resulting data will be valid. Diagram for CWE-502
+ Alternate Terms
Marshaling, Unmarshaling
Marshaling and unmarshaling are effectively synonyms for serialization and deserialization, respectively.
Pickling, Unpickling
In Python, the "pickle" functionality is used to perform serialization and deserialization.
PHP Object Injection
Some PHP application researchers use this term when attacking unsafe use of the unserialize() function; but it is also used for CWE-915.
+ Common Consequences
Section HelpThis 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.
Impact Details

Modify Application Data; Unexpected State

Scope: Integrity

Attackers can modify unexpected objects or data that was assumed to be safe from modification. Deserialized data or code could be modified without using the provided accessor functions, or unexpected functions could be invoked.

DoS: Resource Consumption (CPU)

Scope: Availability

If a function is making an assumption on when to terminate, based on a sentry in a string, it could easily never terminate.

Varies by Context

Scope: Other

The consequences can vary widely, because it depends on which objects or methods are being deserialized, and how they are used. Making an assumption that the code in the deserialized object is valid is dangerous and can enable exploitation. One example is attackers using gadget chains to perform unauthorized actions, such as generating a shell.
+ Potential Mitigations
Phase(s) Mitigation

Architecture and Design; Implementation

If available, use the signing/sealing features of the programming language to assure that deserialized data has not been tainted. For example, a hash-based message authentication code (HMAC) could be used to ensure that data has not been modified.

Implementation

When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.

Implementation

Explicitly define a final object() to prevent deserialization.

Architecture and Design; Implementation

Make fields transient to protect them from deserialization.

An attempt to serialize and then deserialize a class containing transient fields will result in NULLs where the transient data should be. This is an excellent way to prevent time, environment-based, or sensitive variables from being carried over and used improperly.

Implementation

Avoid having unnecessary types or gadgets (a sequence of instances and method invocations that can self-execute during the deserialization process, often found in libraries) available that can be leveraged for malicious ends. This limits the potential for unintended or unauthorized types and gadgets to be leveraged by the attacker. Add only acceptable classes to an allowlist. Note: new gadgets are constantly being discovered, so this alone is not a sufficient mitigation.

Architecture and Design; Implementation

Employ cryptography of the data or code for protection. However, it's important to note that it would still be client-side security. This is risky because if the client is compromised then the security implemented on the client (the cryptography) can be bypassed.
+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 913 Improper Control of Dynamically-Managed Code Resources
PeerOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 915 Improperly Controlled Modification of Dynamically-Determined Object Attributes
+ Relevant to the view "Software Development" (View-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 399 Resource Management Errors
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 913 Improper Control of Dynamically-Managed Code Resources
+ Relevant to the view "Architectural Concepts" (View-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1019 Validate Inputs
+ Background Details
Serialization and deserialization refer to the process of taking program-internal object-related data, packaging it in a way that allows the data to be externally stored or transferred ("serialization"), then extracting the serialized data to reconstruct the original object ("deserialization").
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Implementation
+ Applicable Platforms
Section HelpThis 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

Java (Undetermined Prevalence)

Ruby (Undetermined Prevalence)

PHP (Undetermined Prevalence)

Python (Undetermined Prevalence)

JavaScript (Undetermined Prevalence)

Technologies

Class: ICS/OT (Often Prevalent)

+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1


This code snippet deserializes an object from a file and uses it as a UI button:

(bad code)
Example Language: Java 
try {
File file = new File("object.obj");
ObjectInputStream in = new ObjectInputStream(new FileInputStream(file));
javax.swing.JButton button = (javax.swing.JButton) in.readObject();
in.close();
}

This code does not attempt to verify the source or contents of the file before deserializing it. An attacker may be able to replace the intended file with a file that contains arbitrary malicious code which will be executed when the button is pressed.

To mitigate this, explicitly define final readObject() to prevent deserialization. An example of this is:

(good code)
Example Language: Java 
private final void readObject(ObjectInputStream in) throws java.io.IOException {
throw new java.io.IOException("Cannot be deserialized"); }


Example 2


In Python, the Pickle library handles the serialization and deserialization processes. In this example derived from [REF-467], the code receives and parses data, and afterwards tries to authenticate a user based on validating a token.

(bad code)
Example Language: Python 
try {
class ExampleProtocol(protocol.Protocol):
def dataReceived(self, data):

# Code that would be here would parse the incoming data
# After receiving headers, call confirmAuth() to authenticate

def confirmAuth(self, headers):
try:
token = cPickle.loads(base64.b64decode(headers['AuthToken']))
if not check_hmac(token['signature'], token['data'], getSecretKey()):
raise AuthFail
self.secure_data = token['data']
except:
raise AuthFail
}

Unfortunately, the code does not verify that the incoming data is legitimate. An attacker can construct a illegitimate, serialized object "AuthToken" that instantiates one of Python's subprocesses to execute arbitrary commands. For instance,the attacker could construct a pickle that leverages Python's subprocess module, which spawns new processes and includes a number of arguments for various uses. Since Pickle allows objects to define the process for how they should be unpickled, the attacker can direct the unpickle process to call Popen in the subprocess module and execute /bin/sh.



+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
chain: bypass of untrusted deserialization issue (CWE-502) by using an assumed-trusted class (CWE-183)
Deserialization issue in commonly-used Java library allows remote execution.
Deserialization issue in commonly-used Java library allows remote execution.
Use of PHP unserialize function on untrusted input allows attacker to modify application configuration.
Use of PHP unserialize function on untrusted input in content management system might allow code execution.
Use of PHP unserialize function on untrusted input in content management system allows code execution using a crafted cookie value.
Content management system written in PHP allows unserialize of arbitrary objects, possibly allowing code execution.
Python script allows local users to execute code via pickled data.
Unsafe deserialization using pickle in a Python script.
Web browser allows execution of native methods via a crafted string to a JavaScript function that deserializes the string.
+ Detection Methods
Method Details

Automated Static Analysis

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

Effectiveness: High

+ Memberships
Section HelpThis 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 858 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - Serialization (SER)
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 994 SFP Secondary Cluster: Tainted Input to Variable
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1034 OWASP Top Ten 2017 Category A8 - Insecure Deserialization
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1148 SEI CERT Oracle Secure Coding Standard for Java - Guidelines 14. Serialization (SER)
MemberOf ViewView - 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1308 CISQ Quality Measures - Security
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1337 Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf ViewView - 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 ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1350 Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1354 OWASP Top Ten 2021 Category A08:2021 - Software and Data Integrity Failures
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1387 Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1415 Comprehensive Categorization: Resource Control
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1425 Weaknesses in the 2023 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1430 Weaknesses in the 2024 CWE Top 25 Most Dangerous Software Weaknesses
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

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

Comments

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

Maintenance

The relationships between CWE-502 and CWE-915 need further exploration. CWE-915 is more narrowly scoped to object modification, and is not necessarily used for deserialization.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
CLASP Deserialization of untrusted data
The CERT Oracle Secure Coding Standard for Java (2011) SER01-J Do not deviate from the proper signatures of serialization methods
The CERT Oracle Secure Coding Standard for Java (2011) SER03-J Do not serialize unencrypted, sensitive data
The CERT Oracle Secure Coding Standard for Java (2011) SER06-J Make defensive copies of private mutable components during deserialization
The CERT Oracle Secure Coding Standard for Java (2011) SER08-J Do not use the default serialized form for implementation defined invariants
Software Fault Patterns SFP25 Tainted input to variable
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005.
<https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>. (URL validated: 2024-11-17)
[REF-461] Matthias Kaiser. "Exploiting Deserialization Vulnerabilities in Java". 2015-10-28.
<https://www.slideshare.net/codewhitesec/exploiting-deserialization-vulnerabilities-in-java-54707478>. (URL validated: 2023-04-07)
[REF-462] Sam Thomas. "PHP unserialization vulnerabilities: What are we missing?". 2015-08-27.
<https://www.slideshare.net/_s_n_t/php-unserialization-vulnerabilities-what-are-we-missing>. (URL validated: 2023-04-07)
[REF-463] Gabriel Lawrence and Chris Frohoff. "Marshalling Pickles: How deserializing objects can ruin your day". 2015-01-28.
<https://www.slideshare.net/frohoff1/appseccali-2015-marshalling-pickles>. (URL validated: 2023-04-07)
[REF-464] Heine Deelstra. "Unserializing user-supplied data, a bad idea". 2010-08-25.
<https://drupalsun.com/heine/2010/08/25/unserializing-user-supplied-data-bad-idea>. (URL validated: 2023-04-07)
[REF-465] Manish S. Saindane. "Black Hat EU 2010 - Attacking Java Serialized Communication". 2010-04-26.
<https://www.slideshare.net/msaindane/black-hat-eu-2010-attacking-java-serialized-communication>. (URL validated: 2023-04-07)
[REF-466] Nadia Alramli. "Why Python Pickle is Insecure". 2009-09-09.
<http://michael-rushanan.blogspot.com/2012/10/why-python-pickle-is-insecure.html>. (URL validated: 2023-04-07)
[REF-467] Nelson Elhage. "Exploiting misuse of Python's "pickle"". 2011-03-20.
<https://blog.nelhage.com/2011/03/exploiting-pickle/>.
[REF-468] Chris Frohoff. "Deserialize My Shorts: Or How I Learned to Start Worrying and Hate Java Object Deserialization". 2016-03-21.
<https://speakerdeck.com/frohoff/owasp-sd-deserialize-my-shorts-or-how-i-learned-to-start-worrying-and-hate-java-object-deserialization>. (URL validated: 2023-04-07)
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Contributions
Contribution Date Contributor Organization
2024-02-29
(CWE 4.16, 2024-11-19)
Abhi Balakrishnan
Contributed usability diagram concepts used by the CWE team
+ Modifications
Modification Date Modifier Organization
2024-11-19
(CWE 4.16, 2024-11-19)
CWE Content Team MITRE
updated Common_Consequences, Description, Diagram, Potential_Mitigations, Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes, Relationships
2023-04-27 CWE Content Team MITRE
updated Detection_Factors, References, Relationships
2023-01-31 CWE Content Team MITRE
updated Description
2022-10-13 CWE Content Team MITRE
updated Applicable_Platforms
2022-06-28 CWE Content Team MITRE
updated Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2021-07-20 CWE Content Team MITRE
updated Relationships
2020-12-10 CWE Content Team MITRE
updated Relationships
2020-08-20 CWE Content Team MITRE
updated Relationships
2020-06-25 CWE Content Team MITRE
updated Alternate_Terms, Potential_Mitigations
2020-02-24 CWE Content Team MITRE
updated Observed_Examples, References, Relationships
2019-09-19 CWE Content Team MITRE
updated Relationships
2019-06-20 CWE Content Team MITRE
updated Type
2019-01-03 CWE Content Team MITRE
updated Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2018-03-27 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Modes_of_Introduction, Potential_Mitigations, References, Relationships
2017-05-03 CWE Content Team MITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Potential_Mitigations, References
2015-12-07 CWE Content Team MITRE
updated Observed_Examples, References, Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2013-02-21 CWE Content Team MITRE
updated Alternate_Terms, Applicable_Platforms, Background_Details, Common_Consequences, Maintenance_Notes, Observed_Examples, Potential_Mitigations, References, Relationships
2012-10-30 CWE Content Team MITRE
updated Demonstrative_Examples
2012-05-11 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2009-10-29 CWE Content Team MITRE
updated Description, Other_Notes, Potential_Mitigations
2008-09-08 CWE Content Team MITRE
updated Common_Consequences, Description, Relationships, Other_Notes, Taxonomy_Mappings
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction

CWE-1190: DMA Device Enabled Too Early in Boot Phase

Weakness ID: 1190
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product enables a Direct Memory Access (DMA) capable device before the security configuration settings are established, which allows an attacker to extract data from or gain privileges on the product.
+ Extended Description

DMA is included in a number of devices because it allows data transfer between the computer and the connected device, using direct hardware access to read or write directly to main memory without any OS interaction. An attacker could exploit this to access secrets. Several virtualization-based mitigations have been introduced to thwart DMA attacks. These are usually configured/setup during boot time. However, certain IPs that are powered up before boot is complete (known as early boot IPs) may be DMA capable. Such IPs, if not trusted, could launch DMA attacks and gain access to assets that should otherwise be protected.

+ Common Consequences
Section HelpThis 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.
Impact Details

Bypass Protection Mechanism; Modify Memory

Scope: Access Control

Likelihood: High

DMA devices have direct write access to main memory and due to time of attack will be able to bypass OS or Bootloader access control.
+ Potential Mitigations
Phase(s) Mitigation

Architecture and Design

Utilize an IOMMU to orchestrate IO access from the start of the boot process.
+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 696 Incorrect Behavior Order
+ Relevant to the view "Hardware Design" (View-1194)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1196 Security Flow Issues
+ Modes Of Introduction
Section HelpThe 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
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Class: System on Chip (Undetermined Prevalence)

+ Memberships
Section HelpThis 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1410 Comprehensive Categorization: Insufficient Control Flow Management
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

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

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ References
[REF-1038] "DMA attack". 2019-10-19.
<https://en.wikipedia.org/wiki/DMA_attack>.
[REF-1039] A. Theodore Markettos, Colin Rothwell, Brett F. Gutstein, Allison Pearce, Peter G. Neumann, Simon W. Moore and Robert N. M. Watson. "Thunderclap: Exploring Vulnerabilities in Operating System IOMMU Protection via DMA from Untrustworthy Peripherals". 2019-02-25.
<https://www.ndss-symposium.org/wp-content/uploads/2019/02/ndss2019_05A-1_Markettos_paper.pdf>.
[REF-1040] Maximillian Dornseif, Michael Becher and Christian N. Klein. "FireWire all your memory are belong to us". 2005.
<http://www.orkspace.net/secdocs/Conferences/CanSecWest/2005/0wn3d%20by%20an%20iPod%20-%20Firewire1394%20Issues.pdf>. (URL validated: 2023-04-07)
[REF-1041] Rory Breuk, Albert Spruyt and Adam Boileau. "Integrating DMA attacks in exploitation frameworks". 2012-02-20.
<https://www.os3.nl/_media/2011-2012/courses/rp1/p14_report.pdf>.
[REF-1042] Maximillian Dornseif. "Owned by an iPod". 2004.
<https://web.archive.org/web/20060505224959/https://pacsec.jp/psj04/psj04-dornseif-e.ppt>. (URL validated: 2023-04-07)
[REF-1044] Dmytro Oleksiuk. "My aimful life". 2015-09-12.
<http://blog.cr4.sh/2015/09/breaking-uefi-security-with-software.html>.
[REF-1046] A. Theodore Markettos and Adam Boileau. "Hit by a Bus:Physical Access Attacks with Firewire". 2006.
<https://security-assessment.com/files/presentations/ab_firewire_rux2k6-final.pdf>.
+ Content History
+ Submissions
Submission Date Submitter Organization
2019-10-15
(CWE 4.0, 2020-02-24)
Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V Mangipudi Intel Corporation
+ Modifications
Modification Date Modifier Organization
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated References, Relationships
2020-08-20 CWE Content Team MITRE
updated Related_Attack_Patterns

CWE-494: Download of Code Without Integrity Check

Weakness ID: 494
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product downloads source code or an executable from a remote location and executes the code without sufficiently verifying the origin and integrity of the code.
+ Extended Description
An attacker can execute malicious code by compromising the host server, performing DNS spoofing, or modifying the code in transit.
+ Common Consequences
Section HelpThis 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.
Impact Details

Execute Unauthorized Code or Commands; Alter Execution Logic; Other

Scope: Integrity, Availability, Confidentiality, Other

Executing untrusted code could compromise the control flow of the program. The untrusted code could execute attacker-controlled commands, read or modify sensitive resources, or prevent the software from functioning correctly for legitimate users.
+ Potential Mitigations
Phase(s) Mitigation

Implementation

Perform proper forward and reverse DNS lookups to detect DNS spoofing.
Note: This is only a partial solution since it will not prevent your code from being modified on the hosting site or in transit.

Architecture and Design; Operation

Encrypt the code with a reliable encryption scheme before transmitting.

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

Architecture and Design

Strategy: Libraries or Frameworks

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

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

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

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.

Architecture and Design; Operation

Strategy: Sandbox or Jail

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

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

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

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

Effectiveness: Limited

Note: The effectiveness of this mitigation depends on the prevention capabilities of the specific sandbox or jail being used and might only help to reduce the scope of an attack, such as restricting the attacker to certain system calls or limiting the portion of the file system that can be accessed.
+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 345 Insufficient Verification of Data Authenticity
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 669 Incorrect Resource Transfer Between Spheres
CanFollow Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
+ Relevant to the view "Software Development" (View-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1214 Data Integrity Issues
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 669 Incorrect Resource Transfer Between Spheres
+ Relevant to the view "Architectural Concepts" (View-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1020 Verify Message Integrity
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Implementation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1


This example loads an external class from a local subdirectory.

(bad code)
Example Language: Java 
URL[] classURLs= new URL[]{
new URL("file:subdir/")
};
URLClassLoader loader = new URLClassLoader(classURLs);
Class loadedClass = Class.forName("loadMe", true, loader);

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



Example 2


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

(bad code)
Example Language: PHP 
//assume the password is already encrypted, avoiding CWE-312

function authenticate($username,$password){

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

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

if(mysql_numrows($result) == 1){
mysql_close();
return true;
}
else{
mysql_close();
return false;
}

}

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

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



+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
Satellite phone does not validate its firmware image.
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).
OS does not verify authenticity of its own updates.
online poker client does not verify authenticity of its own updates.
anti-virus product does not verify automatic updates for itself.
VOIP phone downloads applications from web sites without verifying integrity.
+ Detection Methods
Method Details

Manual Analysis

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

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

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

Black Box

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

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

Automated Static Analysis

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

Effectiveness: High

+ Memberships
Section HelpThis 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 752 2009 Top 25 - Risky Resource Management
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 802 2010 Top 25 - Risky Resource Management
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 859 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 16 - Platform Security (SEC)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 865 2011 Top 25 - Risky Resource Management
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 991 SFP Secondary Cluster: Tainted Input to Environment
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1354 OWASP Top Ten 2021 Category A08:2021 - Software and Data Integrity Failures
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1364 ICS Communications: Zone Boundary Failures
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1411 Comprehensive Categorization: Insufficient Verification of Data Authenticity
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

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

Comments

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

Research Gap

This is critical for mobile code, but it is likely to become more and more common as developers continue to adopt automated, network-based product distributions and upgrades. Software-as-a-Service (SaaS) might introduce additional subtleties. Common exploitation scenarios may include ad server compromises and bad upgrades.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
CLASP Invoking untrusted mobile code
The CERT Oracle Secure Coding Standard for Java (2011) SEC06-J Do not rely on the default automatic signature verification provided by URLClassLoader and java.util.jar
Software Fault Patterns SFP27 Tainted input to environment
+ References
[REF-454] Microsoft. "Introduction to Code Signing".
<http://msdn.microsoft.com/en-us/library/ms537361(VS.85).aspx>.
[REF-455] Microsoft. "Authenticode".
<http://msdn.microsoft.com/en-us/library/ms537359(v=VS.85).aspx>.
[REF-456] Apple. "Code Signing Guide". Apple Developer Connection. 2008-11-19.
<https://web.archive.org/web/20080724215143/http://developer.apple.com/documentation/Security/Conceptual/CodeSigningGuide/Introduction/chapter_1_section_1.html>. (URL validated: 2023-04-07)
[REF-457] Anthony Bellissimo, John Burgess and Kevin Fu. "Secure Software Updates: Disappointments and New Challenges".
<http://prisms.cs.umass.edu/~kevinfu/papers/secureupdates-hotsec06.pdf>.
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 18: The Sins of Mobile Code." Page 267. McGraw-Hill. 2010.
[REF-459] Johannes Ullrich. "Top 25 Series - Rank 20 - Download of Code Without Integrity Check". SANS Software Security Institute. 2010-04-05.
<https://www.sans.org/blog/top-25-series-rank-20-download-of-code-without-integrity-check/>. (URL validated: 2023-04-07)
[REF-76] Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14.
<https://web.archive.org/web/20211209014121/https://www.cisa.gov/uscert/bsi/articles/knowledge/principles/least-privilege>. (URL validated: 2023-04-07)
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005.
<https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>. (URL validated: 2024-11-17)
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification Date Modifier Organization
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Demonstrative_Examples, Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Detection_Factors, References, Relationships
2023-01-31 CWE Content Team MITRE
updated Related_Attack_Patterns
2022-10-13 CWE Content Team MITRE
updated References, Related_Attack_Patterns
2021-10-28 CWE Content Team MITRE
updated Observed_Examples, Relationships
2021-07-20 CWE Content Team MITRE
updated Demonstrative_Examples
2021-03-15 CWE Content Team MITRE
updated References, Related_Attack_Patterns
2020-12-10 CWE Content Team MITRE
updated Demonstrative_Examples
2020-08-20 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Demonstrative_Examples, Relationships
2019-06-20 CWE Content Team MITRE
updated Related_Attack_Patterns, Relationships
2019-01-03 CWE Content Team MITRE
updated Taxonomy_Mappings
2017-11-08 CWE Content Team MITRE
updated Modes_of_Introduction, References, Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2012-05-11 CWE Content Team MITRE
updated References, Relationships, Taxonomy_Mappings
2011-09-13 CWE Content Team MITRE
updated Potential_Mitigations, References
2011-06-27 CWE Content Team MITRE
updated Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-03-29 CWE Content Team MITRE
updated Demonstrative_Examples
2010-12-13 CWE Content Team MITRE
updated Potential_Mitigations
2010-09-27 CWE Content Team MITRE
updated Potential_Mitigations, References
2010-06-21 CWE Content Team MITRE
updated Common_Consequences, Detection_Factors, Potential_Mitigations, References
2010-04-05 CWE Content Team MITRE
updated Applicable_Platforms
2010-02-16 CWE Content Team MITRE
updated Detection_Factors, References, Relationships
2009-07-27 CWE Content Team MITRE
updated Description, Observed_Examples, Related_Attack_Patterns
2009-03-10 CWE Content Team MITRE
updated Potential_Mitigations
2009-01-12 CWE Content Team MITRE
updated Applicable_Platforms, Common_Consequences, Description, Name, Other_Notes, Potential_Mitigations, References, Relationships, Research_Gaps, Type
2008-09-08 CWE Content Team MITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
+ Previous Entry Names
Change Date Previous Entry Name
2008-04-11 Mobile Code: Invoking Untrusted Mobile Code
2009-01-12 Download of Untrusted Mobile Code Without Integrity Check

CWE-250: Execution with Unnecessary Privileges

Weakness ID: 250
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product performs an operation at a privilege level that is higher than the minimum level required, which creates new weaknesses or amplifies the consequences of other weaknesses.
+ Extended Description

New weaknesses can be exposed because running with extra privileges, such as root or Administrator, can disable the normal security checks being performed by the operating system or surrounding environment. Other pre-existing weaknesses can turn into security vulnerabilities if they occur while operating at raised privileges.

Privilege management functions can behave in some less-than-obvious ways, and they have different quirks on different platforms. These inconsistencies are particularly pronounced if you are transitioning from one non-root user to another. Signal handlers and spawned processes run at the privilege of the owning process, so if a process is running as root when a signal fires or a sub-process is executed, the signal handler or sub-process will operate with root privileges.

+ Common Consequences
Section HelpThis 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.
Impact Details

Gain Privileges or Assume Identity; Execute Unauthorized Code or Commands; Read Application Data; DoS: Crash, Exit, or Restart

Scope: Confidentiality, Integrity, Availability, Access Control

An attacker will be able to gain access to any resources that are allowed by the extra privileges. Common results include executing code, disabling services, and reading restricted data.
+ Potential Mitigations
Phase(s) Mitigation

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.

Architecture and Design

Strategy: Separation of Privilege

Identify the functionality that requires additional privileges, such as access to privileged operating system resources. Wrap and centralize this functionality if possible, and isolate the privileged code as much as possible from other code [REF-76]. Raise privileges as late as possible, and drop them as soon as possible to avoid CWE-271. Avoid weaknesses such as CWE-288 and CWE-420 by protecting all possible communication channels that could interact with the privileged code, such as a secondary socket that is only intended to be accessed by administrators.

Architecture and Design

Strategy: Attack Surface Reduction

Identify the functionality that requires additional privileges, such as access to privileged operating system resources. Wrap and centralize this functionality if possible, and isolate the privileged code as much as possible from other code [REF-76]. Raise privileges as late as possible, and drop them as soon as possible to avoid CWE-271. Avoid weaknesses such as CWE-288 and CWE-420 by protecting all possible communication channels that could interact with the privileged code, such as a secondary socket that is only intended to be accessed by administrators.

Implementation

Perform extensive input validation for any privileged code that must be exposed to the user and reject anything that does not fit your strict requirements.

Implementation

When dropping privileges, ensure that they have been dropped successfully to avoid CWE-273. As protection mechanisms in the environment get stronger, privilege-dropping calls may fail even if it seems like they would always succeed.

Implementation

If circumstances force you to run with extra privileges, then determine the minimum access level necessary. First identify the different permissions that the software and its users will need to perform their actions, such as file read and write permissions, network socket permissions, and so forth. Then explicitly allow those actions while denying all else [REF-76]. Perform extensive input validation and canonicalization to minimize the chances of introducing a separate vulnerability. This mitigation is much more prone to error than dropping the privileges in the first place.

Operation; System Configuration

Strategy: Environment Hardening

Ensure that the software runs properly under the United States Government Configuration Baseline (USGCB) [REF-199] or an equivalent hardening configuration guide, which many organizations use to limit the attack surface and potential risk of deployed software.
+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 269 Improper Privilege Management
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 657 Violation of Secure Design Principles
+ Relevant to the view "Software Development" (View-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 265 Privilege Issues
+ Relevant to the view "Architectural Concepts" (View-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1015 Limit Access
+ Modes Of Introduction
Section HelpThe 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
Implementation

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

Installation
Architecture and Design

If an application has this design problem, then it can be easier for the developer to make implementation-related errors such as CWE-271 (Privilege Dropping / Lowering Errors). In addition, the consequences of Privilege Chaining (CWE-268) can become more severe.

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

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Class: Mobile (Undetermined Prevalence)

+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1


This code temporarily raises the program's privileges to allow creation of a new user folder.

(bad code)
Example Language: Python 
def makeNewUserDir(username):
if invalidUsername(username):

#avoid CWE-22 and CWE-78
print('Usernames cannot contain invalid characters')
return False

try:
raisePrivileges()
os.mkdir('/home/' + username)
lowerPrivileges()

except OSError:
print('Unable to create new user directory for user:' + username)
return False

return True

While the program only raises its privilege level to create the folder and immediately lowers it again, if the call to os.mkdir() throws an exception, the call to lowerPrivileges() will not occur. As a result, the program is indefinitely operating in a raised privilege state, possibly allowing further exploitation to occur.



Example 2


The following code calls chroot() to restrict the application to a subset of the filesystem below APP_HOME in order to prevent an attacker from using the program to gain unauthorized access to files located elsewhere. The code then opens a file specified by the user and processes the contents of the file.

(bad code)
Example Language:
chroot(APP_HOME);
chdir("/");
FILE* data = fopen(argv[1], "r+");
...

Constraining the process inside the application's home directory before opening any files is a valuable security measure. However, the absence of a call to setuid() with some non-zero value means the application is continuing to operate with unnecessary root privileges. Any successful exploit carried out by an attacker against the application can now result in a privilege escalation attack because any malicious operations will be performed with the privileges of the superuser. If the application drops to the privilege level of a non-root user, the potential for damage is substantially reduced.



Example 3


This application intends to use a user's location to determine the timezone the user is in:

(bad code)
Example Language: Java 
locationClient = new LocationClient(this, this, this);
locationClient.connect();
Location userCurrLocation;
userCurrLocation = locationClient.getLastLocation();
setTimeZone(userCurrLocation);

This is unnecessary use of the location API, as this information is already available using the Android Time API. Always be sure there is not another way to obtain needed information before resorting to using the location API.



Example 4


This code uses location to determine the user's current US State location.

First the application must declare that it requires the ACCESS_FINE_LOCATION permission in the application's manifest.xml:

(bad code)
Example Language: XML 
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>

During execution, a call to getLastLocation() will return a location based on the application's location permissions. In this case the application has permission for the most accurate location possible:

(bad code)
Example Language: Java 
locationClient = new LocationClient(this, this, this);
locationClient.connect();
Location userCurrLocation;
userCurrLocation = locationClient.getLastLocation();
deriveStateFromCoords(userCurrLocation);

While the application needs this information, it does not need to use the ACCESS_FINE_LOCATION permission, as the ACCESS_COARSE_LOCATION permission will be sufficient to identify which US state the user is in.



+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
FTP client program on a certain OS runs with setuid privileges and has a buffer overflow. Most clients do not need extra privileges, so an overflow is not a vulnerability for those clients.
Program runs with privileges and calls another program with the same privileges, which allows read of arbitrary files.
OS incorrectly installs a program with setuid privileges, allowing users to gain privileges.
Composite: application running with high privileges (CWE-250) allows user to specify a restricted file to process, which generates a parsing error that leaks the contents of the file (CWE-209).
Program does not drop privileges before calling another program, allowing code execution.
setuid root program allows creation of arbitrary files through command line argument.
Installation script installs some programs as setuid when they shouldn't be.
mail program runs as root but does not drop its privileges before attempting to access a file. Attacker can use a symlink from their home directory to a directory only readable by root, then determine whether the file exists based on the response.
Product launches Help functionality while running with raised privileges, allowing command execution using Windows message to access "open file" dialog.
+ Detection Methods
Method Details

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.
Note:These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.

Black Box

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

Attach the monitor to the process and perform a login. Look for library functions and system calls that indicate when privileges are being raised or dropped. Look for accesses of resources that are restricted to normal users.

Note:Note that this technique is only useful for privilege issues related to system resources. It is not likely to detect application-level business rules that are related to privileges, such as if a blog system allows a user to delete a blog entry without first checking that the user has administrator privileges.

Automated Static Analysis - Binary or Bytecode

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

Highly cost effective:
  • Compare binary / bytecode to application permission manifest
Cost effective for partial coverage:
  • Bytecode Weakness Analysis - including disassembler + source code weakness analysis
  • Binary Weakness Analysis - including disassembler + source code weakness analysis

Effectiveness: High

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:
  • Host-based Vulnerability Scanners - Examine configuration for flaws, verifying that audit mechanisms work, ensure host configuration meets certain predefined criteria

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

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

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

Highly cost effective:
  • Manual Source Code Review (not inspections)
Cost effective for partial coverage:
  • Focused Manual Spotcheck - Focused manual analysis of source

Effectiveness: High

Automated Static Analysis - Source Code

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

Cost effective for partial coverage:
  • Source code Weakness Analyzer
  • Context-configured Source Code Weakness Analyzer

Effectiveness: SOAR Partial

Automated Static Analysis

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

Cost effective for partial coverage:
  • Configuration Checker
  • Permission Manifest Analysis

Effectiveness: SOAR Partial

Architecture or Design Review

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

Highly cost effective:
  • Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)
  • Formal Methods / Correct-By-Construction
Cost effective for partial coverage:
  • Attack Modeling

Effectiveness: High

+ Memberships
Section HelpThis 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 227 7PK - API Abuse
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 753 2009 Top 25 - Porous Defenses
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 815 OWASP Top Ten 2010 Category A6 - Security Misconfiguration
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 858 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 15 - Serialization (SER)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 866 2011 Top 25 - Porous Defenses
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 901 SFP Primary Cluster: Privilege
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1418 Comprehensive Categorization: Violation of Secure Design Principles
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

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

Comments

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

Relationship

There is a close association with CWE-653 (Insufficient Separation of Privileges). CWE-653 is about providing separate components for each privilege; CWE-250 is about ensuring that each component has the least amount of privileges possible.

Maintenance

CWE-271, CWE-272, and CWE-250 are all closely related and possibly overlapping. CWE-271 is probably better suited as a category. Both CWE-272 and CWE-250 are in active use by the community. The "least privilege" phrase has multiple interpretations.

Maintenance

The Taxonomy_Mappings to ISA/IEC 62443 were added in CWE 4.10, but they are still under review and might change in future CWE versions. These draft mappings were performed by members of the "Mapping CWE to 62443" subgroup of the CWE-CAPEC ICS/OT Special Interest Group (SIG), and their work is incomplete as of CWE 4.10. The mappings are included to facilitate discussion and review by the broader ICS/OT community, and they are likely to change in future CWE versions.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
7 Pernicious Kingdoms Often Misused: Privilege Management
The CERT Oracle Secure Coding Standard for Java (2011) SER09-J Minimize privileges before deserializing from a privilege context
ISA/IEC 62443 Part 2-4 Req SP.03.05 BR
ISA/IEC 62443 Part 2-4 Req SP.03.08 BR
ISA/IEC 62443 Part 2-4 Req SP.03.08 RE(1)
ISA/IEC 62443 Part 2-4 Req SP.05.07 BR
ISA/IEC 62443 Part 2-4 Req SP.09.02 RE(4)
ISA/IEC 62443 Part 2-4 Req SP.09.03 BR
ISA/IEC 62443 Part 2-4 Req SP.09.04 BR
ISA/IEC 62443 Part 3-3 Req SR 1.1
ISA/IEC 62443 Part 3-3 Req SR 1.2
ISA/IEC 62443 Part 3-3 Req SR 2.1
ISA/IEC 62443 Part 3-3 Req SR 2.1 RE 1
ISA/IEC 62443 Part 4-1 Req SD-4
ISA/IEC 62443 Part 4-2 Req CCSC 3
ISA/IEC 62443 Part 4-2 Req CR 1.1
+ 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-196] Jerome H. Saltzer and Michael D. Schroeder. "The Protection of Information in Computer Systems". Proceedings of the IEEE 63. 1975-09.
<http://web.mit.edu/Saltzer/www/publications/protection/>.
[REF-76] Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14.
<https://web.archive.org/web/20211209014121/https://www.cisa.gov/uscert/bsi/articles/knowledge/principles/least-privilege>. (URL validated: 2023-04-07)
[REF-7] Michael Howard and David LeBlanc. "Writing Secure Code". Chapter 7, "Running with Least Privilege" Page 207. 2nd Edition. Microsoft Press. 2002-12-04.
<https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223>.
[REF-199] NIST. "United States Government Configuration Baseline (USGCB)".
<https://csrc.nist.gov/Projects/United-States-Government-Configuration-Baseline>. (URL validated: 2023-03-28)
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 16: Executing Code With Too Much Privilege." Page 243. McGraw-Hill. 2010.
[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 9, "Privilege Vulnerabilities", Page 477. 1st Edition. Addison Wesley. 2006.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Contributions
Contribution Date Contributor Organization
2023-01-24
(CWE 4.10, 2023-01-31)
"Mapping CWE to 62443" Sub-Working Group CWE-CAPEC ICS/OT SIG
Suggested mappings to ISA/IEC 62443.
2023-04-25 "Mapping CWE to 62443" Sub-Working Group CWE-CAPEC ICS/OT SIG
Suggested mappings to ISA/IEC 62443.
+ Modifications
Modification Date Modifier Organization
2023-10-26 CWE Content Team MITRE
updated Observed_Examples
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2023-01-31 CWE Content Team MITRE
updated Description, Maintenance_Notes, Taxonomy_Mappings
2022-10-13 CWE Content Team MITRE
updated References
2022-04-28 CWE Content Team MITRE
updated Observed_Examples
2020-02-24 CWE Content Team MITRE
updated Applicable_Platforms, Detection_Factors, Observed_Examples, References, Relationships, Type
2019-09-19 CWE Content Team MITRE
updated Demonstrative_Examples
2019-01-03 CWE Content Team MITRE
updated Taxonomy_Mappings
2018-03-27 CWE Content Team MITRE
updated References
2017-11-08 CWE Content Team MITRE
updated Modes_of_Introduction, References, Relationships
2014-07-30 CWE Content Team MITRE
updated Detection_Factors
2014-02-18 CWE Content Team MITRE
updated Demonstrative_Examples
2013-07-17 CWE Content Team MITRE
updated Applicable_Platforms
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2012-05-11 CWE Content Team MITRE
updated References, Related_Attack_Patterns, Relationships
2011-09-13 CWE Content Team MITRE
updated Potential_Mitigations, References, Relationships
2011-06-27 CWE Content Team MITRE
updated Demonstrative_Examples, Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-03-29 CWE Content Team MITRE
updated Relationships
2010-06-21 CWE Content Team MITRE
updated Detection_Factors, Potential_Mitigations
2010-02-16 CWE Content Team MITRE
updated Detection_Factors, Potential_Mitigations, References
2009-05-27 CWE Content Team MITRE
updated Related_Attack_Patterns
2009-03-10 CWE Content Team MITRE
updated Potential_Mitigations
2009-01-12 CWE Content Team MITRE
updated Common_Consequences, Description, Likelihood_of_Exploit, Maintenance_Notes, Name, Observed_Examples, Other_Notes, Potential_Mitigations, Relationships, Time_of_Introduction
2008-10-14 CWE Content Team MITRE
updated Description, Maintenance_Notes
2008-09-08 CWE Content Team MITRE
updated Description, Modes_of_Introduction, Relationships, Other_Notes, Relationship_Notes, Taxonomy_Mappings
+ Previous Entry Names
Change Date Previous Entry Name
2008-01-30 Often Misused: Privilege Management
2009-01-12 Design Principle Violation: Failure to Use Least Privilege

CWE-440: Expected Behavior Violation

Weakness ID: 440
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
A feature, API, or function does not perform according to its specification.
+ Common Consequences
Section HelpThis 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.
Impact Details

Quality Degradation; Varies by Context

Scope: Other

+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 684 Incorrect Provision of Specified Functionality
+ Relevant to the view "Software Development" (View-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 438 Behavioral Problems
+ Relevant to the view "Hardware Design" (View-1194)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1208 Cross-Cutting Problems
+ Modes Of Introduction
Section HelpThe 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
Operation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Class: ICS/OT (Undetermined Prevalence)

+ Demonstrative Examples

Example 1


The provided code is extracted from the Control and Status Register (CSR), csr_regfile, module within the Hack@DAC'21 OpenPiton System-on-Chip (SoC). This module is designed to implement CSR registers in accordance with the RISC-V specification. The mie (machine interrupt enable) register is a 64-bit register [REF-1384], where bits correspond to different interrupt sources. As the name suggests, mie is a machine-level register that determines which interrupts are enabled. Note that in the example below the mie_q and mie_d registers represent the conceptual mie reigster in the RISC-V specification. The mie_d register is the value to be stored in the mie register while the mie_q register holds the current value of the mie register [REF-1385].

The mideleg (machine interrupt delegation) register, also 64-bit wide, enables the delegation of specific interrupt sources from machine privilege mode to lower privilege levels. By setting specific bits in the mideleg register, the handling of certain interrupts can be delegated to lower privilege levels without engaging the machine-level privilege mode. For example, in supervisor mode, the mie register is limited to a specific register called the sie (supervisor interrupt enable) register. If delegated, an interrupt becomes visible in the sip (supervisor interrupt pending) register and can be enabled or blocked using the sie register. If no delegation occurs, the related bits in sip and sie are set to zero.

The sie register value is computed based on the current value of mie register, i.e., mie_q, and the mideleg register.

(bad code)
Example Language: Verilog 
module csr_regfile #(...)(...);
...
// ---------------------------
// CSR Write and update logic
// ---------------------------
...
if (csr_we) begin
unique case (csr_addr.address)
...
riscv::CSR_SIE: begin
// the mideleg makes sure only delegate-able register
//(and therefore also only implemented registers) are written
mie_d = (mie_q & ~mideleg_q) | (csr_wdata & mideleg_q) | utval_q;
end
...
endcase
end
endmodule

The above code snippet illustrates an instance of a vulnerable implementation of the sie register update logic, where users can tamper with the mie_d register value through the utval (user trap value) register. This behavior violates the RISC-V specification.

The code shows that the value of utval, among other signals, is used in updating the mie_d value within the sie update logic. While utval is a register accessible to users, it should not influence or compromise the integrity of sie. Through manipulation of the utval register, it becomes feasible to manipulate the sie register's value. This opens the door for potential attacks, as an adversary can gain control over or corrupt the sie value. Consequently, such manipulation empowers an attacker to enable or disable critical supervisor-level interrupts, resulting in various security risks such as privilege escalation or denial-of-service attacks.

A fix to this issue is to remove the utval from the right-hand side of the assignment. That is the value of the mie_d should be updated as shown in the good code example [REF-1386].

(good code)
Example Language: Verilog 
module csr_regfile #(...)(...);
...
// ---------------------------
// CSR Write and update logic
// ---------------------------
...
if (csr_we) begin
unique case (csr_addr.address)
...
riscv::CSR_SIE: begin
// the mideleg makes sure only delegate-able register
//(and therefore also only implemented registers) are written
mie_d = (mie_q & ~mideleg_q) | (csr_wdata & mideleg_q);
end
...
endcase
end
endmodule


+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
Program uses large timeouts on unconfirmed connections resulting from inconsistency in linked lists implementations.
"strncpy" in Linux kernel acts different than libc on x86, leading to expected behavior difference - sort of a multiple interpretation error?
Buffer overflow in product stems the use of a third party library function that is expected to have internal protection against overflows, but doesn't.
+ Memberships
Section HelpThis 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1001 SFP Secondary Cluster: Use of an Improper API
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1368 ICS Dependencies (& Architecture): External Digital Systems
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1412 Comprehensive Categorization: Poor Coding Practices
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

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

Comments

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

Theoretical

The behavior of an application that is not consistent with the expectations of the developer may lead to incorrect use of the software.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER Expected behavior violation
+ References
[REF-1384] "The RISC-V Instruction Set Manual Volume II: Privileged Architecture page 28". 2021.
<https://riscv.org/wp-content/uploads/2017/05/riscv-privileged-v1.10.pdf>. (URL validated: 2024-01-16)
[REF-1385] "csr_regfile.sv". 2021.
<https://github.com/HACK-EVENT/hackatdac21/blob/b9ecdf6068445d76d6bee692d163fededf7a9d9b/piton/design/chip/tile/ariane/src/csr_regfile.sv>. (URL validated: 2024-01-16)
[REF-1386] "Fix for csr_regfile.sv". 2021.
<https://github.com/HACK-EVENT/hackatdac21/blob/2341c625a28d2fb87d370e32c45b68bd711cc43b/piton/design/chip/tile/ariane/src/csr_regfile.sv#L519C4-L522C20>. (URL validated: 2024-01-16)
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution Date Contributor Organization
2023-06-21 Chen Chen, Rahul Kande, Jeyavijayan Rajendran Texas A&M University
suggested demonstrative example
2023-06-21 Shaza Zeitouni, Mohamadreza Rostami, Ahmad-Reza Sadeghi Technical University of Darmstadt
suggested demonstrative example
+ Modifications
Modification Date Modifier Organization
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Demonstrative_Examples, References
2023-10-26 CWE Content Team MITRE
updated Observed_Examples
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Relationships
2023-01-31 CWE Content Team MITRE
updated Applicable_Platforms, Relationships
2020-08-20 CWE Content Team MITRE
updated Description, Observed_Examples, Theoretical_Notes
2020-02-24 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Relevant_Properties
2014-07-30 CWE Content Team MITRE
updated Relationships
2012-05-11 CWE Content Team MITRE
updated Relationships
2011-06-27 CWE Content Team MITRE
updated Common_Consequences
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2009-10-29 CWE Content Team MITRE
updated Other_Notes, Relevant_Properties, Theoretical_Notes
2008-09-08 CWE Content Team MITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction

CWE-749: Exposed Dangerous Method or Function

Weakness ID: 749
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product provides an Applications Programming Interface (API) or similar interface for interaction with external actors, but the interface includes a dangerous method or function that is not properly restricted.
+ Extended Description

This weakness can lead to a wide variety of resultant weaknesses, depending on the behavior of the exposed method. It can apply to any number of technologies and approaches, such as ActiveX controls, Java functions, IOCTLs, and so on.

The exposure can occur in a few different ways:

  • The function/method was never intended to be exposed to outside actors.
  • The function/method was only intended to be accessible to a limited set of actors, such as Internet-based access from a single web site.
+ Common Consequences
Section HelpThis 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.
Impact Details

Gain Privileges or Assume Identity; Read Application Data; Modify Application Data; Execute Unauthorized Code or Commands; Other

Scope: Integrity, Confidentiality, Availability, Access Control, Other

Exposing critical functionality essentially provides an attacker with the privilege level of the exposed functionality. This could result in the modification or exposure of sensitive data or possibly even execution of arbitrary code.
+ Potential Mitigations
Phase(s) Mitigation

Architecture and Design

If you must expose a method, make sure to perform input validation on all arguments, limit access to authorized parties, and protect against all possible vulnerabilities.

Architecture and Design; Implementation

Strategy: Attack Surface Reduction

Identify all exposed functionality. Explicitly list all functionality that must be exposed to some user or set of users. Identify which functionality may be:

  • accessible to all users
  • restricted to a small set of privileged users
  • prevented from being directly accessible at all

Ensure that the implemented code follows these expectations. This includes setting the appropriate access modifiers where applicable (public, private, protected, etc.) or not marking ActiveX controls safe-for-scripting.

+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Pillar Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things. 284 Improper Access Control
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 618 Exposed Unsafe ActiveX Method
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 782 Exposed IOCTL with Insufficient Access Control
+ Relevant to the view "Software Development" (View-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1228 API / Function Errors
+ Modes Of Introduction
Section HelpThe 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
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Likelihood Of Exploit
Low
+ Demonstrative Examples

Example 1


In the following Java example the method removeDatabase will delete the database with the name specified in the input parameter.

(bad code)
Example Language: Java 
public void removeDatabase(String databaseName) {
try {
Statement stmt = conn.createStatement();
stmt.execute("DROP DATABASE " + databaseName);
} catch (SQLException ex) {...}
}

The method in this example is declared public and therefore is exposed to any class in the application. Deleting a database should be considered a critical operation within an application and access to this potentially dangerous method should be restricted. Within Java this can be accomplished simply by declaring the method private thereby exposing it only to the enclosing class as in the following example.

(good code)
Example Language: Java 
private void removeDatabase(String databaseName) {
try {
Statement stmt = conn.createStatement();
stmt.execute("DROP DATABASE " + databaseName);
} catch (SQLException ex) {...}
}


Example 2


These Android and iOS applications intercept URL loading within a WebView and perform special actions if a particular URL scheme is used, thus allowing the Javascript within the WebView to communicate with the application:

(bad code)
Example Language: Java 
// Android
@Override
public boolean shouldOverrideUrlLoading(WebView view, String url){
if (url.substring(0,14).equalsIgnoreCase("examplescheme:")){
if(url.substring(14,25).equalsIgnoreCase("getUserInfo")){
writeDataToView(view, UserData);
return false;
}
else{
return true;
}
}
}
(bad code)
Example Language: Objective-C 
// iOS
-(BOOL) webView:(UIWebView *)exWebView shouldStartLoadWithRequest:(NSURLRequest *)exRequest navigationType:(UIWebViewNavigationType)exNavigationType
{
NSURL *URL = [exRequest URL];
if ([[URL scheme] isEqualToString:@"exampleScheme"])
{
NSString *functionString = [URL resourceSpecifier];
if ([functionString hasPrefix:@"specialFunction"])
{

// Make data available back in webview.
UIWebView *webView = [self writeDataToView:[URL query]];
}
return NO;
}
return YES;
}

A call into native code can then be initiated by passing parameters within the URL:

(attack code)
Example Language: JavaScript 
window.location = examplescheme://method?parameter=value

Because the application does not check the source, a malicious website loaded within this WebView has the same access to the API as a trusted site.



Example 3


This application uses a WebView to display websites, and creates a Javascript interface to a Java object to allow enhanced functionality on a trusted website:

(bad code)
Example Language: Java 
public class WebViewGUI extends Activity {
WebView mainWebView;

public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
mainWebView = new WebView(this);
mainWebView.getSettings().setJavaScriptEnabled(true);
mainWebView.addJavascriptInterface(new JavaScriptInterface(), "userInfoObject");
mainWebView.loadUrl("file:///android_asset/www/index.html");
setContentView(mainWebView);
}

final class JavaScriptInterface {
JavaScriptInterface () {}

public String getUserInfo() {
return currentUser.Info();
}
}
}

Before Android 4.2 all methods, including inherited ones, are exposed to Javascript when using addJavascriptInterface(). This means that a malicious website loaded within this WebView can use reflection to acquire a reference to arbitrary Java objects. This will allow the website code to perform any action the parent application is authorized to.

For example, if the application has permission to send text messages:

(attack code)
Example Language: JavaScript 
<script>
userInfoObject.getClass().forName('android.telephony.SmsManager').getMethod('getDefault',null).sendTextMessage(attackNumber, null, attackMessage, null, null);
</script>

This malicious script can use the userInfoObject object to load the SmsManager object and send arbitrary text messages to any recipient.



Example 4


After Android 4.2, only methods annotated with @JavascriptInterface are available in JavaScript, protecting usage of getClass() by default, as in this example:

(bad code)
Example Language: Java 
final class JavaScriptInterface {
JavaScriptInterface () { }

@JavascriptInterface
public String getUserInfo() {
return currentUser.Info();
}
}

This code is not vulnerable to the above attack, but still may expose user info to malicious pages loaded in the WebView. Even malicious iframes loaded within a trusted page may access the exposed interface:

(attack code)
Example Language: JavaScript 
<script>
var info = window.userInfoObject.getUserInfo();
sendUserInfo(info);
</script>

This malicious code within an iframe is able to access the interface object and steal the user's data.



+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
arbitrary Java code execution via exposed method
security tool ActiveX control allows download or upload of files
+ Weakness Ordinalities
Ordinality Description
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods
Method Details

Automated Static Analysis

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

Effectiveness: High

+ Memberships
Section HelpThis 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 808 2010 Top 25 - Weaknesses On the Cusp
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 975 SFP Secondary Cluster: Architecture
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1416 Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

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

Comments

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

Research Gap

Under-reported and under-studied. This weakness could appear in any technology, language, or framework that allows the programmer to provide a functional interface to external parties, but it is not heavily reported. In 2007, CVE began showing a notable increase in reports of exposed method vulnerabilities in ActiveX applications, as well as IOCTL access to OS-level resources. These weaknesses have been documented for Java applications in various secure programming sources, but there are few reports in CVE, which suggests limited awareness in most parts of the vulnerability research community.
+ References
[REF-503] Microsoft. "Developing Secure ActiveX Controls". 2005-04-13.
<https://learn.microsoft.com/en-us/previous-versions//ms533046(v=vs.85)?redirectedfrom=MSDN>. (URL validated: 2023-04-07)
[REF-510] Microsoft. "How to stop an ActiveX control from running in Internet Explorer".
<https://support.microsoft.com/en-us/help/240797/how-to-stop-an-activex-control-from-running-in-internet-explorer>. (URL validated: 2023-04-07)
+ Content History
+ Submissions
Submission Date Submitter Organization
2008-11-24
(CWE 1.1, 2008-11-24)
CWE Content Team MITRE
+ Modifications
Modification Date Modifier Organization
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Detection_Factors, References, Relationships
2023-01-31 CWE Content Team MITRE
updated Description, Related_Attack_Patterns, Relationships
2020-02-24 CWE Content Team MITRE
updated Relationships
2019-06-20 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Likelihood_of_Exploit, References, Relationships
2015-12-07 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships
2014-02-18 CWE Content Team MITRE
updated Demonstrative_Examples
2012-05-11 CWE Content Team MITRE
updated Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2010-06-21 CWE Content Team MITRE
updated Common_Consequences
2010-04-05 CWE Content Team MITRE
updated Demonstrative_Examples, Related_Attack_Patterns
2010-02-16 CWE Content Team MITRE
updated Common_Consequences, Demonstrative_Examples, Potential_Mitigations, References, Related_Attack_Patterns, Relationships
2009-12-28 CWE Content Team MITRE
updated Applicable_Platforms, Likelihood_of_Exploit
2009-07-27 CWE Content Team MITRE
updated Relationships
2009-01-12 CWE Content Team MITRE
updated Name
+ Previous Entry Names
Change Date Previous Entry Name
2009-01-12 Exposed Insecure Method or Function

CWE-359: Exposure of Private Personal Information to an Unauthorized Actor

Weakness ID: 359
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product does not properly prevent a person's private, personal information from being accessed by actors who either (1) are not explicitly authorized to access the information or (2) do not have the implicit consent of the person about whom the information is collected. Diagram for CWE-359
+ Alternate Terms
Privacy violation
Privacy leak
Privacy leakage
+ Common Consequences
Section HelpThis 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.
Impact Details

Read Application Data

Scope: Confidentiality

+ Potential Mitigations
Phase(s) Mitigation

Requirements

Identify and consult all relevant regulations for personal privacy. An organization may be required to comply with certain federal and state regulations, depending on its location, the type of business it conducts, and the nature of any private data it handles. Regulations may include Safe Harbor Privacy Framework [REF-340], Gramm-Leach Bliley Act (GLBA) [REF-341], Health Insurance Portability and Accountability Act (HIPAA) [REF-342], General Data Protection Regulation (GDPR) [REF-1047], California Consumer Privacy Act (CCPA) [REF-1048], and others.

Architecture and Design

Carefully evaluate how secure design may interfere with privacy, and vice versa. Security and privacy concerns often seem to compete with each other. From a security perspective, all important operations should be recorded so that any anomalous activity can later be identified. However, when private data is involved, this practice can in fact create risk. Although there are many ways in which private data can be handled unsafely, a common risk stems from misplaced trust. Programmers often trust the operating environment in which a program runs, and therefore believe that it is acceptable store private information on the file system, in the registry, or in other locally-controlled resources. However, even if access to certain resources is restricted, this does not guarantee that the individuals who do have access can be trusted.

+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 200 Exposure of Sensitive Information to an Unauthorized Actor
+ Relevant to the view "Software Development" (View-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 199 Information Management Errors
+ Relevant to the view "Architectural Concepts" (View-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1011 Authorize Actors
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Implementation
Operation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Class: Mobile (Undetermined Prevalence)

+ Demonstrative Examples

Example 1


The following code contains a logging statement that tracks the contents of records added to a database by storing them in a log file. Among other values that are stored, the getPassword() function returns the user-supplied plaintext password associated with the account.

(bad code)
Example Language: C# 
pass = GetPassword();
...
dbmsLog.WriteLine(id + ":" + pass + ":" + type + ":" + tstamp);

The code in the example above logs a plaintext password to the filesystem. Although many developers trust the filesystem as a safe storage location for data, it should not be trusted implicitly, particularly when privacy is a concern.



Example 2


This code uses location to determine the user's current US State location.

First the application must declare that it requires the ACCESS_FINE_LOCATION permission in the application's manifest.xml:

(bad code)
Example Language: XML 
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>

During execution, a call to getLastLocation() will return a location based on the application's location permissions. In this case the application has permission for the most accurate location possible:

(bad code)
Example Language: Java 
locationClient = new LocationClient(this, this, this);
locationClient.connect();
Location userCurrLocation;
userCurrLocation = locationClient.getLastLocation();
deriveStateFromCoords(userCurrLocation);

While the application needs this information, it does not need to use the ACCESS_FINE_LOCATION permission, as the ACCESS_COARSE_LOCATION permission will be sufficient to identify which US state the user is in.



Example 3


In 2004, an employee at AOL sold approximately 92 million private customer e-mail addresses to a spammer marketing an offshore gambling web site [REF-338]. In response to such high-profile exploits, the collection and management of private data is becoming increasingly regulated.



+ Detection Methods
Method Details

Architecture or Design Review

Private personal data can enter a program in a variety of ways:

  • Directly from the user in the form of a password or personal information
  • Accessed from a database or other data store by the application
  • Indirectly from a partner or other third party

If the data is written to an external location - such as the console, file system, or network - a privacy violation may occur.

Effectiveness: High

Automated Static Analysis

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

Effectiveness: High

+ Memberships
Section HelpThis 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 254 7PK - Security Features
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 857 The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO)
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 975 SFP Secondary Cluster: Architecture
MemberOf CategoryCategory - 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1147 SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO)
MemberOf ViewView - 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 CategoryCategory - 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1417 Comprehensive Categorization: Sensitive Information Exposure
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

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

Comments

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

Other

There are many types of sensitive information that products must protect from attackers, including system data, communications, configuration, business secrets, intellectual property, and an individual's personal (private) information. Private personal information may include a password, phone number, geographic location, personal messages, credit card number, etc. Private information is important to consider whether the person is a user of the product, or part of a data set that is processed by the product. An exposure of private information does not necessarily prevent the product from working properly, and in fact the exposure might be intended by the developer, e.g. as part of data sharing with other organizations. However, the exposure of personal private information can still be undesirable or explicitly prohibited by law or regulation.

Some types of private information include:

  • Government identifiers, such as Social Security Numbers
  • Contact information, such as home addresses and telephone numbers
  • Geographic location - where the user is (or was)
  • Employment history
  • Financial data - such as credit card numbers, salary, bank accounts, and debts
  • Pictures, video, or audio
  • Behavioral patterns - such as web surfing history, when certain activities are performed, etc.
  • Relationships (and types of relationships) with others - family, friends, contacts, etc.
  • Communications - e-mail addresses, private messages, text messages, chat logs, etc.
  • Health - medical conditions, insurance status, prescription records
  • Account passwords and other credentials

Some of this information may be characterized as PII (Personally Identifiable Information), Protected Health Information (PHI), etc. Categories of private information may overlap or vary based on the intended usage or the policies and practices of a particular industry.

Sometimes data that is not labeled as private can have a privacy implication in a different context. For example, student identification numbers are usually not considered private because there is no explicit and publicly-available mapping to an individual student's personal information. However, if a school generates identification numbers based on student social security numbers, then the identification numbers should be considered private.

Maintenance

This entry overlaps many other entries that are not organized around the kind of sensitive information that is exposed. However, because privacy is treated with such importance due to regulations and other factors, and it may be useful for weakness-finding tools to highlight capabilities that detect personal private information instead of system information, it is not clear whether - and how - this entry should be deprecated.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
7 Pernicious Kingdoms Privacy Violation
The CERT Oracle Secure Coding Standard for Java (2011) FIO13-J Do not log sensitive information outside a trust boundary
+ 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-338] J. Oates. "AOL man pleads guilty to selling 92m email addies". The Register. 2005.
<https://www.theregister.com/2005/02/07/aol_email_theft/>. (URL validated: 2023-04-07)
[REF-339] NIST. "Guide to Protecting the Confidentiality of Personally Identifiable Information (SP 800-122)". 2010-04.
<https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-122.pdf>. (URL validated: 2023-04-07)
[REF-340] U.S. Department of Commerce. "Safe Harbor Privacy Framework".
<https://web.archive.org/web/20010223203241/http://www.export.gov/safeharbor/>. (URL validated: 2023-04-07)
[REF-341] Federal Trade Commission. "Financial Privacy: The Gramm-Leach Bliley Act (GLBA)".
<https://www.ftc.gov/business-guidance/privacy-security/gramm-leach-bliley-act>. (URL validated: 2023-04-07)
[REF-342] U.S. Department of Human Services. "Health Insurance Portability and Accountability Act (HIPAA)".
<https://www.hhs.gov/hipaa/index.html>. (URL validated: 2023-04-07)
[REF-343] Government of the State of California. "California SB-1386". 2002.
<http://info.sen.ca.gov/pub/01-02/bill/sen/sb_1351-1400/sb_1386_bill_20020926_chaptered.html>.
[REF-267] Information Technology Laboratory, National Institute of Standards and Technology. "SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES". 2001-05-25.
<https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402.pdf>. (URL validated: 2023-04-07)
[REF-172] Chris Wysopal. "Mobile App Top 10 List". 2010-12-13.
<https://www.veracode.com/blog/2010/12/mobile-app-top-10-list>. (URL validated: 2023-04-07)
[REF-1047] Wikipedia. "General Data Protection Regulation".
<https://en.wikipedia.org/wiki/General_Data_Protection_Regulation>.
[REF-1048] State of California Department of Justice, Office of the Attorney General. "California Consumer Privacy Act (CCPA)".
<https://oag.ca.gov/privacy/ccpa>.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification Date Modifier Organization
2024-11-19
(CWE 4.16, 2024-11-19)
CWE Content Team MITRE
updated Description, Diagram, Other_Notes
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Detection_Factors, References, Relationships
2023-01-31 CWE Content Team MITRE
updated Related_Attack_Patterns
2021-10-28 CWE Content Team MITRE
updated Relationships
2021-03-15 CWE Content Team MITRE
updated References
2020-12-10 CWE Content Team MITRE
updated Relationships
2020-08-20 CWE Content Team MITRE
updated Related_Attack_Patterns
2020-02-24 CWE Content Team MITRE
updated Alternate_Terms, Applicable_Platforms, Demonstrative_Examples, Description, Detection_Factors, Maintenance_Notes, Name, Potential_Mitigations, References, Relationships, Type
2019-01-03 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2018-03-27 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Modes_of_Introduction, References, Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships
2014-02-18 CWE Content Team MITRE
updated Alternate_Terms, Demonstrative_Examples, Description, Name, Other_Notes, References
2013-02-21 CWE Content Team MITRE
updated Applicable_Platforms, References
2012-05-11 CWE Content Team MITRE
updated Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2011-09-13 CWE Content Team MITRE
updated Other_Notes, References
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-03-29 CWE Content Team MITRE
updated Other_Notes
2010-02-16 CWE Content Team MITRE
updated Other_Notes, References
2009-12-28 CWE Content Team MITRE
updated Other_Notes, References
2009-07-27 CWE Content Team MITRE
updated Demonstrative_Examples
2009-03-10 CWE Content Team MITRE
updated Other_Notes
2008-09-08 CWE Content Team MITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
+ Previous Entry Names
Change Date Previous Entry Name
2014-02-18 Privacy Violation
2020-02-24 Exposure of Private Information ('Privacy Violation')

CWE-668: Exposure of Resource to Wrong Sphere

Weakness ID: 668
Vulnerability Mapping: DISCOURAGED This CWE ID should not be used to map to real-world vulnerabilities
Abstraction: Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


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

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

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

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

+ Common Consequences
Section HelpThis 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.
Impact Details

Read Application Data

Scope: Confidentiality

Likelihood: High

An adversary that gains access to a resource exposed to a wrong sphere could potentially retrieve private data from that resource, thus breaking the intended confidentiality of that data.

Modify Application Data

Scope: Integrity

Likelihood: Medium

An adversary that gains access to a resource exposed to a wrong sphere could potentially modify data held within that resource, thus breaking the intended integrity of that data and causing the system relying on that resource to make unintended decisions.

Varies by Context

Scope: Other

The consequences may vary widely depending on how the product uses the affected resource.
+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Pillar Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things. 664 Improper Control of a Resource Through its Lifetime
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 8 J2EE Misconfiguration: Entity Bean Declared Remote
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 134 Use of Externally-Controlled Format String
ParentOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 200 Exposure of Sensitive Information to an Unauthorized Actor
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 374 Passing Mutable Objects to an Untrusted Method
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 375 Returning a Mutable Object to an Untrusted Caller
ParentOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 377 Insecure Temporary File
ParentOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 402 Transmission of Private Resources into a New Sphere ('Resource Leak')
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 427 Uncontrolled Search Path Element
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 428 Unquoted Search Path or Element
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 488 Exposure of Data Element to Wrong Session
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 491 Public cloneable() Method Without Final ('Object Hijack')
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 492 Use of Inner Class Containing Sensitive Data
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 493 Critical Public Variable Without Final Modifier
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 498 Cloneable Class Containing Sensitive Information
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 499 Serializable Class Containing Sensitive Data
ParentOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 522 Insufficiently Protected Credentials
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 524 Use of Cache Containing Sensitive Information
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 552 Files or Directories Accessible to External Parties
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 582 Array Declared Public, Final, and Static
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 583 finalize() Method Declared Public
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 608 Struts: Non-private Field in ActionForm Class
ParentOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 642 External Control of Critical State Data
ParentOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 732 Incorrect Permission Assignment for Critical Resource
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 767 Access to Critical Private Variable via Public Method
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 927 Use of Implicit Intent for Sensitive Communication
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1189 Improper Isolation of Shared Resources on System-on-a-Chip (SoC)
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1282 Assumed-Immutable Data is Stored in Writable Memory
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1327 Binding to an Unrestricted IP Address
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1331 Improper Isolation of Shared Resources in Network On Chip (NoC)
CanFollow Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
CanFollow Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 441 Unintended Proxy or Intermediary ('Confused Deputy')
CanFollow Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 942 Permissive Cross-domain Policy with Untrusted Domains
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Nature Type ID Name
MemberOf View View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1003 Weaknesses for Simplified Mapping of Published Vulnerabilities
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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" (View-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1011 Authorize Actors
+ Modes Of Introduction
Section HelpThe 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 REALIZATION: This weakness is caused during implementation of an architectural security tactic.
Operation
+ Memberships
Section HelpThis 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 963 SFP Secondary Cluster: Exposed Data
MemberOf CategoryCategory - 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1364 ICS Communications: Zone Boundary Failures
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1403 Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes
Usage DISCOURAGED
(this CWE ID should not be used to map to real-world vulnerabilities)
Reasons Frequent Misuse, Abstraction

Rationale

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

Comments

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

Theoretical

A "control sphere" is a set of resources and behaviors that are accessible to a single actor, or a group of actors. A product's security model will typically define multiple spheres, possibly implicitly. For example, a server might define one sphere for "administrators" who can create new user accounts with subdirectories under /home/server/, and a second sphere might cover the set of users who can create or delete files within their own subdirectories. A third sphere might be "users who are authenticated to the operating system on which the product is installed." Each sphere has different sets of actors and allowable behaviors.
+ References
[REF-1287] MITRE. "Supplemental Details - 2022 CWE Top 25". Details of Problematic Mappings. 2022-06-28.
<https://cwe.mitre.org/top25/archive/2022/2022_cwe_top25_supplemental.html#problematicMappingDetails>. (URL validated: 2024-11-17)
+ Content History
+ Submissions
Submission Date Submitter Organization
2008-04-11
(CWE Draft 9, 2008-04-11)
CWE Content Team MITRE
+ Modifications
Modification Date Modifier Organization
2025-04-03
(CWE 4.17, 2025-04-03)
CWE Content Team MITRE
updated Common_Consequences, Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Relationships
2022-10-13 CWE Content Team MITRE
updated References
2022-04-28 CWE Content Team MITRE
updated Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2021-03-15 CWE Content Team MITRE
updated Relationships
2020-06-25 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Relationships
2019-06-20 CWE Content Team MITRE
updated Relationships
2019-01-03 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Modes_of_Introduction, Relationships, Relevant_Properties
2017-01-19 CWE Content Team MITRE
updated Relationships
2015-12-07 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships
2014-06-23 CWE Content Team MITRE
updated Relationships
2013-07-17 CWE Content Team MITRE
updated Relationships
2013-02-21 CWE Content Team MITRE
updated Relationships
2012-05-11 CWE Content Team MITRE
updated Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2011-03-29 CWE Content Team MITRE
updated Relationships
2010-09-27 CWE Content Team MITRE
updated Relationships
2009-12-28 CWE Content Team MITRE
updated Relationships
2009-10-29 CWE Content Team MITRE
updated Other_Notes, Theoretical_Notes
2009-07-27 CWE Content Team MITRE
updated Description, Relationships
2009-07-22 CWE Content Team MITRE
Clarified description to include permissions.
2009-05-27 CWE Content Team MITRE
updated Relationships
2008-11-24 CWE Content Team MITRE
updated Relationships
2008-09-08 CWE Content Team MITRE
updated Relationships, Other_Notes
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction

CWE-1422: Exposure of Sensitive Information caused by Incorrect Data Forwarding during Transient Execution

Weakness ID: 1422
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
A processor event or prediction may allow incorrect or stale data to be forwarded to transient operations, potentially exposing data over a covert channel.
+ Extended Description

Software may use a variety of techniques to preserve the confidentiality of private data that is accessible within the current processor context. For example, the memory safety and type safety properties of some high-level programming languages help to prevent software written in those languages from exposing private data. As a second example, software sandboxes may co-locate multiple users' software within a single process. The processor's Instruction Set Architecture (ISA) may permit one user's software to access another user's data (because the software shares the same address space), but the sandbox prevents these accesses by using software techniques such as bounds checking.

If incorrect or stale data can be forwarded (for example, from a cache) to transient operations, then the operations' microarchitectural side effects may correspond to the data. If an attacker can trigger these transient operations and observe their side effects through a covert channel, then the attacker may be able to infer the data. For example, an attacker process may induce transient execution in a victim process that causes the victim to inadvertently access and then expose its private data via a covert channel. In the software sandbox example, an attacker sandbox may induce transient execution in its own code, allowing it to transiently access and expose data in a victim sandbox that shares the same address space.

Consequently, weaknesses that arise from incorrect/stale data forwarding might violate users' expectations of software-based memory safety and isolation techniques. If the data forwarding behavior is not properly documented by the hardware vendor, this might violate the software vendor's expectation of how the hardware should behave.

+ Common Consequences
Section HelpThis 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.
Impact Details

Read Memory

Scope: Confidentiality

Likelihood: Medium

+ Potential Mitigations
Phase(s) Mitigation

Architecture and Design

The hardware designer can attempt to prevent transient execution from causing observable discrepancies in specific covert channels.

Effectiveness: Limited

Note: Instructions or features that constrain transient execution or suppress its side effects may impact performance.

Requirements

Processor designers, system software vendors, or other agents may choose to restrict the ability of unprivileged software to access to high-resolution timers that are commonly used to monitor covert channels.

Effectiveness: Defense in Depth

Note: Disabling specific predictors or other hardware features may result in significant performance overhead.

Requirements

Processor designers may expose instructions or other architectural features that allow software to mitigate the effects of transient execution, but without disabling predictors. These features may also help to limit opportunities for data exposure.

Effectiveness: Moderate

Note:

Instructions or features that constrain transient execution or suppress its side effects may impact performance.

Requirements

Processor designers may expose registers (for example, control registers or model-specific registers) that allow privileged and/or user software to disable specific predictors or other hardware features that can cause confidential data to be exposed during transient execution.

Effectiveness: Limited

Note:

Disabling specific predictors or other hardware features may result in significant performance overhead.

Build and Compilation

Use software techniques (including the use of serialization instructions) that are intended to reduce the number of instructions that can be executed transiently after a processor event or misprediction.

Effectiveness: Incidental

Note:

Some transient execution weaknesses can be exploited even if a single instruction is executed transiently after a processor event or mis-prediction. This mitigation strategy has many other pitfalls that prevent it from eliminating this weakness entirely. For example, see [REF-1389].

Build and Compilation

Isolate sandboxes or managed runtimes in separate address spaces (separate processes).

Effectiveness: High

Note:

Process isolation is also an effective strategy to mitigate many other kinds of weaknesses.

Build and Compilation

Include serialization instructions (for example, LFENCE) that prevent processor events or mis-predictions prior to the serialization instruction from causing transient execution after the serialization instruction. For some weaknesses, a serialization instruction can also prevent a processor event or a mis-prediction from occurring after the serialization instruction (for example, CVE-2018-3639 can allow a processor to predict that a load will not depend on an older store; a serialization instruction between the store and the load may allow the store to update memory and prevent the mis-prediction from happening at all).

Effectiveness: Moderate

Note:

When used to comprehensively mitigate a transient execution weakness, serialization instructions can introduce significant performance overhead.

Build and Compilation

Use software techniques that can mitigate the consequences of transient execution. For example, address masking can be used in some circumstances to prevent out-of-bounds transient reads.

Effectiveness: Limited

Note:

Address masking and related software mitigation techniques have been used to harden specific code sequences that could potentially be exploited via transient execution. For example, the Linux kernel makes limited use of this technique to mitigate bounds-check bypass [REF-1390].

Build and Compilation

If the weakness is exposed by a single instruction (or a small set of instructions), then the compiler (or JIT, etc.) can be configured to prevent the affected instruction(s) from being generated, and instead generate an alternate sequence of instructions that is not affected by the weakness.

Effectiveness: Limited

Note:

This technique is only effective for software that is compiled with this mitigation.

Documentation

If a hardware feature can allow incorrect or stale data to be forwarded to transient operations, the hardware designer may opt to disclose this behavior in architecture documentation. This documentation can inform users about potential consequences and effective mitigations.

Effectiveness: High

+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1420 Exposure of Sensitive Information during Transient Execution
+ Relevant to the view "Hardware Design" (View-1194)
Nature Type ID Name
ChildOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1420 Exposure of Sensitive Information during Transient Execution
+ Modes Of Introduction
Section HelpThe 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

This weakness can be introduced by data speculation techniques, or when the processor pipeline is designed to check exception conditions concurrently with other operations. This weakness can also persist after a CWE-1421 weakness has been mitigated. For example, suppose that a processor can forward stale data from a shared microarchitectural buffer to dependent transient operations, and furthermore suppose that the processor has been patched to flush the buffer on context switches. This mitigates the CWE-1421 weakness, but the stale-data forwarding behavior may persist as a CWE-1422 weakness unless this behavior is also patched.

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

Class: Not Language-Specific (Undetermined Prevalence)

Operating Systems

Class: Not OS-Specific (Undetermined Prevalence)

Architectures

Class: Not Architecture-Specific (Undetermined Prevalence)

Technologies

Class: Not Technology-Specific (Undetermined Prevalence)

+ Demonstrative Examples

Example 1


Faulting loads in a victim domain may trigger incorrect transient forwarding, which leaves secret-dependent traces in the microarchitectural state. Consider this code sequence example from [REF-1391].

(bad code)
Example Language:

void call_victim(size_t untrusted_arg) {
*arg_copy = untrusted_arg;
array[**trusted_ptr * 4096];
}

A processor with this weakness will store the value of untrusted_arg (which may be provided by an attacker) to the stack, which is trusted memory. Additionally, this store operation will save this value in some microarchitectural buffer, for example, the store buffer.

In this code sequence, trusted_ptr is dereferenced while the attacker forces a page fault. The faulting load causes the processor to mis-speculate by forwarding untrusted_arg as the (transient) load result. The processor then uses untrusted_arg for the pointer dereference. After the fault has been handled and the load has been re-issued with the correct argument, secret-dependent information stored at the address of trusted_ptr remains in microarchitectural state and can be extracted by an attacker using a vulnerable code sequence.



Example 2


Some processors try to predict when a store will forward data to a subsequent load, even when the address of the store or the load is not yet known. For example, on Intel processors this feature is called a Fast Store Forwarding Predictor [REF-1392], and on AMD processors the feature is called Predictive Store Forwarding [REF-1393]. A misprediction can cause incorrect or stale data to be forwarded from a store to a load, as illustrated in the following code snippet from [REF-1393]:

(bad code)
Example Language:

void fn(int idx) {
unsigned char v;
idx_array[0] = 4096;
v = array[idx_array[idx] * (idx)];
}

In this example, assume that the parameter idx can only be 0 or 1, and assume that idx_array initially contains all 0s. Observe that the assignment to v in line 4 will be array[0], regardless of whether idx=0 or idx=1. Now suppose that an attacker repeatedly invokes fn with idx=0 to train the store forwarding predictor to predict that the store in line 3 will forward the data 4096 to the load idx_array[idx] in line 4. Then, when the attacker invokes fn with idx=1 the predictor may cause idx_array[idx] to transiently produce the incorrect value 4096, and therefore v will transiently be assigned the value array[4096], which otherwise would not have been accessible in line 4.

Although this toy example is benign (it doesn't transmit array[4096] over a covert channel), an attacker may be able to use similar techniques to craft and train malicious code sequences to, for example, read data beyond a software sandbox boundary.



+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
A fault, microcode assist, or abort may allow transient load operations to forward malicious stale data to dependent operations executed by a victim, causing the victim to unintentionally access and potentially expose its own data over a covert channel.
A fast store forwarding predictor may allow store operations to forward incorrect data to transient load operations, potentially exposing data over a covert channel.
+ Detection Methods
Method Details

Automated Static Analysis

A variety of automated static analysis tools can identify potentially exploitable code sequences in software. These tools may perform the analysis on source code, on binary code, or on an intermediate code representation (for example, during compilation).

Effectiveness: Moderate

Note:Automated static analysis may not reveal all weaknesses in a processor specification and should be combined with other detection methods to improve coverage.

Manual Analysis

This weakness can be detected in hardware by manually inspecting processor specifications. Features that exhibit this weakness may include microarchitectural predictors, access control checks that occur out-of-order, or any other features that can allow operations to execute without committing to architectural state.Hardware designers can also scrutinize aspects of the instruction set architecture that have undefined behavior; these can become a focal point when applying other detection methods.

Effectiveness: Moderate

Note:Manual analysis may not reveal all weaknesses in a processor specification and should be combined with other detection methods to improve coverage.

Automated Analysis

Software vendors can release tools that detect presence of known weaknesses on a processor. For example, some of these tools can attempt to transiently execute a vulnerable code sequence and detect whether code successfully leaks data in a manner consistent with the weakness under test. Alternatively, some hardware vendors provide enumeration for the presence of a weakness (or lack of a weakness). These enumeration bits can be checked and reported by system software. For example, Linux supports these checks for many commodity processors:

$ cat /proc/cpuinfo | grep bugs | head -n 1

bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa itlb_multihit srbds mmio_stale_data retbleed

Effectiveness: High

Note:This method can be useful for detecting whether a processor if affected by known weaknesses, but it may not be useful for detecting unknown weaknesses.
+ Memberships
Section HelpThis 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1416 Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

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

Comments

Use only when the weakness arises from forwarding of incorrect/stale data, and the data is not architecturally restricted (that is, the forwarded data is accessible within the current processor context).

If a weakness arises from forwarding of incorrect/stale data that is not accessible within the current processor context, then CWE-1421 may be more appropriate for the mapping task.

+ References
[REF-1389] Alyssa Milburn, Ke Sun and Henrique Kawakami. "You Cannot Always Win the Race: Analyzing the LFENCE/JMP Mitigation for Branch Target Injection". 2022-03-08.
<https://arxiv.org/abs/2203.04277>. (URL validated: 2024-02-22)
[REF-1390] The kernel development community. "Speculation". 2020-08-16.
<https://docs.kernel.org/6.6/staging/speculation.html>. (URL validated: 2024-02-04)
[REF-1391] Jo Van Bulck, Daniel Moghimi, Michael Schwarz, Moritz Lipp, Marina Minkin, Daniel Genkin, Yuval Yarom, Berk Sunar, Daniel Gruss and Frank Piessens. "LVI : Hijacking Transient Execution through Microarchitectural Load Value Injection". 2020-01-09.
<https://lviattack.eu/lvi.pdf>. (URL validated: 2024-02-04)
[REF-1392] Intel Corporation. "Fast Store Forwarding Predictor". 2022-02-08.
<https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/fast-store-forwarding-predictor.html>. (URL validated: 2024-02-04)
[REF-1393] AMD. "Security Analysis Of AMD Predictive Store Forwarding". 2021-03.
<https://www.amd.com/system/files/documents/security-analysis-predictive-store-forwarding.pdf>. (URL validated: 2024-02-04)
+ Content History
+ Submissions
Submission Date Submitter Organization
2023-09-19
(CWE 4.14, 2024-02-29)
Scott D. Constable Intel Corporation
+ Contributions
Contribution Date Contributor Organization
2024-01-22
(CWE 4.14, 2024-02-29)
David Kaplan AMD
Member of Microarchitectural Weaknesses Working Group
2024-01-22
(CWE 4.14, 2024-02-29)
Rafael Dossantos, Abraham Fernandez Rubio, Alric Althoff, Lyndon Fawcett Arm
Members of Microarchitectural Weaknesses Working Group
2024-01-22
(CWE 4.14, 2024-02-29)
Jason Oberg Cycuity
Member of Microarchitectural Weaknesses Working Group
2024-01-22
(CWE 4.14, 2024-02-29)
Priya B. Iyer Intel Corporation
Member of Microarchitectural Weaknesses Working Group
2024-01-22
(CWE 4.14, 2024-02-29)
Nicole Fern Riscure
Member of Microarchitectural Weaknesses Working Group

CWE-1423: Exposure of Sensitive Information caused by Shared Microarchitectural Predictor State that Influences Transient Execution

Weakness ID: 1423
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
Shared microarchitectural predictor state may allow code to influence transient execution across a hardware boundary, potentially exposing data that is accessible beyond the boundary over a covert channel.
+ Extended Description

Many commodity processors have Instruction Set Architecture (ISA) features that protect software components from one another. These features can include memory segmentation, virtual memory, privilege rings, trusted execution environments, and virtual machines, among others. For example, virtual memory provides each process with its own address space, which prevents processes from accessing each other's private data. Many of these features can be used to form hardware-enforced security boundaries between software components.

When separate software components (for example, two processes) share microarchitectural predictor state across a hardware boundary, code in one component may be able to influence microarchitectural predictor behavior in another component. If the predictor can cause transient execution, the shared predictor state may allow an attacker to influence transient execution in a victim, and in a manner that could allow the attacker to infer private data from the victim by monitoring observable discrepancies (CWE-203) in a covert channel [REF-1400].

Predictor state may be shared when the processor transitions from one component to another (for example, when a process makes a system call to enter the kernel). Many commodity processors have features which prevent microarchitectural predictions that occur before a boundary from influencing predictions that occur after the boundary.

Predictor state may also be shared between hardware threads, for example, sibling hardware threads on a processor that supports simultaneous multithreading (SMT). This sharing may be benign if the hardware threads are simultaneously executing in the same software component, or it could expose a weakness if one sibling is a malicious software component, and the other sibling is a victim software component. Processors that share microarchitectural predictors between hardware threads may have features which prevent microarchitectural predictions that occur on one hardware thread from influencing predictions that occur on another hardware thread.

Features that restrict predictor state sharing across transitions or between hardware threads may be always-on, on by default, or may require opt-in from software.

+ Common Consequences
Section HelpThis 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.
Impact Details

Read Memory

Scope: Confidentiality

Likelihood: Medium

+ Potential Mitigations
Phase(s) Mitigation

Architecture and Design

The hardware designer can attempt to prevent transient execution from causing observable discrepancies in specific covert channels.

Architecture and Design

Hardware designers may choose to use microarchitectural bits to tag predictor entries. For example, each predictor entry may be tagged with a kernel-mode bit which, when set, indicates that the predictor entry was created in kernel mode. The processor can use this bit to enforce that predictions in the current mode must have been trained in the current mode. This can prevent malicious cross-mode training, such as when user-mode software attempts to create predictor entries that influence transient execution in the kernel. Predictor entry tags can also be used to associate each predictor entry with the SMT thread that created it, and thus the processor can enforce that each predictor entry can only be used by the SMT thread that created it. This can prevent an SMT thread from using predictor entries crafted by a malicious sibling SMT thread.

Effectiveness: Moderate

Note:

Tagging can be highly effective for predictor state that is comprised of discrete elements, such as an array of recently visited branch targets. Predictor state can also have different representations that are not conducive to tagging. For example, some processors keep a compressed digest of branch history which does not contain discrete elements that can be individually tagged.

Architecture and Design

Hardware designers may choose to sanitize microarchitectural predictor state (for example, branch prediction history) when the processor transitions to a different context, for example, whenever a system call is invoked. Alternatively, the hardware may expose instruction(s) that allow software to sanitize predictor state according to the user's threat model. For example, this can allow operating system software to sanitize predictor state when performing a context switch from one process to another.

Effectiveness: Moderate

Note:

This technique may not be able to mitigate weaknesses that arise from predictor state that is shared across SMT threads. Sanitizing predictor state on context switches may also negatively impact performance, either by removing predictor entries that could be reused when returning to the previous context, or by slowing down the context switch itself.

Implementation

System software can mitigate this weakness by invoking predictor-state-sanitizing operations (for example, the indirect branch prediction barrier on Intel x86) when switching from one context to another, according to the hardware vendor's recommendations.

Effectiveness: Moderate

Note:

This technique may not be able to mitigate weaknesses that arise from predictor state shared across SMT threads. Sanitizing predictor state may also negatively impact performance in some circumstances.

Build and Compilation

If the weakness is exposed by a single instruction (or a small set of instructions), then the compiler (or JIT, etc.) can be configured to prevent the affected instruction(s) from being generated. One prominent example of this mitigation is retpoline ([REF-1414]).

Effectiveness: Limited

Note:

This technique is only effective for software that is compiled with this mitigation. Additionally, an alternate instruction sequence may mitigate the weakness on some processors but not others, even when the processors share the same ISA. For example, retpoline has been documented as effective on some x86 processors, but not fully effective on other x86 processors.

Build and Compilation

Use control-flow integrity (CFI) techniques to constrain the behavior of instructions that redirect the instruction pointer, such as indirect branch instructions.

Effectiveness: Moderate

Note:

Some CFI techniques may not be able to constrain transient execution, even though they are effective at constraining architectural execution. Or they may be able to provide some additional protection against a transient execution weakness, but without comprehensively mitigating the weakness. For example, Clang-CFI provides strong architectural CFI properties and can make some transient execution weaknesses more difficult to exploit [REF-1398].

Build and Compilation

Use software techniques (including the use of serialization instructions) that are intended to reduce the number of instructions that can be executed transiently after a processor event or misprediction.

Effectiveness: Incidental

Note:

Some transient execution weaknesses can be exploited even if a single instruction is executed transiently after a processor event or mis-prediction. This mitigation strategy has many other pitfalls that prevent it from eliminating this weakness entirely. For example, see [REF-1389].

System Configuration

Some systems may allow the user to disable predictor sharing. For example, this could be a BIOS configuration, or a model-specific register (MSR) that can be configured by the operating system or virtual machine monitor.

Effectiveness: Moderate

Note:

Disabling predictor sharing can negatively impact performance for some workloads that benefit from shared predictor state.

Patching and Maintenance

The hardware vendor may provide a patch to, for example, sanitize predictor state when the processor transitions to a different context, or to prevent predictor entries from being shared across SMT threads. A patch may also introduce new ISA that allows software to toggle a mitigation.

Effectiveness: Moderate

Note:

This mitigation may only be fully effective if the patch prevents predictor sharing across all contexts that are affected by the weakness. Additionally, sanitizing predictor state and/or preventing shared predictor state can negatively impact performance in some circumstances.

Documentation

If a hardware feature can allow microarchitectural predictor state to be shared between contexts, SMT threads, or other architecturally defined boundaries, the hardware designer may opt to disclose this behavior in architecture documentation. This documentation can inform users about potential consequences and effective mitigations.

Effectiveness: High

Requirements

Processor designers, system software vendors, or other agents may choose to restrict the ability of unprivileged software to access to high-resolution timers that are commonly used to monitor covert channels.

+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1420 Exposure of Sensitive Information during Transient Execution
+ Relevant to the view "Hardware Design" (View-1194)
Nature Type ID Name
ChildOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1420 Exposure of Sensitive Information during Transient Execution
+ Modes Of Introduction
Section HelpThe 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

This weakness can be introduced during hardware architecture and design if predictor state is not properly isolated between modes (for example, user mode and kernel mode), if predictor state is not isolated between hardware threads, or if it is not isolated between other kinds of execution contexts supported by the processor.

Implementation

This weakness can be introduced during system software implementation if predictor-state-sanitizing operations (for example, the indirect branch prediction barrier on Intel x86) are not invoked when switching from one context to another.

System Configuration

This weakness can be introduced if the system has not been configured according to the hardware vendor's recommendations for mitigating the weakness.

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

Class: Not Language-Specific (Undetermined Prevalence)

Operating Systems

Class: Not OS-Specific (Undetermined Prevalence)

Architectures

Class: Not Architecture-Specific (Undetermined Prevalence)

Technologies

Microcontroller Hardware (Undetermined Prevalence)

Processor Hardware (Undetermined Prevalence)

Memory Hardware (Undetermined Prevalence)

Class: System on Chip (Undetermined Prevalence)

+ Demonstrative Examples

Example 1


Branch Target Injection (BTI) is a vulnerability that can allow an SMT hardware thread to maliciously train the indirect branch predictor state that is shared with its sibling hardware thread. A cross-thread BTI attack requires the attacker to find a vulnerable code sequence within the victim software. For example, the authors of [REF-1415] identified the following code sequence in the Windows library ntdll.dll:

(bad code)
Example Language: x86 Assembly 

adc edi,dword ptr [ebx+edx+13BE13BDh]
adc dl,byte ptr [edi]
...
indirect_branch_site:
jmp dword ptr [rsi] # at this point attacker knows edx, controls edi and ebx

To successfully exploit this code sequence to disclose the victim's private data, the attacker must also be able to find an indirect branch site within the victim, where the attacker controls the values in edi and ebx, and the attacker knows the value in edx as shown above at the indirect branch site.

A proof-of-concept cross-thread BTI attack might proceed as follows:

  1. The attacker thread and victim thread must be co-scheduled on the same physical processor core.
  2. The attacker thread must train the shared branch predictor so that when the victim thread reaches indirect_branch_site, the jmp instruction will be predicted to target example_code_sequence instead of the correct architectural target. The training procedure may vary by processor, and the attacker may need to reverse-engineer the branch predictor to identify a suitable training algorithm.
  3. This step assumes that the attacker can control some values in the victim program, specifically the values in edi and ebx at indirect_branch_site. When the victim reaches indirect_branch_site the processor will (mis)predict example_code_sequence as the target and (transiently) execute the adc instructions. If the attacker chooses ebx so that `ebx = m
    • 0x13BE13BD - edx, then the first adc will load 32 bits from address m in the victim's address space and add *m (the data loaded from) to the attacker-controlled base address in edi. The second adc instruction accesses a location in memory whose address corresponds to *m`.
  4. The adversary uses a covert channel analysis technique such as Flush+Reload ([REF-1416]) to infer the value of the victim's private data *m.



Example 2


BTI can also allow software in one execution context to maliciously train branch predictor entries that can be used in another context. For example, on some processors user-mode software may be able to train predictor entries that can also be used after transitioning into kernel mode, such as after invoking a system call. This vulnerability does not necessarily require SMT and may instead be performed in synchronous steps, though it does require the attacker to find an exploitable code sequence in the victim's code, for example, in the kernel.



+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
(Branch Target Injection, BTI, Spectre v2). Shared microarchitectural indirect branch predictor state may allow code to influence transient execution across a process, VM, or privilege boundary, potentially exposing data that is accessible beyond the boundary.
(Branch History Injection, BHI, Spectre-BHB). Shared branch history state may allow user-mode code to influence transient execution in the kernel, potentially exposing kernel data over a covert channel.
(RSB underflow, Retbleed). Shared return stack buffer state may allow code that executes before a prediction barrier to influence transient execution after the prediction barrier, potentially exposing data that is accessible beyond the barrier over a covert channel.
+ Detection Methods
Method Details

Manual Analysis

This weakness can be detected in hardware by manually inspecting processor specifications. Features that exhibit this weakness may have microarchitectural predictor state that is shared between hardware threads, execution contexts (for example, user and kernel), or other components that may host mutually distrusting software (or firmware, etc.).

Effectiveness: Moderate

Note:Manual analysis may not reveal all weaknesses in a processor specification and should be combined with other detection methods to improve coverage.

Automated Analysis

Software vendors can release tools that detect presence of known weaknesses on a processor. For example, some of these tools can attempt to transiently execute a vulnerable code sequence and detect whether code successfully leaks data in a manner consistent with the weakness under test. Alternatively, some hardware vendors provide enumeration for the presence of a weakness (or lack of a weakness). These enumeration bits can be checked and reported by system software. For example, Linux supports these checks for many commodity processors:

$ cat /proc/cpuinfo | grep bugs | head -n 1

bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa itlb_multihit srbds mmio_stale_data retbleed

Effectiveness: High

Note:This method can be useful for detecting whether a processor if affected by known weaknesses, but it may not be useful for detecting unknown weaknesses

Automated Analysis

This weakness can be detected in hardware by employing static or dynamic taint analysis methods [REF-1401]. These methods can label each predictor entry (or prediction history, etc.) according to the processor context that created it. Taint analysis or information flow analysis can then be applied to detect when predictor state created in one context can influence predictions made in another context.

Effectiveness: Moderate

Note:Automated static or dynamic taint analysis may not reveal all weaknesses in a processor specification and should be combined with other detection methods to improve coverage.
+ Memberships
Section HelpThis 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1416 Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

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

Comments

Use only when the weakness allows code in one processor context to influence the predictions of code in another processor context via predictor state that is shared between the two contexts. For example, Branch Target Injection, an instance of CWE-1423, can be mitigated by tagging each indirect branch predictor entry according to the processor context in which the entry was created, thus preventing entries created in one context from being used in a different context. However, the mitigated indirect branch predictor can still expose different weaknesses where malicious predictor entries created in one context are used later in the same context (context tags cannot prevent this). One such example is Intra-mode Branch Target Injection. Weaknesses of this sort can map to CWE-1420.

Suggestions

CWE-ID Comment
CWE-1420 If a weakness involves a microarchitectural predictor whose state is not shared across processor contexts, then CWE-1420 may be more appropriate for the mapping task.
+ References
[REF-1414] Intel Corporation. "Retpoline: A Branch Target Injection Mitigation". 2022-08-22.
<https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/retpoline-branch-target-injection-mitigation.html>. (URL validated: 2023-02-13)
[REF-1415] Paul Kocher, Jann Horn, Anders Fogh, Daniel Genkin, Daniel Gruss, Werner Haas, Mike Hamburg, Moritz Lipp, Stefan Mangard, Thomas Prescher, Michael Schwarz and Yuval Yarom. "Spectre Attacks: Exploiting Speculative Execution". 2019-05.
<https://spectreattack.com/spectre.pdf>. (URL validated: 2024-02-14)
[REF-1416] Yuval Yarom and Katrina Falkner. "Flush+Reload: A High Resolution, Low Noise, L3 Cache Side-Channel Attack". 2014.
<https://www.usenix.org/system/files/conference/usenixsecurity14/sec14-paper-yarom.pdf>. (URL validated: 2023-02-13)
[REF-1398] The Clang Team. "Control Flow Integrity".
<https://clang.llvm.org/docs/ControlFlowIntegrity.html>. (URL validated: 2024-02-13)
[REF-1389] Alyssa Milburn, Ke Sun and Henrique Kawakami. "You Cannot Always Win the Race: Analyzing the LFENCE/JMP Mitigation for Branch Target Injection". 2022-03-08.
<https://arxiv.org/abs/2203.04277>. (URL validated: 2024-02-22)
[REF-1400] Intel Corporation. "Refined Speculative Execution Terminology". 2022-03-11.
<https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/refined-speculative-execution-terminology.html>. (URL validated: 2024-02-13)
[REF-1401] Neta Bar Kama and Roope Kaivola. "Hardware Security Leak Detection by Symbolic Simulation". 2021-11.
<https://ieeexplore.ieee.org/document/9617727>. (URL validated: 2024-02-13)
+ Content History
+ Submissions
Submission Date Submitter Organization
2023-09-19
(CWE 4.14, 2024-02-29)
Scott D. Constable Intel Corporation
+ Contributions
Contribution Date Contributor Organization
2024-01-22
(CWE 4.14, 2024-02-29)
David Kaplan AMD
Member of Microarchitectural Weaknesses Working Group
2024-01-22
(CWE 4.14, 2024-02-29)
Rafael Dossantos, Abraham Fernandez Rubio, Alric Althoff, Lyndon Fawcett Arm
Members of Microarchitectural Weaknesses Working Group
2024-01-22
(CWE 4.14, 2024-02-29)
Jason Oberg Cycuity
Member of Microarchitectural Weaknesses Working Group
2024-01-22
(CWE 4.14, 2024-02-29)
Priya B. Iyer Intel Corporation
Member of Microarchitectural Weaknesses Working Group
2024-01-22
(CWE 4.14, 2024-02-29)
Nicole Fern Riscure
Member of Microarchitectural Weaknesses Working Group

CWE-213: Exposure of Sensitive Information Due to Incompatible Policies

Weakness ID: 213
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product's intended functionality exposes information to certain actors in accordance with the developer's security policy, but this information is regarded as sensitive according to the intended security policies of other stakeholders such as the product's administrator, users, or others whose information is being processed.
+ Extended Description

When handling information, the developer must consider whether the information is regarded as sensitive by different stakeholders, such as users or administrators. Each stakeholder effectively has its own intended security policy that the product is expected to uphold. When a developer does not treat that information as sensitive, this can introduce a vulnerability that violates the expectations of the product's users.

+ Common Consequences
Section HelpThis 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.
Impact Details

Read Application Data

Scope: Confidentiality

+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 200 Exposure of Sensitive Information to an Unauthorized Actor
+ Relevant to the view "Software Development" (View-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 199 Information Management Errors
+ Modes Of Introduction
Section HelpThe 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
Policy This can occur when the product's policy does not account for all relevant stakeholders, or when the policies of other stakeholders are not interpreted properly.
Requirements This can occur when requirements do not explicitly account for all relevant stakeholders.
Architecture and Design Communications or data exchange frameworks may be chosen that exchange or provide access to more information than strictly needed.
Implementation This can occur when the developer does not properly track the flow of sensitive information and how it is exposed, e.g., via an API.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Demonstrative Examples

Example 1


This code displays some information on a web page.

(bad code)
Example Language: JSP 
Social Security Number: <%= ssn %></br>Credit Card Number: <%= ccn %>

The code displays a user's credit card and social security numbers, even though they aren't absolutely necessary.



+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
Script calls phpinfo()
Script calls phpinfo()
Script calls phpinfo()
Script calls phpinfo()
Script calls phpinfo()
Product lists DLLs and full pathnames.
Telnet protocol allows servers to obtain sensitive environment information from clients.
Telnet protocol allows servers to obtain sensitive environment information from clients.
+ Memberships
Section HelpThis 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 963 SFP Secondary Cluster: Exposed Data
MemberOf ViewView - 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1348 OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1417 Comprehensive Categorization: Sensitive Information Exposure
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

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

Comments

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

Theoretical

In vulnerability theory terms, this covers cases in which the developer's Intended Policy allows the information to be made available, but the information might be in violation of a Universal Policy in which the product's administrator should have control over which information is considered sensitive and therefore should not be exposed.

Maintenance

This entry is being considered for deprecation. It overlaps many other entries related to information exposures. It might not be essential to preserve this entry, since other key stakeholder policies are covered elsewhere, e.g. personal privacy leaks (CWE-359) and system-level exposures that are important to system administrators (CWE-497).
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER Intended information leak
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification Date Modifier Organization
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2020-12-10 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Demonstrative_Examples, Description, Maintenance_Notes, Modes_of_Introduction, Name, Other_Notes, Relationship_Notes, Relationships, Time_of_Introduction
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms
2014-07-30 CWE Content Team MITRE
updated Demonstrative_Examples, Relationships
2014-06-23 CWE Content Team MITRE
updated Other_Notes, Relationship_Notes, Theoretical_Notes
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2012-05-11 CWE Content Team MITRE
updated Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2011-03-29 CWE Content Team MITRE
updated Name
2008-09-08 CWE Content Team MITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
2008-07-01 Sean Eidemiller Cigital
added/updated demonstrative examples
+ Previous Entry Names
Change Date Previous Entry Name
2011-03-29 Intended Information Leak
2020-02-24 Intentional Information Exposure

CWE-1420: Exposure of Sensitive Information during Transient Execution

Weakness ID: 1420
Vulnerability Mapping: ALLOWED This CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
A processor event or prediction may allow incorrect operations (or correct operations with incorrect data) to execute transiently, potentially exposing data over a covert channel.
+ Extended Description

When operations execute but do not commit to the processor's architectural state, this is commonly referred to as transient execution. This behavior can occur when the processor mis-predicts an outcome (such as a branch target), or when a processor event (such as an exception or microcode assist, etc.) is handled after younger operations have already executed. Operations that execute transiently may exhibit observable discrepancies (CWE-203) in covert channels [REF-1400] such as data caches. Observable discrepancies of this kind can be detected and analyzed using timing or power analysis techniques, which may allow an attacker to infer information about the operations that executed transiently. For example, the attacker may be able to infer confidential data that was accessed or used by those operations.

Transient execution weaknesses may be exploited using one of two methods. In the first method, the attacker generates a code sequence that exposes data through a covert channel when it is executed transiently (the attacker must also be able to trigger transient execution). Some transient execution weaknesses can only expose data that is accessible within the attacker's processor context. For example, an attacker executing code in a software sandbox may be able to use a transient execution weakness to expose data within the same address space, but outside of the attacker's sandbox. Other transient execution weaknesses can expose data that is architecturally inaccessible, that is, data protected by hardware-enforced boundaries such as page tables or privilege rings. These weaknesses are the subject of CWE-1421.

In the second exploitation method, the attacker first identifies a code sequence in a victim program that, when executed transiently, can expose data that is architecturally accessible within the victim's processor context. For instance, the attacker may search the victim program for code sequences that resemble a bounds-check bypass sequence (see Demonstrative Example 1). If the attacker can trigger a mis-prediction of the conditional branch and influence the index of the out-of-bounds array access, then the attacker may be able to infer the value of out-of-bounds data by monitoring observable discrepancies in a covert channel.

+ Common Consequences
Section HelpThis 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.
Impact Details

Read Memory

Scope: Confidentiality

Likelihood: Medium

+ Potential Mitigations
Phase(s) Mitigation

Architecture and Design

The hardware designer can attempt to prevent transient execution from causing observable discrepancies in specific covert channels.

Effectiveness: Limited

Note:

This technique has many pitfalls. For example, InvisiSpec was an early attempt to mitigate this weakness by blocking "micro-architectural covert and side channels through the multiprocessor data cache hierarchy due to speculative loads" [REF-1417]. Commodity processors and SoCs have many covert and side channels that exist outside of the data cache hierarchy. Even when some of these channels are blocked, others (such as execution ports [REF-1418]) may allow an attacker to infer confidential data. Mitigation strategies that attempt to prevent transient execution from causing observable discrepancies also have other pitfalls, for example, see [REF-1419].

Requirements

Processor designers may expose instructions or other architectural features that allow software to mitigate the effects of transient execution, but without disabling predictors. These features may also help to limit opportunities for data exposure.

Effectiveness: Moderate

Note:

Instructions or features that constrain transient execution or suppress its side effects may impact performance.

Requirements

Processor designers may expose registers (for example, control registers or model-specific registers) that allow privileged and/or user software to disable specific predictors or other hardware features that can cause confidential data to be exposed during transient execution.

Effectiveness: Limited

Note:

Disabling specific predictors or other hardware features may result in significant performance overhead.

Requirements

Processor designers, system software vendors, or other agents may choose to restrict the ability of unprivileged software to access to high-resolution timers that are commonly used to monitor covert channels.

Effectiveness: Defense in Depth

Note:

Specific software algorithms can be used by an attacker to compensate for a lack of a high-resolution time source [REF-1420].

Build and Compilation

Isolate sandboxes or managed runtimes in separate address spaces (separate processes). For examples, see [REF-1421].

Effectiveness: High

Build and Compilation

Include serialization instructions (for example, LFENCE) that prevent processor events or mis-predictions prior to the serialization instruction from causing transient execution after the serialization instruction. For some weaknesses, a serialization instruction can also prevent a processor event or a mis-prediction from occurring after the serialization instruction (for example, CVE-2018-3639 can allow a processor to predict that a load will not depend on an older store; a serialization instruction between the store and the load may allow the store to update memory and prevent the prediction from happening at all).

Effectiveness: Moderate

Note:

When used to comprehensively mitigate a transient execution weakness (for example, by inserting an LFENCE after every instruction in a program), serialization instructions can introduce significant performance overhead. On the other hand, when used to mitigate only a relatively small number of high-risk code sequences, serialization instructions may have a low or negligible impact on performance.

Build and Compilation

Use control-flow integrity (CFI) techniques to constrain the behavior of instructions that redirect the instruction pointer, such as indirect branch instructions.

Effectiveness: Moderate

Note:

Some CFI techniques may not be able to constrain transient execution, even though they are effective at constraining architectural execution. Or they may be able to provide some additional protection against a transient execution weakness, but without comprehensively mitigating the weakness. For example, Clang-CFI provides strong architectural CFI properties and can make some transient execution weaknesses more difficult to exploit [REF-1398].

Build and Compilation

If the weakness is exposed by a single instruction (or a small set of instructions), then the compiler (or JIT, etc.) can be configured to prevent the affected instruction(s) from being generated, and instead generate an alternate sequence of instructions that is not affected by the weakness. One prominent example of this mitigation is retpoline ([REF-1414]).

Effectiveness: Limited

Note:

This technique may only be effective for software that is compiled with this mitigation. For some transient execution weaknesses, this technique may not be sufficient to protect software that is compiled without the affected instruction(s). For example, see CWE-1421.

Build and Compilation

Use software techniques that can mitigate the consequences of transient execution. For example, address masking can be used in some circumstances to prevent out-of-bounds transient reads.

Effectiveness: Limited

Note:

Address masking and related software mitigation techniques have been used to harden specific code sequences that could potentially be exploited via transient execution. For example, the Linux kernel makes limited use of manually inserted address masks to mitigate bounds-check bypass [REF-1390]. Compiler-based techniques have also been used to automatically harden software [REF-1425].

Build and Compilation

Use software techniques (including the use of serialization instructions) that are intended to reduce the number of instructions that can be executed transiently after a processor event or misprediction.

Effectiveness: Incidental

Note:

Some transient execution weaknesses can be exploited even if a single instruction is executed transiently after a processor event or mis-prediction. This mitigation strategy has many other pitfalls that prevent it from eliminating this weakness entirely. For example, see [REF-1389].

Documentation

If a hardware feature can allow incorrect operations (or correct operations with incorrect data) to execute transiently, the hardware designer may opt to disclose this behavior in architecture documentation. This documentation can inform users about potential consequences and effective mitigations.

Effectiveness: High

+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 669 Incorrect Resource Transfer Between Spheres
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1421 Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1422 Exposure of Sensitive Information caused by Incorrect Data Forwarding during Transient Execution
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1423 Exposure of Sensitive Information caused by Shared Microarchitectural Predictor State that Influences Transient Execution
+ Relevant to the view "Hardware Design" (View-1194)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1198 Privilege Separation and Access Control Issues
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1201 Core and Compute Issues
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1202 Memory and Storage Issues
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1421 Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1422 Exposure of Sensitive Information caused by Incorrect Data Forwarding during Transient Execution
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1423 Exposure of Sensitive Information caused by Shared Microarchitectural Predictor State that Influences Transient Execution
+ Modes Of Introduction
Section HelpThe 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 This weakness can be introduced when a computing unit (such as a CPU, GPU, accelerator, or any other processor) uses out-of-order execution, speculation, or any other microarchitectural feature that can allow microarchitectural operations to execute without committing to architectural state.
Implementation This weakness can be introduced when sandboxes or managed runtimes are not properly isolated by using hardware-enforced boundaries. Developers of sandbox or managed runtime software should exercise caution when relying on software techniques (such as bounds checking) to prevent code in one sandbox from accessing confidential data in another sandbox. For example, an attacker sandbox may be able to trigger a processor event or mis-prediction in a manner that allows it to transiently read a victim sandbox's private data.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

Operating Systems

Class: Not OS-Specific (Undetermined Prevalence)

Architectures

Class: Not Architecture-Specific (Undetermined Prevalence)

Technologies

Class: Not Technology-Specific (Undetermined Prevalence)

+ Demonstrative Examples

Example 1


Secure programs perform bounds checking before accessing an array if the source of the array index is provided by an untrusted source such as user input. In the code below, data from array1 will not be accessed if x is out of bounds. The following code snippet is from [REF-1415]:

(bad code)
Example Language:
if (x < array1_size)
y = array2[array1[x] * 4096];

However, if this code executes on a processor that performs conditional branch prediction the outcome of the if statement could be mis-predicted and the access on the next line will occur with a value of x that can point to an out-of-bounds location (within the program's memory).

Even though the processor does not commit the architectural effects of the mis-predicted branch, the memory accesses alter data cache state, which is not rolled back after the branch is resolved. The cache state can reveal array1[x] thereby providing a mechanism to recover the data value located at address array1 + x.



Example 2


Some managed runtimes or just-in-time (JIT) compilers may overwrite recently executed code with new code. When the instruction pointer enters the new code, the processor may inadvertently execute the stale code that had been overwritten. This can happen, for instance, when the processor issues a store that overwrites a sequence of code, but the processor fetches and executes the (stale) code before the store updates memory. Similar to the first example, the processor does not commit the stale code's architectural effects, though microarchitectural side effects can persist. Hence, confidential information accessed or used by the stale code may be inferred via an observable discrepancy in a covert channel. This vulnerability is described in more detail in [REF-1427].



+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
Microarchitectural conditional branch predictors may allow operations to execute transiently after a misprediction, potentially exposing data over a covert channel.
A machine clear triggered by self-modifying code may allow incorrect operations to execute transiently, potentially exposing data over a covert channel.
Microarchitectural indirect branch predictors may allow incorrect operations to execute transiently after a misprediction, potentially exposing data over a covert channel.
+ Detection Methods
Method Details

Manual Analysis

This weakness can be detected in hardware by manually inspecting processor specifications. Features that exhibit this weakness may include microarchitectural predictors, access control checks that occur out-of-order, or any other features that can allow operations to execute without committing to architectural state. Academic researchers have demonstrated that new hardware weaknesses can be discovered by exhaustively analyzing a processor's machine clear (or nuke) conditions ([REF-1427]).

Effectiveness: Moderate

Note:

Hardware designers can also scrutinize aspects of the instruction set architecture that have undefined behavior; these can become a focal point when applying other detection methods.

Manual analysis may not reveal all weaknesses in a processor specification and should be combined with other detection methods to improve coverage.

Fuzzing

Academic researchers have demonstrated that this weakness can be detected in hardware using software fuzzing tools that treat the underlying hardware as a black box ([REF-1428]).

Effectiveness: Opportunistic

Note:

Fuzzing may not reveal all weaknesses in a processor specification and should be combined with other detection methods to improve coverage.

Fuzzing

Academic researchers have demonstrated that this weakness can be detected in software using software fuzzing tools ([REF-1429]).

Effectiveness: Opportunistic

Note:

At the time of this writing, publicly available software fuzzing tools can only detect a subset of transient execution weaknesses in software (for example, [REF-1429] can only detect instances of Spectre v1) and may produce false positives.

Automated Static Analysis

A variety of automated static analysis tools can identify potentially exploitable code sequences in software. These tools may perform the analysis on source code, on binary code, or on an intermediate code representation (for example, during compilation).

Effectiveness: Limited

Note:

At the time of this writing, publicly available software static analysis tools can only detect a subset of transient execution weaknesses in software and may produce false positives.

Automated Analysis

Software vendors can release tools that detect presence of known weaknesses on a processor. For example, some of these tools can attempt to transiently execute a vulnerable code sequence and detect whether code successfully leaks data in a manner consistent with the weakness under test. Alternatively, some hardware vendors provide enumeration for the presence of a weakness (or lack of a weakness). These enumeration bits can be checked and reported by system software. For example, Linux supports these checks for many commodity processors:

$ cat /proc/cpuinfo | grep bugs | head -n 1

bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa itlb_multihit srbds mmio_stale_data retbleed

Effectiveness: High

Note:

This method can be useful for detecting whether a processor is affected by known weaknesses, but it may not be useful for detecting unknown weaknesses.

+ Memberships
Section HelpThis 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1416 Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes
Usage ALLOWED-WITH-REVIEW
(this CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review)
Reason Acceptable-Use

Rationale

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

Comments

A vulnerability should only map to CWE-1420 if it cannot map to any of CWE-1420's child weaknesses. Follow this diagram:

CWE-1420 mapping decision diagram
+ References
[REF-1389] Alyssa Milburn, Ke Sun and Henrique Kawakami. "You Cannot Always Win the Race: Analyzing the LFENCE/JMP Mitigation for Branch Target Injection". 2022-03-08.
<https://arxiv.org/abs/2203.04277>. (URL validated: 2024-02-22)
[REF-1417] Mengjia Yan, Jiho Choi, Dimitrios Skarlatos, Adam Morrison, Christopher W. Fletcher and Josep Torrella. "InvisiSpec: making speculative execution invisible in the cache hierarchy.". 2019-05.
<http://iacoma.cs.uiuc.edu/iacoma-papers/micro18.pdf>. (URL validated: 2024-02-14)
[REF-1418] Alejandro Cabrera Aldaya, Billy Bob Brumley, Sohaib ul Hassan, Cesar Pereida García and Nicola Tuveri. "Port Contention for Fun and Profit". 2019-05.
<https://eprint.iacr.org/2018/1060.pdf>. (URL validated: 2024-02-14)
[REF-1419] Mohammad Behnia, Prateek Sahu, Riccardo Paccagnella, Jiyong Yu, Zirui Zhao, Xiang Zou, Thomas Unterluggauer, Josep Torrellas, Carlos Rozas, Adam Morrison, Frank Mckeen, Fangfei Liu, Ron Gabor, Christopher W. Fletcher, Abhishek Basak and Alaa Alameldeen. "Speculative Interference Attacks: Breaking Invisible Speculation Schemes". 2021-04.
<https://arxiv.org/abs/2007.11818>. (URL validated: 2024-02-14)
[REF-1420] Ross Mcilroy, Jaroslav Sevcik, Tobias Tebbi, Ben L. Titzer and Toon Verwaest. "Spectre is here to stay: An analysis of side-channels and speculative execution". 2019-02-14.
<https://arxiv.org/pdf/1902.05178.pdf>. (URL validated: 2024-02-14)
[REF-1421] Intel Corporation. "Managed Runtime Speculative Execution Side Channel Mitigations". 2018-01-03.
<https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/runtime-speculative-side-channel-mitigations.html>. (URL validated: 2024-02-14)
[REF-1398] The Clang Team. "Control Flow Integrity".
<https://clang.llvm.org/docs/ControlFlowIntegrity.html>. (URL validated: 2024-02-13)
[REF-1414] Intel Corporation. "Retpoline: A Branch Target Injection Mitigation". 2022-08-22.
<https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/retpoline-branch-target-injection-mitigation.html>. (URL validated: 2023-02-13)
[REF-1390] The kernel development community. "Speculation". 2020-08-16.
<https://docs.kernel.org/6.6/staging/speculation.html>. (URL validated: 2024-02-04)
[REF-1425] Chandler Carruth. "Speculative Load Hardening".
<https://llvm.org/docs/SpeculativeLoadHardening.html>. (URL validated: 2024-02-14)
[REF-1427] Hany Ragab, Enrico Barberis, Herbert Bos and Cristiano Giuffrida. "Rage Against the Machine Clear: A Systematic Analysis of Machine Clears and Their Implications for Transient Execution Attacks". 2021-08.
<https://www.usenix.org/system/files/sec21-ragab.pdf>. (URL validated: 2024-02-14)
[REF-1428] Oleksii Oleksenko, Marco Guarnieri, Boris Köpf and Mark Silberstein. "Hide and Seek with Spectres: Efficient discovery of speculative information leaks with random testing". 2023-01-18.
<https://arxiv.org/pdf/2301.07642.pdf>. (URL validated: 2024-02-14)
[REF-1429] Oleksii Oleksenko, Bohdan Trach, Mark Silberstein and Christof Fetzer. "SpecFuzz: Bringing Spectre-type vulnerabilities to the surface". 2020-08.
<https://www.usenix.org/system/files/sec20-oleksenko.pdf>. (URL validated: 2024-02-14)
[REF-1415] Paul Kocher, Jann Horn, Anders Fogh, Daniel Genkin, Daniel Gruss, Werner Haas, Mike Hamburg, Moritz Lipp, Stefan Mangard, Thomas Prescher, Michael Schwarz and Yuval Yarom. "Spectre Attacks: Exploiting Speculative Execution". 2019-05.
<https://spectreattack.com/spectre.pdf>. (URL validated: 2024-02-14)
[REF-1400] Intel Corporation. "Refined Speculative Execution Terminology". 2022-03-11.
<https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/refined-speculative-execution-terminology.html>. (URL validated: 2024-02-13)
+ Content History
+ Submissions
Submission Date Submitter Organization
2023-09-19
(CWE 4.14, 2024-02-29)
Scott D. Constable Intel Corporation
+ Contributions
Contribution Date Contributor Organization
2024-01-22
(CWE 4.14, 2024-02-29)
David Kaplan AMD
Member of Microarchitectural Weaknesses Working Group
2024-01-22
(CWE 4.14, 2024-02-29)
Rafael Dossantos, Abraham Fernandez Rubio, Alric Althoff, Lyndon Fawcett Arm
Members of Microarchitectural Weaknesses Working Group
2024-01-22
(CWE 4.14, 2024-02-29)
Jason Oberg Cycuity
Member of Microarchitectural Weaknesses Working Group
2024-01-22
(CWE 4.14, 2024-02-29)
Priya B. Iyer Intel Corporation
Member of Microarchitectural Weaknesses Working Group
2024-01-22
(CWE 4.14, 2024-02-29)
Nicole Fern Riscure
Member of Microarchitectural Weaknesses Working Group
+ Modifications
Modification Date Modifier Organization
2024-07-16
(CWE 4.15, 2024-07-16)
CWE Content Team MITRE
updated Mapping_Notes

CWE-1421: Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution

Weakness ID: 1421
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
A processor event may allow transient operations to access architecturally restricted data (for example, in another address space) in a shared microarchitectural structure (for example, a CPU cache), potentially exposing the data over a covert channel.
+ Extended Description

Many commodity processors have Instruction Set Architecture (ISA) features that protect software components from one another. These features can include memory segmentation, virtual memory, privilege rings, trusted execution environments, and virtual machines, among others. For example, virtual memory provides each process with its own address space, which prevents processes from accessing each other's private data. Many of these features can be used to form hardware-enforced security boundaries between software components.

Many commodity processors also share microarchitectural resources that cache (temporarily store) data, which may be confidential. These resources may be shared across processor contexts, including across SMT threads, privilege rings, or others.

When transient operations allow access to ISA-protected data in a shared microarchitectural resource, this might violate users' expectations of the ISA feature that is bypassed. For example, if transient operations can access a victim's private data in a shared microarchitectural resource, then the operations' microarchitectural side effects may correspond to the accessed data. If an attacker can trigger these transient operations and observe their side effects through a covert channel [REF-1400], then the attacker may be able to infer the victim's private data. Private data could include sensitive program data, OS/VMM data, page table data (such as memory addresses), system configuration data (see Demonstrative Example 3), or any other data that the attacker does not have the required privileges to access.

+ Common Consequences
Section HelpThis 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.
Impact Details

Read Memory

Scope: Confidentiality

Likelihood: Medium

<<put the information here>>

+ Potential Mitigations
Phase(s) Mitigation

Architecture and Design

Hardware designers may choose to engineer the processor's pipeline to prevent architecturally restricted data from being used by operations that can execute transiently.

Effectiveness: High

Architecture and Design

Hardware designers may choose not to share microarchitectural resources that can contain sensitive data, such as fill buffers and store buffers.

Effectiveness: Moderate

Note:

This can be highly effective at preventing this weakness from being exposed across different SMT threads or different processor cores. It is generally less practical to isolate these resources between different contexts (for example, user and kernel) that may execute on the same SMT thread or processor core.

Architecture and Design

Hardware designers may choose to sanitize specific microarchitectural state (for example, store buffers) when the processor transitions to a different context, such as whenever a system call is invoked. Alternatively, the hardware may expose instruction(s) that allow software to sanitize microarchitectural state according to the user or system administrator's threat model. These mitigation approaches are similar to those that address CWE-226; however, sanitizing microarchitectural state may not be the optimal or best way to mitigate this weakness on every processor design.

Effectiveness: Moderate

Note:

Sanitizing shared state on context transitions may not be practical for all processors, especially when the amount of shared state affected by the weakness is relatively large. Additionally, this technique may not be practical unless there is a synchronous transition between two processor contexts that would allow the affected resource to be sanitized. For example, this technique alone may not suffice to mitigate asynchronous access to a resource that is shared by two SMT threads.

Architecture and Design

The hardware designer can attempt to prevent transient execution from causing observable discrepancies in specific covert channels.

Effectiveness: Limited

Note:

This technique has many pitfalls. For example, InvisiSpec was an early attempt to mitigate this weakness by blocking "micro-architectural covert and side channels through the multiprocessor data cache hierarchy due to speculative loads" [REF-1417]. Commodity processors and SoCs have many covert and side channels that exist outside of the data cache hierarchy. Even when some of these channels are blocked, others (such as execution ports [REF-1418]) may allow an attacker to infer confidential data. Mitigation strategies that attempt to prevent transient execution from causing observable discrepancies also have other pitfalls, for example, see [REF-1419].

Architecture and Design

Software architects may design software to enforce strong isolation between different contexts. For example, kernel page table isolation (KPTI) mitigates the Meltdown vulnerability [REF-1401] by separating user-mode page tables from kernel-mode page tables, which prevents user-mode processes from using Meltdown to transiently access kernel memory [REF-1404].

Effectiveness: Limited

Note:

Isolating different contexts across a process boundary (or another kind of architectural boundary) may only be effective for some weaknesses.

Build and Compilation

If the weakness is exposed by a single instruction (or a small set of instructions), then the compiler (or JIT, etc.) can be configured to prevent the affected instruction(s) from being generated, and instead generate an alternate sequence of instructions that is not affected by the weakness.

Effectiveness: Limited

Note:

This technique may only be fully effective if it is applied to all software that runs on the system. Also, relatively few observed examples of this weakness have exposed data through only a single instruction.

Build and Compilation

Use software techniques (including the use of serialization instructions) that are intended to reduce the number of instructions that can be executed transiently after a processor event or misprediction.

Effectiveness: Incidental

Note:

Some transient execution weaknesses can be exploited even if a single instruction is executed transiently after a processor event or mis-prediction. This mitigation strategy has many other pitfalls that prevent it from eliminating this weakness entirely. For example, see [REF-1389].

Implementation

System software can mitigate this weakness by invoking state-sanitizing operations when switching from one context to another, according to the hardware vendor's recommendations.

Effectiveness: Limited

Note:

This technique may not be able to mitigate weaknesses that arise from resource sharing across SMT threads.

System Configuration

Some systems may allow the user to disable (for example, in the BIOS) sharing of the affected resource.

Effectiveness: Limited

Note:

Disabling resource sharing (for example, by disabling SMT) may result in significant performance overhead.

System Configuration

Some systems may allow the user to disable (for example, in the BIOS) microarchitectural features that allow transient access to architecturally restricted data.

Effectiveness: Limited

Note:

Disabling microarchitectural features such as predictors may result in significant performance overhead.

Patching and Maintenance

The hardware vendor may provide a patch to sanitize the affected shared microarchitectural state when the processor transitions to a different context.

Effectiveness: Moderate

Note:

This technique may not be able to mitigate weaknesses that arise from resource sharing across SMT threads.

Patching and Maintenance

This kind of patch may not be feasible or implementable for all processors or all weaknesses.

Effectiveness: Limited

Requirements

Processor designers, system software vendors, or other agents may choose to restrict the ability of unprivileged software to access to high-resolution timers that are commonly used to monitor covert channels.

Effectiveness: Defense in Depth

Note:

Specific software algorithms can be used by an attacker to compensate for a lack of a high-resolution time source [REF-1420].

+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1420 Exposure of Sensitive Information during Transient Execution
+ Relevant to the view "Hardware Design" (View-1194)
Nature Type ID Name
ChildOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1420 Exposure of Sensitive Information during Transient Execution
+ Modes Of Introduction
Section HelpThe 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

This weakness can be introduced during hardware architecture and design if a data path allows architecturally restricted data to propagate to operations that execute before an older mis-prediction or processor event (such as an exception) is caught.

Implementation

This weakness can be introduced during system software implementation if state-sanitizing operations are not invoked when switching from one context to another, according to the hardware vendor's recommendations for mitigating the weakness.

System Configuration

This weakness can be introduced if the system has not been configured according to the hardware vendor's recommendations for mitigating the weakness.

Architecture and Design

This weakness can be introduced when an access control check (for example, checking page permissions) can proceed in parallel with the access operation (for example, a load) that is being checked. If the processor can allow the access operation to execute before the check completes, this race condition may allow subsequent transient operations to expose sensitive information.

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

Class: Not Language-Specific (Undetermined Prevalence)

Operating Systems

Class: Not OS-Specific (Undetermined Prevalence)

Architectures

Class: Not Architecture-Specific (Undetermined Prevalence)

Technologies

Class: Not Technology-Specific (Undetermined Prevalence)

+ Demonstrative Examples

Example 1


Some processors may perform access control checks in parallel with memory read/write operations. For example, when a user-mode program attempts to read data from memory, the processor may also need to check whether the memory address is mapped into user space or kernel space. If the processor performs the access concurrently with the check, then the access may be able to transiently read kernel data before the check completes. This race condition is demonstrated in the following code snippet from [REF-1408], with additional annotations:

(bad code)
Example Language: x86 Assembly 
1 ; rcx = kernel address, rbx = probe array
2 xor rax, rax # set rax to 0
3 retry:
4 mov al, byte [rcx] # attempt to read kernel memory
5 shl rax, 0xc # multiply result by page size (4KB)
6 jz retry # if the result is zero, try again
7 mov rbx, qword [rbx + rax] # transmit result over a cache covert channel

Vulnerable processors may return kernel data from a shared microarchitectural resource in line 4, for example, from the processor's L1 data cache. Since this vulnerability involves a race condition, the mov in line 4 may not always return kernel data (that is, whenever the check "wins" the race), in which case this demonstration code re-attempts the access in line 6. The accessed data is multiplied by 4KB, a common page size, to make it easier to observe via a cache covert channel after the transmission in line 7. The use of cache covert channels to observe the side effects of transient execution has been described in [REF-1408].



Example 2


Many commodity processors share microarchitectural fill buffers between sibling hardware threads on simultaneous multithreaded (SMT) processors. Fill buffers can serve as temporary storage for data that passes to and from the processor's caches. Microarchitectural Fill Buffer Data Sampling (MFBDS) is a vulnerability that can allow a hardware thread to access its sibling's private data in a shared fill buffer. The access may be prohibited by the processor's ISA, but MFBDS can allow the access to occur during transient execution, in particular during a faulting operation or an operation that triggers a microcode assist.

More information on MFBDS can be found in [REF-1405] and [REF-1409].



Example 3


Some processors may allow access to system registers (for example, system coprocessor registers or model-specific registers) during transient execution. This scenario is depicted in the code snippet below. Under ordinary operating circumstances, code in exception level 0 (EL0) is not permitted to access registers that are restricted to EL1, such as TTBR0_EL1. However, on some processors an earlier mis-prediction can cause the MRS instruction to transiently read the value in an EL1 register. In this example, a conditional branch (line 2) can be mis-predicted as "not taken" while waiting for a slow load (line 1). This allows MRS (line 3) to transiently read the value in the TTBR0_EL1 register. The subsequent memory access (line 6) can allow the restricted register's value to become observable, for example, over a cache covert channel.

Code snippet is from [REF-1410]. See also [REF-1411].

(bad code)
Example Language: x86 Assembly 

1 LDR X1, [X2] ; arranged to miss in the cache
2 CBZ X1, over ; This will be taken
3 MRS X3, TTBR0_EL1;
4 LSL X3, X3, #imm
5 AND X3, X3, #0xFC0
6 LDR X5, [X6,X3] ; X6 is an EL0 base address
7 over


+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
A fault may allow transient user-mode operations to access kernel data cached in the L1D, potentially exposing the data over a covert channel.
A fault may allow transient non-enclave operations to access SGX enclave data cached in the L1D, potentially exposing the data over a covert channel.
A TSX Asynchronous Abort may allow transient operations to access architecturally restricted data, potentially exposing the data over a covert channel.
+ Detection Methods
Method Details

Manual Analysis

This weakness can be detected in hardware by manually inspecting processor specifications. Features that exhibit this weakness may include microarchitectural predictors, access control checks that occur out-of-order, or any other features that can allow operations to execute without committing to architectural state. Academic researchers have demonstrated that new hardware weaknesses can be discovered by examining publicly available patent filings, for example [REF-1405] and [REF-1406]. Hardware designers can also scrutinize aspects of the instruction set architecture that have undefined behavior; these can become a focal point when applying other detection methods.

Effectiveness: Moderate

Note:Manual analysis may not reveal all weaknesses in a processor specification and should be combined with other detection methods to improve coverage.

Automated Analysis

This weakness can be detected (pre-discovery) in hardware by employing static or dynamic taint analysis methods [REF-1401]. These methods can label data in one context (for example, kernel data) and perform information flow analysis (or a simulation, etc.) to determine whether tainted data can appear in another context (for example, user mode). Alternatively, stale or invalid data in shared microarchitectural resources can be marked as tainted, and the taint analysis framework can identify when transient operations encounter tainted data.

Effectiveness: Moderate

Note:Automated static or dynamic taint analysis may not reveal all weaknesses in a processor specification and should be combined with other detection methods to improve coverage.

Automated Analysis

Software vendors can release tools that detect presence of known weaknesses (post-discovery) on a processor. For example, some of these tools can attempt to transiently execute a vulnerable code sequence and detect whether code successfully leaks data in a manner consistent with the weakness under test. Alternatively, some hardware vendors provide enumeration for the presence of a weakness (or lack of a weakness). These enumeration bits can be checked and reported by system software. For example, Linux supports these checks for many commodity processors:

$ cat /proc/cpuinfo | grep bugs | head -n 1

bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa itlb_multihit srbds mmio_stale_data retbleed

Effectiveness: High

Note:This method can be useful for detecting whether a processor if affected by known weaknesses, but it may not be useful for detecting unknown weaknesses.

Fuzzing

Academic researchers have demonstrated that this weakness can be detected in hardware using software fuzzing tools that treat the underlying hardware as a black box ([REF-1406], [REF-1430])

Effectiveness: Opportunistic

Note:Fuzzing may not reveal all weaknesses in a processor specification and should be combined with other detection methods to improve coverage.
+ Memberships
Section HelpThis 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1416 Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

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

Comments

If a weakness can potentially be exploited to infer data that is accessible inside or outside the current processor context, then the weakness could map to CWE-1421 and to another CWE such as CWE-1420.
+ References
[REF-1404] The kernel development community. "Page Table Isolation (PTI)". 2023-01-30.
<https://kernel.org/doc/html/next/x86/pti.html>. (URL validated: 2024-02-13)
[REF-1405] Stephan van Schaik, Alyssa Milburn, Sebastian Österlund, Pietro Frigo, Giorgi Maisuradze, Kaveh Razavi, Herbert Bos and Cristiano Giuffrida. "RIDL: Rogue In-Flight Data Load". 2019-05-19.
<https://mdsattacks.com/files/ridl.pdf>. (URL validated: 2024-02-13)
[REF-1406] Daniel Moghimi. "Downfall: Exploiting Speculative Data Gathering". 2023-08-09.
<https://www.usenix.org/system/files/usenixsecurity23-moghimi.pdf>. (URL validated: 2024-02-13)
[REF-1401] Neta Bar Kama and Roope Kaivola. "Hardware Security Leak Detection by Symbolic Simulation". 2021-11.
<https://ieeexplore.ieee.org/document/9617727>. (URL validated: 2024-02-13)
[REF-1408] Moritz Lipp, Michael Schwarz, Daniel Gruss, Thomas Prescher, Werner Haas, Stefan Mangard, Paul Kocher, Daniel Genkin, Yuval Yarom and Mike Hamburg. "Meltdown: Reading Kernel Memory from User Space". 2020-05-21.
<https://meltdownattack.com/meltdown.pdf>. (URL validated: 2024-02-13)
[REF-1409] Intel Corporation. "Microarchitectural Data Sampling". 2021-03-11.
<https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/intel-analysis-microarchitectural-data-sampling.html>. (URL validated: 2024-02-13)
[REF-1410] ARM. "Cache Speculation Side-channels". 2018-01.
<https://armkeil.blob.core.windows.net/developer/Files/pdf/Cache_Speculation_Side-channels.pdf>. (URL validated: 2024-02-22)
[REF-1411] Intel Corporation. "Rogue System Register Read/CVE-2018-3640/INTEL-SA-00115". 2018-05-01.
<https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/rogue-system-register-read.html>. (URL validated: 2024-02-13)
[REF-1400] Intel Corporation. "Refined Speculative Execution Terminology". 2022-03-11.
<https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/refined-speculative-execution-terminology.html>. (URL validated: 2024-02-13)
[REF-1389] Alyssa Milburn, Ke Sun and Henrique Kawakami. "You Cannot Always Win the Race: Analyzing the LFENCE/JMP Mitigation for Branch Target Injection". 2022-03-08.
<https://arxiv.org/abs/2203.04277>. (URL validated: 2024-02-22)
[REF-1430] Daniel Moghimi, Moritz Lipp, Berk Sunar and Michael Schwarz. "Medusa: Microarchitectural: Data Leakage via Automated Attack Synthesis". 2020-08.
<https://www.usenix.org/conference/usenixsecurity20/presentation/moghimi-medusa>. (URL validated: 2024-02-27)
[REF-1417] Mengjia Yan, Jiho Choi, Dimitrios Skarlatos, Adam Morrison, Christopher W. Fletcher and Josep Torrella. "InvisiSpec: making speculative execution invisible in the cache hierarchy.". 2019-05.
<http://iacoma.cs.uiuc.edu/iacoma-papers/micro18.pdf>. (URL validated: 2024-02-14)
[REF-1418] Alejandro Cabrera Aldaya, Billy Bob Brumley, Sohaib ul Hassan, Cesar Pereida García and Nicola Tuveri. "Port Contention for Fun and Profit". 2019-05.
<https://eprint.iacr.org/2018/1060.pdf>. (URL validated: 2024-02-14)
[REF-1419] Mohammad Behnia, Prateek Sahu, Riccardo Paccagnella, Jiyong Yu, Zirui Zhao, Xiang Zou, Thomas Unterluggauer, Josep Torrellas, Carlos Rozas, Adam Morrison, Frank Mckeen, Fangfei Liu, Ron Gabor, Christopher W. Fletcher, Abhishek Basak and Alaa Alameldeen. "Speculative Interference Attacks: Breaking Invisible Speculation Schemes". 2021-04.
<https://arxiv.org/abs/2007.11818>. (URL validated: 2024-02-14)
[REF-1420] Ross Mcilroy, Jaroslav Sevcik, Tobias Tebbi, Ben L. Titzer and Toon Verwaest. "Spectre is here to stay: An analysis of side-channels and speculative execution". 2019-02-14.
<https://arxiv.org/pdf/1902.05178.pdf>. (URL validated: 2024-02-14)
+ Content History
+ Submissions
Submission Date Submitter Organization
2023-09-19
(CWE 4.14, 2024-02-29)
Scott D. Constable Intel Corporation
+ Contributions
Contribution Date Contributor Organization
2024-01-22
(CWE 4.14, 2024-02-29)
David Kaplan AMD
Member of Microarchitectural Weaknesses Working Group
2024-01-22
(CWE 4.14, 2024-02-29)
Rafael Dossantos, Abraham Fernandez Rubio, Alric Althoff, Lyndon Fawcett Arm
Members of Microarchitectural Weaknesses Working Group
2024-01-22
(CWE 4.14, 2024-02-29)
Jason Oberg Cycuity
Member of Microarchitectural Weaknesses Working Group
2024-01-22
(CWE 4.14, 2024-02-29)
Priya B. Iyer Intel Corporation
Member of Microarchitectural Weaknesses Working Group
2024-01-22
(CWE 4.14, 2024-02-29)
Nicole Fern Riscure
Member of Microarchitectural Weaknesses Working Group

CWE-202: Exposure of Sensitive Information Through Data Queries

Weakness ID: 202
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
When trying to keep information confidential, an attacker can often infer some of the information by using statistics.
+ Extended Description
In situations where data should not be tied to individual users, but a large number of users should be able to make queries that "scrub" the identity of users, it may be possible to get information about a user -- e.g., by specifying search terms that are known to be unique to that user.
+ Common Consequences
Section HelpThis 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.
Impact Details

Read Files or Directories; Read Application Data

Scope: Confidentiality

Sensitive information may possibly be leaked through data queries accidentally.
+ Potential Mitigations
Phase(s) Mitigation

Architecture and Design

This is a complex topic. See the book Translucent Databases for a good discussion of best practices.
+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1230 Exposure of Sensitive Information Through Metadata
+ Modes Of Introduction
Section HelpThe 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
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

+ Likelihood Of Exploit
Medium
+ Demonstrative Examples

Example 1


See the book Translucent Databases for examples.



+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
Wiki product allows an adversary to discover filenames via a series of queries starting with one letter and then iteratively extending the match.
+ Memberships
Section HelpThis 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 967 SFP Secondary Cluster: State Disclosure
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1396 Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

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

Comments

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

Maintenance

The relationship between CWE-202 and CWE-612 needs to be investigated more closely, as they may be different descriptions of the same kind of problem. CWE-202 is also being considered for deprecation, as it is not clearly described and may have been misunderstood by CWE users. It could be argued that this issue is better covered by CAPEC; an attacker can utilize their data-query privileges to perform this kind of operation, and if the attacker should not be allowed to perform the operation - or if the sensitive data should not have been made accessible at all - then that is more appropriately classified as a separate CWE related to authorization (see the parent, CWE-1230).

+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
CLASP Accidental leaking of sensitive information through data queries
+ References
[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005.
<https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>. (URL validated: 2024-11-17)
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
CLASP
+ Modifications
Modification Date Modifier Organization
2023-10-26 CWE Content Team MITRE
updated Observed_Examples
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Relationships, Type
2020-02-24 CWE Content Team MITRE
updated Maintenance_Notes, Name, References, Relationships
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms
2017-05-03 CWE Content Team MITRE
updated Related_Attack_Patterns
2014-07-30 CWE Content Team MITRE
updated Relationships
2013-02-21 CWE Content Team MITRE
updated Potential_Mitigations
2012-05-11 CWE Content Team MITRE
updated Related_Attack_Patterns, Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2011-03-29 CWE Content Team MITRE
updated Name
2008-09-08 CWE Content Team MITRE
updated Common_Consequences, Description, Relationships, Taxonomy_Mappings
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
+ Previous Entry Names
Change Date Previous Entry Name
2008-04-11 Information Leak Through Data Queries
2011-03-29 Privacy Leak through Data Queries
2020-02-24 Exposure of Sensitive Data Through Data Queries

CWE-1230: Exposure of Sensitive Information Through Metadata

Weakness ID: 1230
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product prevents direct access to a resource containing sensitive information, but it does not sufficiently limit access to metadata that is derived from the original, sensitive information.
+ Extended Description

Developers might correctly prevent unauthorized access to a database or other resource containing sensitive information, but they might not consider that portions of the original information might also be recorded in metadata, search indices, statistical reports, or other resources. If these resources are not also restricted, then attackers might be able to extract some or all of the original information, or otherwise infer some details. For example, an attacker could specify search terms that are known to be unique to a particular person, or view metadata such as activity or creation dates in order to identify usage patterns.

+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 285 Improper Authorization
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 202 Exposure of Sensitive Information Through Data Queries
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 612 Improper Authorization of Index Containing Sensitive Information
+ Relevant to the view "Software Development" (View-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 199 Information Management Errors
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1212 Authorization Errors
+ Modes Of Introduction
Section HelpThe 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
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

Operating Systems

Class: Not OS-Specific (Undetermined Prevalence)

Architectures

Class: Not Architecture-Specific (Undetermined Prevalence)

+ Memberships
Section HelpThis 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1396 Comprehensive Categorization: Access Control
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

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

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Content History
+ Submissions
Submission Date Submitter Organization
2020-01-26
(CWE 4.0, 2020-02-24)
CWE Content Team MITRE
+ Modifications
Modification Date Modifier Organization
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Relationships, Time_of_Introduction

CWE-200: Exposure of Sensitive Information to an Unauthorized Actor

Weakness ID: 200
Vulnerability Mapping: DISCOURAGED This CWE ID should not be used to map to real-world vulnerabilities
Abstraction: Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
+ Extended Description

There are many different kinds of mistakes that introduce information exposures. The severity of the error can range widely, depending on the context in which the product operates, the type of sensitive information that is revealed, and the benefits it may provide to an attacker. Some kinds of sensitive information include:

  • private, personal information, such as personal messages, financial data, health records, geographic location, or contact details
  • system status and environment, such as the operating system and installed packages
  • business secrets and intellectual property
  • network status and configuration
  • the product's own code or internal state
  • metadata, e.g. logging of connections or message headers
  • indirect information, such as a discrepancy between two internal operations that can be observed by an outsider

Information might be sensitive to different parties, each of which may have their own expectations for whether the information should be protected. These parties include:

  • the product's own users
  • people or organizations whose information is created or used by the product, even if they are not direct product users
  • the product's administrators, including the admins of the system(s) and/or networks on which the product operates
  • the developer

Information exposures can occur in different ways:

  • the code explicitly inserts sensitive information into resources or messages that are intentionally made accessible to unauthorized actors, but should not contain the information - i.e., the information should have been "scrubbed" or "sanitized"
  • a different weakness or mistake indirectly inserts the sensitive information into resources, such as a web script error revealing the full system path of the program.
  • the code manages resources that intentionally contain sensitive information, but the resources are unintentionally made accessible to unauthorized actors. In this case, the information exposure is resultant - i.e., a different weakness enabled the access to the information in the first place.

It is common practice to describe any loss of confidentiality as an "information exposure," but this can lead to overuse of CWE-200 in CWE mapping. From the CWE perspective, loss of confidentiality is a technical impact that can arise from dozens of different weaknesses, such as insecure file permissions or out-of-bounds read. CWE-200 and its lower-level descendants are intended to cover the mistakes that occur in behaviors that explicitly manage, store, transfer, or cleanse sensitive information.

+ Alternate Terms
Information Disclosure
This term is frequently used in vulnerability advisories to describe a consequence or technical impact, for any vulnerability that has a loss of confidentiality. Often, CWE-200 can be misused to represent the loss of confidentiality, even when the mistake - i.e., the weakness - is not directly related to the mishandling of the information itself, such as an out-of-bounds read that accesses sensitive memory contents; here, the out-of-bounds read is the primary weakness, not the disclosure of the memory. In addition, this phrase is also used frequently in policies and legal documents, but it does not refer to any disclosure of security-relevant information.
Information Leak
This is a frequently used term, however the "leak" term has multiple uses within security. In some cases it deals with the accidental exposure of information from a different weakness, but in other cases (such as "memory leak"), this deals with improper tracking of resources, which can lead to exhaustion. As a result, CWE is actively avoiding usage of the "leak" term.
+ Common Consequences
Section HelpThis 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.
Impact Details

Read Application Data

Scope: Confidentiality

+ Potential Mitigations
Phase(s) Mitigation

Architecture and Design

Strategy: Separation of Privilege

Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.

Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.

+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 668 Exposure of Resource to Wrong Sphere
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 201 Insertion of Sensitive Information Into Sent Data
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 203 Observable Discrepancy
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 209 Generation of Error Message Containing Sensitive Information
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 213 Exposure of Sensitive Information Due to Incompatible Policies
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 215 Insertion of Sensitive Information Into Debugging Code
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 359 Exposure of Private Personal Information to an Unauthorized Actor
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 497 Exposure of Sensitive System Information to an Unauthorized Control Sphere
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 538 Insertion of Sensitive Information into Externally-Accessible File or Directory
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1258 Exposure of Sensitive System Information Due to Uncleared Debug Information
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1273 Device Unlock Credential Sharing
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1295 Debug Messages Revealing Unnecessary Information
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1431 Driving Intermediate Cryptographic State/Results to Hardware Module Outputs
CanFollow Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 498 Cloneable Class Containing Sensitive Information
CanFollow Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 499 Serializable Class Containing Sensitive Data
CanFollow Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 1272 Sensitive Information Uncleared Before Debug/Power State Transition
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)
Nature Type ID Name
MemberOf View View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1003 Weaknesses for Simplified Mapping of Published Vulnerabilities
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 203 Observable Discrepancy
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 209 Generation of Error Message Containing Sensitive Information
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 532 Insertion of Sensitive Information into Log File
+ Modes Of Introduction
Section HelpThe 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
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Class: Mobile (Undetermined Prevalence)

+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1


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

(bad code)
Example Language: Perl 
my $username=param('username');
my $password=param('password');

if (IsValidUsername($username) == 1)
{
if (IsValidPassword($username, $password) == 1)
{
print "Login Successful";
}
else
{
print "Login Failed - incorrect password";
}
}
else
{
print "Login Failed - unknown username";
}

In the above code, there are different messages for when an incorrect username is supplied, versus when the username is correct but the password is wrong. This difference enables a potential attacker to understand the state of the login function, and could allow an attacker to discover a valid username by trying different values until the incorrect password message is returned. In essence, this makes it easier for an attacker to obtain half of the necessary authentication credentials.

While this type of information may be helpful to a user, it is also useful to a potential attacker. In the above example, the message for both failed cases should be the same, such as:

(result)
 
"Login Failed - incorrect username or password"


Example 2


This code tries to open a database connection, and prints any exceptions that occur.

(bad code)
Example Language: PHP 
try {
openDbConnection();
}
//print exception message that includes exception message and configuration file location
catch (Exception $e) {
echo 'Caught exception: ', $e->getMessage(), '\n';
echo 'Check credentials in config file at: ', $Mysql_config_location, '\n';
}

If an exception occurs, the printed message exposes the location of the configuration file the script is using. An attacker can use this information to target the configuration file (perhaps exploiting a Path Traversal weakness). If the file can be read, the attacker could gain credentials for accessing the database. The attacker may also be able to replace the file with a malicious one, causing the application to use an arbitrary database.



Example 3


In the example below, the method getUserBankAccount retrieves a bank account object from a database using the supplied username and account number to query the database. If an SQLException is raised when querying the database, an error message is created and output to a log file.

(bad code)
Example Language: Java 
public BankAccount getUserBankAccount(String username, String accountNumber) {
BankAccount userAccount = null;
String query = null;
try {
if (isAuthorizedUser(username)) {
query = "SELECT * FROM accounts WHERE owner = "
+ username + " AND accountID = " + accountNumber;
DatabaseManager dbManager = new DatabaseManager();
Connection conn = dbManager.getConnection();
Statement stmt = conn.createStatement();
ResultSet queryResult = stmt.executeQuery(query);
userAccount = (BankAccount)queryResult.getObject(accountNumber);
}
} catch (SQLException ex) {
String logMessage = "Unable to retrieve account information from database,\nquery: " + query;
Logger.getLogger(BankManager.class.getName()).log(Level.SEVERE, logMessage, ex);
}
return userAccount;
}

The error message that is created includes information about the database query that may contain sensitive information about the database or query logic. In this case, the error message will expose the table name and column names used in the database. This data could be used to simplify other attacks, such as SQL injection (CWE-89) to directly access the database.



Example 4


This code stores location information about the current user:

(bad code)
Example Language: Java 
locationClient = new LocationClient(this, this, this);
locationClient.connect();
currentUser.setLocation(locationClient.getLastLocation());
...

catch (Exception e) {
AlertDialog.Builder builder = new AlertDialog.Builder(this);
builder.setMessage("Sorry, this application has experienced an error.");
AlertDialog alert = builder.create();
alert.show();
Log.e("ExampleActivity", "Caught exception: " + e + " While on User:" + User.toString());
}

When the application encounters an exception it will write the user object to the log. Because the user object contains location information, the user's location is also written to the log.



Example 5


The following is an actual MySQL error statement:

(result)
Example Language: SQL 
Warning: mysql_pconnect(): Access denied for user: 'root@localhost' (Using password: N1nj4) in /usr/local/www/wi-data/includes/database.inc on line 4

The error clearly exposes the database credentials.



Example 6


This code displays some information on a web page.

(bad code)
Example Language: JSP 
Social Security Number: <%= ssn %></br>Credit Card Number: <%= ccn %>

The code displays a user's credit card and social security numbers, even though they aren't absolutely necessary.



Example 7


The following program changes its behavior based on a debug flag.

(bad code)
Example Language: JSP 
<% if (Boolean.getBoolean("debugEnabled")) {
%>
User account number: <%= acctNo %>
<%
} %>

The code writes sensitive debug information to the client browser if the "debugEnabled" flag is set to true .



Example 8


This code uses location to determine the user's current US State location.

First the application must declare that it requires the ACCESS_FINE_LOCATION permission in the application's manifest.xml:

(bad code)
Example Language: XML 
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>

During execution, a call to getLastLocation() will return a location based on the application's location permissions. In this case the application has permission for the most accurate location possible:

(bad code)
Example Language: Java 
locationClient = new LocationClient(this, this, this);
locationClient.connect();
Location userCurrLocation;
userCurrLocation = locationClient.getLastLocation();
deriveStateFromCoords(userCurrLocation);

While the application needs this information, it does not need to use the ACCESS_FINE_LOCATION permission, as the ACCESS_COARSE_LOCATION permission will be sufficient to identify which US state the user is in.



+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
Rust library leaks Oauth client details in application debug logs
Digital Rights Management (DRM) capability for mobile platform leaks pointer information, simplifying ASLR bypass
Enumeration of valid usernames based on inconsistent responses
Account number enumeration via inconsistent responses.
User enumeration via discrepancies in error messages.
Telnet protocol allows servers to obtain sensitive environment information from clients.
Script calls phpinfo(), revealing system configuration to web user
Product sets a different TTL when a port is being filtered than when it is not being filtered, which allows remote attackers to identify filtered ports by comparing TTLs.
Version control system allows remote attackers to determine the existence of arbitrary files and directories via the -X command for an alternate history file, which causes different error messages to be returned.
Virtual machine allows malicious web site operators to determine the existence of files on the client by measuring delays in the execution of the getSystemResource method.
Product immediately sends an error message when a user does not exist, which allows remote attackers to determine valid usernames via a timing attack.
POP3 server reveals a password in an error message after multiple APOP commands are sent. Might be resultant from another weakness.
Program reveals password in error message if attacker can trigger certain database errors.
Composite: application running with high privileges (CWE-250) allows user to specify a restricted file to process, which generates a parsing error that leaks the contents of the file (CWE-209).
Direct request to library file in web application triggers pathname leak in error message.
Malformed regexp syntax leads to information exposure in error message.
Password exposed in debug information.
FTP client with debug option enabled shows password to the screen.
Collaboration platform does not clear team emails in a response, allowing leak of email addresses
+ Weakness Ordinalities
Ordinality Description
Primary
(where the weakness exists independent of other weaknesses)
Developers may insert sensitive information that they do not believe, or they might forget to remove the sensitive information after it has been processed
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
Separate mistakes or weaknesses could inadvertently make the sensitive information available to an attacker, such as in a detailed error message that can be read by an unauthorized party
+ Detection Methods
Method Details

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
  • Inter-application Flow Analysis

Effectiveness: SOAR Partial

Dynamic Analysis with Automated Results Interpretation

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

Highly cost effective:
  • Web Application Scanner
  • Web Services Scanner
  • Database Scanners

Effectiveness: High

Dynamic Analysis with Manual Results Interpretation

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

Cost effective for partial coverage:
  • Fuzz Tester
  • Framework-based Fuzzer
  • Automated Monitored Execution
  • Monitored Virtual Environment - run potentially malicious code in sandbox / wrapper / virtual machine, see if it does anything suspicious

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

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

Highly cost effective:
  • Manual Source Code Review (not inspections)

Effectiveness: High

Automated Static Analysis - Source Code

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

Highly cost effective:
  • Context-configured Source Code Weakness Analyzer
Cost effective for partial coverage:
  • 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:
  • Attack Modeling
  • Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)

Effectiveness: High

+ Memberships
Section HelpThis 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 ViewView - 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 717 OWASP Top Ten 2007 Category A6 - Information Leakage and Improper Error Handling
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 963 SFP Secondary Cluster: Exposed Data
MemberOf ViewView - 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 ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1337 Weaknesses in the 2021 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf CategoryCategory - 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 ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1350 Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1417 Comprehensive Categorization: Sensitive Information Exposure
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1430 Weaknesses in the 2024 CWE Top 25 Most Dangerous Software Weaknesses
+ Vulnerability Mapping Notes
Usage DISCOURAGED
(this CWE ID should not be used to map to real-world vulnerabilities)
Reason Frequent Misuse

Rationale

CWE-200 is commonly misused to represent the loss of confidentiality in a vulnerability, but confidentiality loss is a technical impact - not a root cause error. As of CWE 4.9, over 400 CWE entries can lead to a loss of confidentiality. Other options are often available. [REF-1287].

Comments

If an error or mistake causes information to be disclosed, then use the CWE ID for that error. Consider starting with improper authorization (CWE-285), insecure permissions (CWE-732), improper authentication (CWE-287), etc. Also consider children such as Insertion of Sensitive Information Into Sent Data (CWE-201), Observable Discrepancy (CWE-203), Insertion of Sensitive Information into Externally-Accessible File or Directory (CWE-538), or others.
+ Notes

Maintenance

As a result of mapping analysis in the 2020 Top 25 and more recent versions, this weakness is under review, since it is frequently misused in mapping to cover many problems that lead to loss of confidentiality. See Mapping Notes, Extended Description, and Alternate Terms.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER Information Leak (information disclosure)
OWASP Top Ten 2007 A6 CWE More Specific Information Leakage and Improper Error Handling
WASC 13 Information Leakage
+ References
[REF-172] Chris Wysopal. "Mobile App Top 10 List". 2010-12-13.
<https://www.veracode.com/blog/2010/12/mobile-app-top-10-list>. (URL validated: 2023-04-07)
[REF-1287] MITRE. "Supplemental Details - 2022 CWE Top 25". Details of Problematic Mappings. 2022-06-28.
<https://cwe.mitre.org/top25/archive/2022/2022_cwe_top25_supplemental.html#problematicMappingDetails>. (URL validated: 2024-11-17)
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Contributions
Contribution Date Contributor Organization
2022-07-11 Nick Johnston
Identified incorrect language tag in demonstrative example.
+ Modifications
Modification Date Modifier Organization
2025-04-03
(CWE 4.17, 2025-04-03)
CWE Content Team MITRE
updated Relationships
2024-11-19
(CWE 4.16, 2024-11-19)
CWE Content Team MITRE
updated Relationships
2023-10-26 CWE Content Team MITRE
updated Observed_Examples
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated References, Relationships
2022-10-13 CWE Content Team MITRE
updated Demonstrative_Examples, Maintenance_Notes, Observed_Examples, References
2021-10-28 CWE Content Team MITRE
updated Relationships
2021-07-20 CWE Content Team MITRE
updated Relationships
2020-12-10 CWE Content Team MITRE
updated Potential_Mitigations
2020-08-20 CWE Content Team MITRE
updated Alternate_Terms, Description, Maintenance_Notes, Related_Attack_Patterns, Relationships
2020-06-25 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Applicable_Platforms, Demonstrative_Examples, Description, Name, Observed_Examples, Related_Attack_Patterns, Relationships, Weakness_Ordinalities
2019-09-19 CWE Content Team MITRE
updated Demonstrative_Examples, Observed_Examples, Relationships
2019-06-20 CWE Content Team MITRE
updated Related_Attack_Patterns, Relationships
2019-01-03 CWE Content Team MITRE
updated Related_Attack_Patterns
2017-11-08 CWE Content Team MITRE
updated References
2017-05-03 CWE Content Team MITRE
updated Related_Attack_Patterns
2015-12-07 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Detection_Factors, Relationships
2014-06-23 CWE Content Team MITRE
updated Related_Attack_Patterns
2013-02-21 CWE Content Team MITRE
updated Alternate_Terms, Applicable_Platforms, References
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2012-05-11 CWE Content Team MITRE
updated Related_Attack_Patterns, Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2011-03-29 CWE Content Team MITRE
updated Description, Relationships
2010-04-05 CWE Content Team MITRE
updated Related_Attack_Patterns
2010-02-16 CWE Content Team MITRE
updated Taxonomy_Mappings
2009-12-28 CWE Content Team MITRE
updated Alternate_Terms, Description, Name
2008-10-14 CWE Content Team MITRE
updated Description
2008-09-08 CWE Content Team MITRE
updated Likelihood_of_Exploit, Relationships, Taxonomy_Mappings, Weakness_Ordinalities
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
+ Previous Entry Names
Change Date Previous Entry Name
2009-12-28 Information Leak (Information Disclosure)
2020-02-24 Information Exposure

CWE-1258: Exposure of Sensitive System Information Due to Uncleared Debug Information

Weakness ID: 1258
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The hardware does not fully clear security-sensitive values, such as keys and intermediate values in cryptographic operations, when debug mode is entered.
+ Extended Description

Security sensitive values, keys, intermediate steps of cryptographic operations, etc. are stored in temporary registers in the hardware. If these values are not cleared when debug mode is entered they may be accessed by a debugger allowing sensitive information to be accessible by untrusted parties.

+ Common Consequences
Section HelpThis 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.
Impact Details

Read Memory

Scope: Confidentiality

Bypass Protection Mechanism

Scope: Access Control

+ Potential Mitigations
Phase(s) Mitigation

Architecture and Design

Whenever debug mode is enabled, all registers containing sensitive assets must be cleared.

+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 200 Exposure of Sensitive Information to an Unauthorized Actor
ChildOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 212 Improper Removal of Sensitive Information Before Storage or Transfer
+ Relevant to the view "Hardware Design" (View-1194)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1207 Debug and Test Problems
+ Modes Of Introduction
Section HelpThe 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
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

Operating Systems

Class: Not OS-Specific (Undetermined Prevalence)

Architectures

Class: Not Architecture-Specific (Undetermined Prevalence)

Technologies

Class: Not Technology-Specific (Undetermined Prevalence)

+ Demonstrative Examples

Example 1


A cryptographic core in a System-On-a-Chip (SoC) is used for cryptographic acceleration and implements several cryptographic operations (e.g., computation of AES encryption and decryption, SHA-256, HMAC, etc.). The keys for these operations or the intermediate values are stored in registers internal to the cryptographic core. These internal registers are in the Memory Mapped Input Output (MMIO) space and are blocked from access by software and other untrusted agents on the SoC. These registers are accessible through the debug and test interface.

(bad code)
Example Language: Other 
In the above scenario, registers that store keys and intermediate values of cryptographic operations are not cleared when system enters debug mode. An untrusted actor running a debugger may read the contents of these registers and gain access to secret keys and other sensitive cryptographic information.
(good code)
Example Language: Other 
Whenever the chip enters debug mode, all registers containing security-sensitive data are be cleared rendering them unreadable.


Example 2


The following code example is extracted from the AES wrapper module, aes1_wrapper, of the Hack@DAC'21 buggy OpenPiton System-on-Chip (SoC). Within this wrapper module are four memory-mapped registers: core_key, core_key0, core_key1, and core_key2. Core_key0, core_key1, and core_key2 hold encryption/decryption keys. The core_key register selects a key and sends it to the underlying AES module to execute encryption/decryption operations.

Debug mode in processors and SoCs facilitates design debugging by granting access to internal signal/register values, including physical pin values of peripherals/core, fabric bus data transactions, and inter-peripheral registers. Debug mode allows users to gather detailed, low-level information about the design to diagnose potential issues. While debug mode is beneficial for diagnosing processors or SoCs, it also introduces a new attack surface for potential attackers. For instance, if an attacker gains access to debug mode, they could potentially read any content transmitted through the fabric bus or access encryption/decryption keys stored in cryptographic peripherals.

Therefore, it is crucial to clear the contents of secret registers upon entering debug mode. In the provided example of flawed code below, when debug_mode_i is activated, the register core_key0 is set to zero to prevent AES key leakage during debugging. However, this protective measure is not applied to the core_key1 register [REF-1435], leaving its contents uncleared during debug mode. This oversight enables a debugger to access sensitive information. Failing to clear sensitive data during debug mode may lead to unauthorized access to secret keys and compromise system security.

(bad code)
Example Language: Verilog 
module aes1_wrapper #(
...
assign core_key0 = debug_mode_i ? 'b0 : {
key_reg0[7],
key_reg0[6],
key_reg0[5],
key_reg0[4],
key_reg0[3],
key_reg0[2],
key_reg0[1],
key_reg0[0]};
assign core_key1 = {
key_reg1[7],
key_reg1[6],
key_reg1[5],
key_reg1[4],
key_reg1[3],
key_reg1[2],
key_reg1[1],
key_reg1[0]};
...
endmodule

To address the issue, it is essential to ensure that the register is cleared and zeroized after activating debug mode on the SoC. In the correct implementation illustrated in the good code below, core_keyx registers are set to zero when debug mode is activated [REF-1436].

(good code)
Example Language: Verilog 
module aes1_wrapper #(
...
assign core_key0 = debug_mode_i ? 'b0 : {
key_reg0[7],
key_reg0[6],
key_reg0[5],
key_reg0[4],
key_reg0[3],
key_reg0[2],
key_reg0[1],
key_reg0[0]};
assign core_key1 = debug_mode_i ? 'b0 : {
key_reg1[7],
key_reg1[6],
key_reg1[5],
key_reg1[4],
key_reg1[3],
key_reg1[2],
key_reg1[1],
key_reg1[0]};
...
endmodule


+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
Uncleared debug information in memory accelerator for SSD product exposes sensitive system information
Rust library leaks Oauth client details in application debug logs
+ Memberships
Section HelpThis 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1416 Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

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

Comments

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ Content History
+ Submissions
Submission Date Submitter Organization
2020-02-12
(CWE 4.1, 2020-02-24)
Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V Mangipudi Intel Corporation
+ Contributions
Contribution Date Contributor Organization
2023-11-07 Mohamadreza Rostami, Shaza Zeitouni, Ahmad-Reza Sadeghi Technical University of Darmstadt
suggested demonstrative example
2023-11-07 Rahul Kande, Chen Chen, Jeyavijayan Rajendran Texas A&M University
suggested demonstrative example
+ Modifications
Modification Date Modifier Organization
2024-07-16
(CWE 4.15, 2024-07-16)
CWE Content Team MITRE
updated Demonstrative_Examples, References
2023-10-26 CWE Content Team MITRE
updated Observed_Examples
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Relationships
2020-08-20 CWE Content Team MITRE
updated Demonstrative_Examples, Description, Name, Related_Attack_Patterns, Relationships
+ Previous Entry Names
Change Date Previous Entry Name
2020-08-20 Sensitive Information Uncleared During Hardware Debug Flows

CWE-642: External Control of Critical State Data

Weakness ID: 642
Vulnerability Mapping: ALLOWED This CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product stores security-critical state information about its users, or the product itself, in a location that is accessible to unauthorized actors.
+ Extended Description

If an attacker can modify the state information without detection, then it could be used to perform unauthorized actions or access unexpected resources, since the application programmer does not expect that the state can be changed.

State information can be stored in various locations such as a cookie, in a hidden web form field, input parameter or argument, an environment variable, a database record, within a settings file, etc. All of these locations have the potential to be modified by an attacker. When this state information is used to control security or determine resource usage, then it may create a vulnerability. For example, an application may perform authentication, then save the state in an "authenticated=true" cookie. An attacker may simply create this cookie in order to bypass the authentication.

+ Common Consequences
Section HelpThis 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.
Impact Details

Bypass Protection Mechanism; Gain Privileges or Assume Identity

Scope: Access Control

An attacker could potentially modify the state in malicious ways. If the state is related to the privileges or level of authentication that the user has, then state modification might allow the user to bypass authentication or elevate privileges.

Read Application Data

Scope: Confidentiality

The state variables may contain sensitive information that should not be known by the client.

DoS: Crash, Exit, or Restart

Scope: Availability

By modifying state variables, the attacker could violate the application's expectations for the contents of the state, leading to a denial of service due to an unexpected error condition.
+ Potential Mitigations
Phase(s) Mitigation

Architecture and Design

Understand all the potential locations that are accessible to attackers. For example, some programmers assume that cookies and hidden form fields cannot be modified by an attacker, or they may not consider that environment variables can be modified before a privileged program is invoked.

Architecture and Design

Strategy: Attack Surface Reduction

Store state information and sensitive data on the server side only.

Ensure that the system definitively and unambiguously keeps track of its own state and user state and has rules defined for legitimate state transitions. Do not allow any application user to affect state directly in any way other than through legitimate actions leading to state transitions.

If information must be stored on the client, do not do so without encryption and integrity checking, or otherwise having a mechanism on the server side to catch tampering. Use a message authentication code (MAC) algorithm, such as Hash Message Authentication Code (HMAC) [REF-529]. Apply this against the state or sensitive data that has to be exposed, which can guarantee the integrity of the data - i.e., that the data has not been modified. Ensure that a strong hash function is used (CWE-328).

Architecture and Design

Store state information on the server side only. Ensure that the system definitively and unambiguously keeps track of its own state and user state and has rules defined for legitimate state transitions. Do not allow any application user to affect state directly in any way other than through legitimate actions leading to state transitions.

Architecture and Design

Strategy: Libraries or Frameworks

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

With a stateless protocol such as HTTP, use some frameworks can maintain the state for you.

Examples include ASP.NET View State and the OWASP ESAPI Session Management feature.

Be careful of language features that provide state support, since these might be provided as a convenience to the programmer and may not be considering security.

Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Operation; Implementation

Strategy: Environment Hardening

When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.

Testing

Use automated static analysis tools that target this type of weakness. Many modern techniques use data flow analysis to minimize the number of false positives. This is not a perfect solution, since 100% accuracy and coverage are not feasible.

Testing

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

Testing

Use tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.
+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 668 Exposure of Resource to Wrong Sphere
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 15 External Control of System or Configuration Setting
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 73 External Control of File Name or Path
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 426 Untrusted Search Path
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 472 External Control of Assumed-Immutable Web Parameter
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 565 Reliance on Cookies without Validation and Integrity Checking
+ Relevant to the view "Architectural Concepts" (View-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1011 Authorize Actors
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Implementation
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

Technologies

Web Server (Often Prevalent)

+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1


In the following example, an authentication flag is read from a browser cookie, thus allowing for external control of user state data.

(bad code)
Example Language: Java 
Cookie[] cookies = request.getCookies();
for (int i =0; i< cookies.length; i++) {
Cookie c = cookies[i];
if (c.getName().equals("authenticated") && Boolean.TRUE.equals(c.getValue())) {
authenticated = true;
}
}


Example 2


The following code uses input from an HTTP request to create a file name. The programmer has not considered the possibility that an attacker could provide a file name such as "../../tomcat/conf/server.xml", which causes the application to delete one of its own configuration files (CWE-22).

(bad code)
Example Language: Java 
String rName = request.getParameter("reportName");
File rFile = new File("/usr/local/apfr/reports/" + rName);
...
rFile.delete();


Example 3


The following code uses input from a configuration file to determine which file to open and echo back to the user. If the program runs with privileges and malicious users can change the configuration file, they can use the program to read any file on the system that ends with the extension .txt.

(bad code)
Example Language: Java 
fis = new FileInputStream(cfg.getProperty("sub")+".txt");
amt = fis.read(arr);
out.println(arr);


Example 4


This program is intended to execute a command that lists the contents of a restricted directory, then performs other actions. Assume that it runs with setuid privileges in order to bypass the permissions check by the operating system.

(bad code)
Example Language:
#define DIR "/restricted/directory"

char cmd[500];
sprintf(cmd, "ls -l %480s", DIR);
/* Raise privileges to those needed for accessing DIR. */

RaisePrivileges(...);
system(cmd);
DropPrivileges(...);
...

This code may look harmless at first, since both the directory and the command are set to fixed values that the attacker can't control. The attacker can only see the contents for DIR, which is the intended program behavior. Finally, the programmer is also careful to limit the code that executes with raised privileges.

However, because the program does not modify the PATH environment variable, the following attack would work:

(attack code)
 
  • The user sets the PATH to reference a directory under the attacker's control, such as "/my/dir/".
  • The attacker creates a malicious program called "ls", and puts that program in /my/dir
  • The user executes the program.
  • When system() is executed, the shell consults the PATH to find the ls program
  • The program finds the attacker's malicious program, "/my/dir/ls". It doesn't find "/bin/ls" because PATH does not contain "/bin/".
  • The program executes the attacker's malicious program with the raised privileges.


Example 5


The following code segment implements a basic server that uses the "ls" program to perform a directory listing of the directory that is listed in the "HOMEDIR" environment variable. The code intends to allow the user to specify an alternate "LANG" environment variable. This causes "ls" to customize its output based on a given language, which is an important capability when supporting internationalization.

(bad code)
Example Language: Perl 
$ENV{"HOMEDIR"} = "/home/mydir/public/";
my $stream = AcceptUntrustedInputStream();
while (<$stream>) {
chomp;
if (/^ENV ([\w\_]+) (.*)/) {
$ENV{$1} = $2;
}
elsif (/^QUIT/) { ... }
elsif (/^LIST/) {
open($fh, "/bin/ls -l $ENV{HOMEDIR}|");
while (<$fh>) {
SendOutput($stream, "FILEINFO: $_");
}
close($fh);
}
}

The programmer takes care to call a specific "ls" program and sets the HOMEDIR to a fixed value. However, an attacker can use a command such as "ENV HOMEDIR /secret/directory" to specify an alternate directory, enabling a path traversal attack (CWE-22). At the same time, other attacks are enabled as well, such as OS command injection (CWE-78) by setting HOMEDIR to a value such as "/tmp; rm -rf /". In this case, the programmer never intends for HOMEDIR to be modified, so input validation for HOMEDIR is not the solution. A partial solution would be an allowlist that only allows the LANG variable to be specified in the ENV command. Alternately, assuming this is an authenticated user, the language could be stored in a local file so that no ENV command at all would be needed.

While this example may not appear realistic, this type of problem shows up in code fairly frequently. See CVE-1999-0073 in the observed examples for a real-world example with similar behaviors.



+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
Mail client stores password hashes for unrelated accounts in a hidden form field.
Privileged program trusts user-specified environment variable to modify critical configuration settings.
Telnet daemon allows remote clients to specify critical environment variables for the server, leading to code execution.
Untrusted search path vulnerability through modified LD_LIBRARY_PATH environment variable.
Untrusted search path vulnerability through modified LD_LIBRARY_PATH environment variable.
Calendar application allows bypass of authentication by setting a certain cookie value to 1.
Setting of a language preference in a cookie enables path traversal attack.
Application allows admin privileges by setting a cookie value to "admin."
Application allows admin privileges by setting a cookie value to "admin."
Application allows admin privileges by setting a cookie value to "admin."
Shopping cart allows price modification via hidden form field.
Shopping cart allows price modification via hidden form field.
Server allows client to specify the search path, which can be modified to point to a program that the client has uploaded.
+ Detection Methods
Method Details

Automated Static Analysis

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

Effectiveness: High

+ Memberships
Section HelpThis 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 752 2009 Top 25 - Risky Resource Management
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 963 SFP Secondary Cluster: Exposed Data
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1348 OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1403 Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes
Usage ALLOWED-WITH-REVIEW
(this CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review)
Reason Abstraction

Rationale

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

Comments

Examine children of this entry to see if there is a better fit
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
Software Fault Patterns SFP23 Exposed Data
+ References
[REF-528] OWASP. "Top 10 2007-Insecure Direct Object Reference". 2007.
<http://www.owasp.org/index.php/Top_10_2007-A4>.
[REF-529] "HMAC". Wikipedia. 2011-08-18.
<https://en.wikipedia.org/wiki/HMAC>. (URL validated: 2023-04-07)
[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 4: Use of Magic URLs, Predictable Cookies, and Hidden Form Fields." Page 75. McGraw-Hill. 2010.
+ Content History
+ Submissions
Submission Date Submitter Organization
2008-01-30
(CWE Draft 8, 2008-01-30)
Evgeny Lebanidze Cigital
+ Modifications
Modification Date Modifier Organization
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Detection_Factors, Potential_Mitigations, References, Relationships
2023-01-31 CWE Content Team MITRE
updated Description, Potential_Mitigations
2021-10-28 CWE Content Team MITRE
updated Relationships
2021-03-15 CWE Content Team MITRE
updated Demonstrative_Examples
2020-06-25 CWE Content Team MITRE
updated Demonstrative_Examples
2020-02-24 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Demonstrative_Examples, Enabling_Factors_for_Exploitation, Modes_of_Introduction, References, Relationships, Relevant_Properties
2017-01-19 CWE Content Team MITRE
updated Related_Attack_Patterns, Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2014-02-18 CWE Content Team MITRE
updated Potential_Mitigations
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2012-05-11 CWE Content Team MITRE
updated Demonstrative_Examples, Potential_Mitigations, References, Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2010-06-21 CWE Content Team MITRE
updated Potential_Mitigations
2010-02-16 CWE Content Team MITRE
updated Potential_Mitigations
2009-07-27 CWE Content Team MITRE
updated Related_Attack_Patterns
2009-03-10 CWE Content Team MITRE
updated Potential_Mitigations
2009-01-12 CWE Content Team MITRE
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Name, Observed_Examples, Potential_Mitigations, References, Relationships, Relevant_Properties, Type
2008-10-14 CWE Content Team MITRE
updated Description
2008-09-08 CWE Content Team MITRE
updated Common_Consequences, Relationships
2008-07-01 Sean Eidemiller Cigital
added/updated demonstrative examples
+ Previous Entry Names
Change Date Previous Entry Name
2008-04-11 Insufficient Management of User State
2009-01-12 External Control of User State Data

CWE-73: External Control of File Name or Path

Weakness ID: 73
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product allows user input to control or influence paths or file names that are used in filesystem operations.
+ Extended Description

This could allow an attacker to access or modify system files or other files that are critical to the application.

Path manipulation errors occur when the following two conditions are met:

1. An attacker can specify a path used in an operation on the filesystem.
2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.

For example, the program may give the attacker the ability to overwrite the specified file or run with a configuration controlled by the attacker.

+ Common Consequences
Section HelpThis 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.
Impact Details

Read Files or Directories; Modify Files or Directories

Scope: Integrity, Confidentiality

The application can operate on unexpected files. Confidentiality is violated when the targeted filename is not directly readable by the attacker.

Modify Files or Directories; Execute Unauthorized Code or Commands

Scope: Integrity, Confidentiality, Availability

The application can operate on unexpected files. This may violate integrity if the filename is written to, or if the filename is for a program or other form of executable code.

DoS: Crash, Exit, or Restart; DoS: Resource Consumption (Other)

Scope: Availability

The application can operate on unexpected files. Availability can be violated if the attacker specifies an unexpected file that the application modifies. Availability can also be affected if the attacker specifies a filename for a large file, or points to a special device or a file that does not have the format that the application expects.
+ Potential Mitigations
Phase(s) Mitigation

Architecture and Design

When the set of filenames is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames, and reject all other inputs. For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt". Features such as the ESAPI AccessReferenceMap provide this capability.

Architecture and Design; Operation

Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict all access to files within a particular directory.

Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection.

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

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

Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Implementation

Strategy: Input Validation

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

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

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

When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single "." character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as "/" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434.

Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering "/" is insufficient protection if the filesystem also supports the use of "\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if "../" sequences are removed from the ".../...//" string in a sequential fashion, two instances of "../" would be removed from the original string, but the remaining characters would still form the "../" string.

Effectiveness: High

Implementation

Use a built-in path canonicalization function (such as realpath() in C) that produces the canonical version of the pathname, which effectively removes ".." sequences and symbolic links (CWE-23, CWE-59).

Installation; Operation

Use OS-level permissions and run as a low-privileged user to limit the scope of any successful attack.

Operation; Implementation

If you are using PHP, configure your application so that it does not use register_globals. During implementation, develop your application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.

Testing

Use tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.
+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 610 Externally Controlled Reference to a Resource in Another Sphere
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 642 External Control of Critical State Data
ParentOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 114 Process Control
CanPrecede Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
CanPrecede Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 41 Improper Resolution of Path Equivalence
CanPrecede Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 59 Improper Link Resolution Before File Access ('Link Following')
CanPrecede Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 98 Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')
CanPrecede Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 434 Unrestricted Upload of File with Dangerous Type
+ Relevant to the view "Software Development" (View-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 399 Resource Management Errors
+ Relevant to the view "Architectural Concepts" (View-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1015 Limit Access
+ Relevant to the view "Seven Pernicious Kingdoms" (View-700)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 20 Improper Input Validation
+ Modes Of Introduction
Section HelpThe 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 REALIZATION: This weakness is caused during implementation of an architectural security tactic.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

Operating Systems

Class: Unix (Often Prevalent)

Class: Windows (Often Prevalent)

Class: macOS (Often Prevalent)

+ Likelihood Of Exploit
High
+ Demonstrative Examples

Example 1


The following code uses input from an HTTP request to create a file name. The programmer has not considered the possibility that an attacker could provide a file name such as "../../tomcat/conf/server.xml", which causes the application to delete one of its own configuration files (CWE-22).

(bad code)
Example Language: Java 
String rName = request.getParameter("reportName");
File rFile = new File("/usr/local/apfr/reports/" + rName);
...
rFile.delete();


Example 2


The following code uses input from a configuration file to determine which file to open and echo back to the user. If the program runs with privileges and malicious users can change the configuration file, they can use the program to read any file on the system that ends with the extension .txt.

(bad code)
Example Language: Java 
fis = new FileInputStream(cfg.getProperty("sub")+".txt");
amt = fis.read(arr);
out.println(arr);


+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
Chain: a learning management tool debugger uses external input to locate previous session logs (CWE-73) and does not properly validate the given path (CWE-20), allowing for filesystem path traversal using "../" sequences (CWE-24)
Chain: external control of values for user's desired language and theme enables path traversal.
Chain: external control of user's target language enables remote file inclusion.
+ Weakness Ordinalities
Ordinality Description
Primary
(where the weakness exists independent of other weaknesses)
+ Detection Methods
Method Details

Automated Static Analysis

The external control or influence of filenames can often be detected using automated static analysis that models data flow within the product.

Automated static analysis might not be able to recognize when proper input validation is being performed, leading to false positives - i.e., warnings that do not have any security consequences or require any code changes.

+ Memberships
Section HelpThis 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 CategoryCategory - 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 752 2009 Top 25 - Risky Resource Management
MemberOf CategoryCategory - 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 981 SFP Secondary Cluster: Path Traversal
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1348 OWASP Top Ten 2021 Category A04:2021 - Insecure Design
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1403 Comprehensive Categorization: Exposed Resource
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

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

Comments

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

Relationship

The external control of filenames can be the primary link in chains with other file-related weaknesses, as seen in the CanPrecede relationships. This is because software systems use files for many different purposes: to execute programs, load code libraries, to store application data, to store configuration settings, record temporary data, act as signals or semaphores to other processes, etc.

However, those weaknesses do not always require external control. For example, link-following weaknesses (CWE-59) often involve pathnames that are not controllable by the attacker at all.

The external control can be resultant from other issues. For example, in PHP applications, the register_globals setting can allow an attacker to modify variables that the programmer thought were immutable, enabling file inclusion (CWE-98) and path traversal (CWE-22). Operating with excessive privileges (CWE-250) might allow an attacker to specify an input filename that is not directly readable by the attacker, but is accessible to the privileged program. A buffer overflow (CWE-119) might give an attacker control over nearby memory locations that are related to pathnames, but were not directly modifiable by the attacker.

Maintenance

CWE-114 is a Class, but it is listed a child of CWE-73 in view 1000. This suggests some abstraction problems that should be resolved in future versions.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
7 Pernicious Kingdoms Path Manipulation
Software Fault Patterns SFP16 Path Traversal
+ 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-45] OWASP. "OWASP Enterprise Security API (ESAPI) Project".
<http://www.owasp.org/index.php/ESAPI>.
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
7 Pernicious Kingdoms
+ Modifications
Modification Date Modifier Organization
2023-10-26 CWE Content Team MITRE
updated Observed_Examples
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Potential_Mitigations, Relationships
2023-01-31 CWE Content Team MITRE
updated Description, Detection_Factors, Potential_Mitigations
2021-10-28 CWE Content Team MITRE
updated Relationships
2021-03-15 CWE Content Team MITRE
updated Maintenance_Notes, Potential_Mitigations
2020-06-25 CWE Content Team MITRE
updated Potential_Mitigations, Relationships
2020-02-24 CWE Content Team MITRE
updated Potential_Mitigations, References, Relationships, Time_of_Introduction, Type
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Likelihood_of_Exploit, Modes_of_Introduction, Relationships, Taxonomy_Mappings
2014-07-30 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2012-05-11 CWE Content Team MITRE
updated Demonstrative_Examples, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2011-09-13 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2010-02-16 CWE Content Team MITRE
updated Potential_Mitigations
2009-12-28 CWE Content Team MITRE
updated Detection_Factors
2009-10-29 CWE Content Team MITRE
updated Common_Consequences, Description
2009-07-27 CWE Content Team MITRE
updated Demonstrative_Examples
2009-03-10 CWE Content Team MITRE
updated Potential_Mitigations, Relationships
2009-01-12 CWE Content Team MITRE
updated Applicable_Platforms, Causal_Nature, Common_Consequences, Demonstrative_Examples, Description, Observed_Examples, Other_Notes, Potential_Mitigations, References, Relationship_Notes, Relationships, Weakness_Ordinalities
2008-09-08 CWE Content Team MITRE
updated Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
+ Previous Entry Names
Change Date Previous Entry Name
2008-04-11 Path Manipulation

CWE-673: External Influence of Sphere Definition

Weakness ID: 673
Vulnerability Mapping: ALLOWED This CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product does not prevent the definition of control spheres from external actors.
+ Extended Description
Typically, a product defines its control sphere within the code itself, or through configuration by the product's administrator. In some cases, an external party can change the definition of the control sphere. This is typically a resultant weakness.
+ Common Consequences
Section HelpThis 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.
Impact Details

Other

Scope: Other

+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Pillar Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things. 664 Improper Control of a Resource Through its Lifetime
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 426 Untrusted Search Path
+ Relevant to the view "Architectural Concepts" (View-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1011 Authorize Actors
+ Modes Of Introduction
Section HelpThe 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 REALIZATION: This weakness is caused during implementation of an architectural security tactic.
+ Demonstrative Examples

Example 1


Consider a blog publishing tool, which might have three explicit control spheres: the creation of articles, only accessible to a "publisher;" commenting on articles, only accessible to a "commenter" who is a registered user; and reading articles, only accessible to an anonymous reader. Suppose that the application is deployed on a web server that is shared with untrusted parties. If a local user can modify the data files that define who a publisher is, then this user has modified the control sphere. In this case, the issue would be resultant from another weakness such as insufficient permissions.



Example 2


In Untrusted Search Path (CWE-426), a user might be able to define the PATH environment variable to cause the product to search in the wrong directory for a library to load. The product's intended sphere of control would include "resources that are only modifiable by the person who installed the product." The PATH effectively changes the definition of this sphere so that it overlaps the attacker's sphere of control.



+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
setuid program allows compromise using path that finds and loads a malicious library.
+ Memberships
Section HelpThis 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 991 SFP Secondary Cluster: Tainted Input to Environment
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1416 Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes
Usage ALLOWED-WITH-REVIEW
(this CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review)
Reason Abstraction

Rationale

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

Comments

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

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.
+ Content History
+ Submissions
Submission Date Submitter Organization
2008-04-11
(CWE Draft 9, 2008-04-11)
CWE Content Team MITRE
+ Modifications
Modification Date Modifier Organization
2023-10-26 CWE Content Team MITRE
updated Observed_Examples
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Modes_of_Introduction, Relationships, Relevant_Properties
2014-07-30 CWE Content Team MITRE
updated Relationships
2013-02-21 CWE Content Team MITRE
updated Relationships
2012-05-11 CWE Content Team MITRE
updated Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2009-10-29 CWE Content Team MITRE
updated Other_Notes, Theoretical_Notes
2008-09-08 CWE Content Team MITRE
updated Description, Relationships, Other_Notes
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction

CWE-454: External Initialization of Trusted Variables or Data Stores

Weakness ID: 454
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product initializes critical internal variables or data stores using inputs that can be modified by untrusted actors.
+ Extended Description
A product system should be reluctant to trust variables that have been initialized outside of its trust boundary, especially if they are initialized by users. The variables may have been initialized incorrectly. If an attacker can initialize the variable, then they can influence what the vulnerable system will do.
+ Common Consequences
Section HelpThis 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.
Impact Details

Modify Application Data

Scope: Integrity

An attacker could gain access to and modify sensitive data or system information.
+ Potential Mitigations
Phase(s) Mitigation

Implementation

Strategy: Input Validation

A product system should be reluctant to trust variables that have been initialized outside of its trust boundary. Ensure adequate checking (e.g. input validation) is performed when relying on input from outside a trust boundary.

Architecture and Design

Avoid any external control of variables. If necessary, restrict the variables that can be modified using an allowlist, and use a different namespace or naming convention if possible.
+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. 1419 Incorrect Initialization of Resource
CanAlsoBe Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 456 Missing Initialization of a Variable
+ Relevant to the view "Software Development" (View-699)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 452 Initialization and Cleanup Errors
+ Modes Of Introduction
Section HelpThe 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
Section HelpThis 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

PHP (Sometimes Prevalent)

Class: Not Language-Specific (Undetermined Prevalence)

+ Demonstrative Examples

Example 1


In the Java example below, a system property controls the debug level of the application.

(bad code)
Example Language: Java 
int debugLevel = Integer.getInteger("com.domain.application.debugLevel").intValue();

If an attacker is able to modify the system property, then it may be possible to coax the application into divulging sensitive information by virtue of the fact that additional debug information is printed/exposed as the debug level increases.



Example 2


This code checks the HTTP POST request for a debug switch, and enables a debug mode if the switch is set.

(bad code)
Example Language: PHP 
$debugEnabled = false;
if ($_POST["debug"] == "true"){
$debugEnabled = true;
}
/.../

function login($username, $password){
if($debugEnabled){
echo 'Debug Activated';
phpinfo();
$isAdmin = True;
return True;
}
}

Any user can activate the debug mode, gaining administrator privileges. An attacker may also use the information printed by the phpinfo() function to further exploit the system. .

This example also exhibits Information Exposure Through Debug Information (CWE-215)



+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
WordPress module sets internal variables based on external inputs, allowing false reporting of the number of views
Does not clear dangerous environment variables, enabling symlink attack.
Specify alternate configuration directory in environment variable, enabling untrusted path.
Dangerous environment variable not cleansed.
Specify arbitrary modules using environment variable.
+ Memberships
Section HelpThis 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 808 2010 Top 25 - Weaknesses On the Cusp
MemberOf ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 884 CWE Cross-section
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 994 SFP Secondary Cluster: Tainted Input to Variable
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1416 Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

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

Comments

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

Relationship

Overlaps Missing variable initialization, especially in PHP.

Applicable Platform

This is often found in PHP due to register_globals and the common practice of storing library/include files under the web document root so that they are available using a direct request.

+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER External initialization of trusted variables or values
Software Fault Patterns SFP25 Tainted input to variable
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification Date Modifier Organization
2023-10-26 CWE Content Team MITRE
updated Observed_Examples, Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Relationships
2023-01-31 CWE Content Team MITRE
updated Description, Potential_Mitigations
2020-06-25 CWE Content Team MITRE
updated Potential_Mitigations
2017-11-08 CWE Content Team MITRE
updated Description
2014-07-30 CWE Content Team MITRE
updated Relationships, Taxonomy_Mappings
2012-10-30 CWE Content Team MITRE
updated Potential_Mitigations
2012-05-11 CWE Content Team MITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-01 CWE Content Team MITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-03-29 CWE Content Team MITRE
updated Demonstrative_Examples
2010-04-05 CWE Content Team MITRE
updated Applicable_Platforms, Demonstrative_Examples
2010-02-16 CWE Content Team MITRE
updated Description, Name, Relationships
2009-10-29 CWE Content Team MITRE
updated Other_Notes, Relationship_Notes
2008-09-08 CWE Content Team MITRE
updated Applicable_Platforms, Description, Relationships, Other_Notes, Taxonomy_Mappings
2008-07-01 Eric Dalci Cigital
updated Potential_Mitigations, Time_of_Introduction
2008-07-01 Sean Eidemiller Cigital
added/updated demonstrative examples
+ Previous Entry Names
Change Date Previous Entry Name
2008-04-11 External Initialization of Trusted Variables or Values
2010-02-16 External Initialization of Trusted Variables

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

Weakness ID: 610
Vulnerability Mapping: DISCOURAGED This CWE ID should not be used to map to real-world vulnerabilities
Abstraction: Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product uses an externally controlled name or reference that resolves to a resource that is outside of the intended control sphere.
+ Common Consequences
Section HelpThis 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.
Impact Details

Read Application Data; Modify Application Data

Scope: Confidentiality, Integrity

An adversary could read or modify data, depending on how the resource is intended to be used.

Gain Privileges or Assume Identity

Scope: Access Control

Likelihood: High

An adversary that can supply a reference to an unintended resource can potentially access a resource that they do not have privileges for, thus bypassing existing access control mechanisms.
+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Pillar Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things. 664 Improper Control of a Resource Through its Lifetime
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 15 External Control of System or Configuration Setting
ParentOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 73 External Control of File Name or Path
ParentOf Composite 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 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 Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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" (View-1003)
Nature Type ID Name
MemberOf View View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). 1003 Weaknesses for Simplified Mapping of Published Vulnerabilities
ParentOf Composite 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 Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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" (View-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1015 Limit Access
+ Modes Of Introduction
Section HelpThe 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 COMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
+ Demonstrative Examples

Example 1


The following code is a Java servlet that will receive a GET request with a url parameter in the request to redirect the browser to the address specified in the url parameter. The servlet will retrieve the url parameter value from the request and send a response to redirect the browser to the url address.

(bad code)
Example Language: Java 
public class RedirectServlet extends HttpServlet {
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
String query = request.getQueryString();
if (query.contains("url")) {
String url = request.getParameter("url");
response.sendRedirect(url);
}
}
}

The problem with this Java servlet code is that an attacker could use the RedirectServlet as part of an e-mail phishing scam to redirect users to a malicious site. An attacker could send an HTML formatted e-mail directing the user to log into their account by including in the e-mail the following link:

(attack code)
Example Language: HTML 
<a href="http://bank.example.com/redirect?url=http://attacker.example.net">Click here to log in</a>

The user may assume that the link is safe since the URL starts with their trusted bank, bank.example.com. However, the user will then be redirected to the attacker's web site (attacker.example.net) which the attacker may have made to appear very similar to bank.example.com. The user may then unwittingly enter credentials into the attacker's web page and compromise their bank account. A Java servlet should never redirect a user to a URL without verifying that the redirect address is a trusted site.



+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
An email client does not block loading of remote objects in a nested document.
Chain: a learning management tool debugger uses external input to locate previous session logs (CWE-73) and does not properly validate the given path (CWE-20), allowing for filesystem path traversal using "../" sequences (CWE-24)
Cryptography API uses unsafe reflection when deserializing a private key
Chain: Go-based Oauth2 reverse proxy can send the authenticated user to another site at the end of the authentication flow. A redirect URL with HTML-encoded whitespace characters can bypass the validation (CWE-1289) to redirect to a malicious site (CWE-601)
Recruiter software allows reading arbitrary files using XXE
Database system allows attackers to bypass sandbox restrictions by using the Reflection API.
+ Memberships
Section HelpThis 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 CategoryCategory - 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 CategoryCategory - 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1368 ICS Dependencies (& Architecture): External Digital Systems
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1416 Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes
Usage DISCOURAGED
(this CWE ID should not be used to map to real-world vulnerabilities)
Reason Abstraction

Rationale

This CWE entry is a level-1 Class (i.e., a child of a Pillar). It might have lower-level children that would be more appropriate

Comments

Examine children of this entry to see if there is a better fit
+ 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.
+ Content History
+ Submissions
Submission Date Submitter Organization
2007-05-07
(CWE Draft 6, 2007-05-07)
Anonymous Tool Vendor (under NDA)
+ Modifications
Modification Date Modifier Organization
2025-04-03
(CWE 4.17, 2025-04-03)
CWE Content Team MITRE
updated Common_Consequences
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Demonstrative_Examples, Mapping_Notes
2023-10-26 CWE Content Team MITRE
updated Observed_Examples
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Relationships
2022-04-28 CWE Content Team MITRE
updated Relationships
2021-10-28 CWE Content Team MITRE
updated Relationships
2020-02-24 CWE Content Team MITRE
updated Relationships
2019-06-20 CWE Content Team MITRE
updated Relationships
2017-11-08 CWE Content Team MITRE
updated Modes_of_Introduction, Relationships, Taxonomy_Mappings
2017-01-19 CWE Content Team MITRE
updated Relationships
2015-12-07 CWE Content Team MITRE
updated Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships
2013-02-21 CWE Content Team MITRE
updated Maintenance_Notes
2012-05-11 CWE Content Team MITRE
updated Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2010-04-05 CWE Content Team MITRE
updated Related_Attack_Patterns
2009-10-29 CWE Content Team MITRE
updated Other_Notes, Relationship_Notes
2008-09-08 CWE Content Team MITRE
updated Relationships, Other_Notes, Taxonomy_Mappings
+ Previous Entry Names
Change Date Previous Entry Name
2008-04-11 Externally Controlled Reference to an Internal Resource

CWE-211: Externally-Generated Error Message Containing Sensitive Information

Weakness ID: 211
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The product performs an operation that triggers an external diagnostic or error message that is not directly generated or controlled by the product, such as an error generated by the programming language interpreter that a software application uses. The error can contain sensitive system information.
+ Common Consequences
Section HelpThis 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.
Impact Details

Read Application Data

Scope: Confidentiality

+ Potential Mitigations
Phase(s) Mitigation

System Configuration

Configure the application's environment in a way that prevents errors from being generated. For example, in PHP, disable display_errors.

Implementation; Build and Compilation

Strategy: Compilation or Build Hardening

Debugging information should not make its way into a production release.

Implementation; Build and Compilation

Strategy: Environment Hardening

Debugging information should not make its way into a production release.

Implementation

Handle exceptions internally and do not display errors containing potentially sensitive information to a user. Create default error pages if necessary.

Implementation

The best way to prevent this weakness during implementation is to avoid any bugs that could trigger the external error message. This typically happens when the program encounters fatal errors, such as a divide-by-zero. You will not always be able to control the use of error pages, and you might not be using a language that handles exceptions.
+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 209 Generation of Error Message Containing Sensitive Information
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 535 Exposure of Information Through Shell Error Message
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 536 Servlet Runtime Error Message Containing Sensitive Information
ParentOf Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource. 537 Java Runtime Error Message Containing Sensitive Information
+ Relevant to the view "Architectural Concepts" (View-1008)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1016 Limit Exposure
+ Modes Of Introduction
Section HelpThe 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 PHP applications are often targeted for having this issue when the PHP interpreter generates the error outside of the application's control. However, other languages/environments exhibit the same issue.
Implementation REALIZATION: This weakness is caused during implementation of an architectural security tactic.
Operation
+ Applicable Platforms
Section HelpThis 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

PHP (Often Prevalent)

Class: Not Language-Specific (Undetermined Prevalence)

+ Demonstrative Examples

Example 1


The following servlet code does not catch runtime exceptions, meaning that if such an exception were to occur, the container may display potentially dangerous information (such as a full stack trace).

(bad code)
Example Language: Java 
public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
String username = request.getParameter("username");

// May cause unchecked NullPointerException.
if (username.length() < 10) {
...
}
}


Example 2


In the following Java example the class InputFileRead enables an input file to be read using a FileReader object. In the constructor of this class a default input file path is set to some directory on the local file system and the method setInputFile must be called to set the name of the input file to be read in the default directory. The method readInputFile will create the FileReader object and will read the contents of the file. If the method setInputFile is not called prior to calling the method readInputFile then the File object will remain null when initializing the FileReader object. A Java RuntimeException will be raised, and an error message will be output to the user.

(bad code)
Example Language: Java 
public class InputFileRead {
private File readFile = null;
private FileReader reader = null;
private String inputFilePath = null;
private final String DEFAULT_FILE_PATH = "c:\\somedirectory\\";

public InputFileRead() {
inputFilePath = DEFAULT_FILE_PATH;
}

public void setInputFile(String inputFile) {

/* Assume appropriate validation / encoding is used and privileges / permissions are preserved */
}

public void readInputFile() {
try {
reader = new FileReader(readFile);
...
} catch (RuntimeException rex) {
System.err.println("Error: Cannot open input file in the directory " + inputFilePath);
System.err.println("Input file has not been set, call setInputFile method before calling readInputFile");


} catch (FileNotFoundException ex) {...}
}
}

However, the error message output to the user contains information regarding the default directory on the local file system. This information can be exploited and may lead to unauthorized access or use of the system. Any Java RuntimeExceptions that are handled should not expose sensitive information to the user.



+ Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference Description
chain: product does not protect against direct request of an include file, leading to resultant path disclosure when the include file does not successfully execute.
Single "'" inserted into SQL query leads to invalid SQL query execution, triggering full path disclosure. Possibly resultant from more general SQL injection issue.
chain: product does not protect against direct request of a library file, leading to resultant path disclosure when the file does not successfully execute.
invalid parameter triggers a failure to find an include file, leading to infoleak in error message.
Various invalid requests lead to information leak in verbose error messages describing the failure to instantiate a class, open a configuration file, or execute an undefined function.
Improper handling of filename request with trailing "/" causes multiple consequences, including information leak in Visual Basic error message.
+ Weakness Ordinalities
Ordinality Description
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
+ Functional Areas
  • Error Handling
+ Memberships
Section HelpThis 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 CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 963 SFP Secondary Cluster: Exposed Data
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1417 Comprehensive Categorization: Sensitive Information Exposure
+ Vulnerability Mapping Notes
Usage ALLOWED
(this CWE ID may be used to map to real-world vulnerabilities)
Reason Acceptable-Use

Rationale

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

Comments

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

Relationship

This is inherently a resultant vulnerability from a weakness within the product or an interaction error.
+ Taxonomy Mappings
Mapped Taxonomy Name Node ID Fit Mapped Node Name
PLOVER Product-External Error Message Infoleak
+ Content History
+ Submissions
Submission Date Submitter Organization
2006-07-19
(CWE Draft 3, 2006-07-19)
PLOVER
+ Modifications
Modification Date Modifier Organization
2024-02-29
(CWE 4.14, 2024-02-29)
CWE Content Team MITRE
updated Demonstrative_Examples
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2023-04-27 CWE Content Team MITRE
updated Relationships
2023-01-31 CWE Content Team MITRE
updated Description
2020-02-24 CWE Content Team MITRE
updated Description, Name, Relationships
2017-11-08 CWE Content Team MITRE
updated Applicable_Platforms, Enabling_Factors_for_Exploitation, Modes_of_Introduction, Relationships
2014-07-30 CWE Content Team MITRE
updated Relationships
2012-10-30 CWE Content Team MITRE
updated Name
2012-05-11 CWE Content Team MITRE
updated Relationships
2011-06-01 CWE Content Team MITRE
updated Common_Consequences
2011-03-29 CWE Content Team MITRE
updated Name
2010-12-13 CWE Content Team MITRE
updated Observed_Examples
2010-06-21 CWE Content Team MITRE
updated Potential_Mitigations
2008-11-24 CWE Content Team MITRE
updated Description, Enabling_Factors_for_Exploitation, Functional_Areas, Observed_Examples, Other_Notes, Potential_Mitigations, Relationship_Notes, Weakness_Ordinalities
2008-10-14 CWE Content Team MITRE
updated Description
2008-09-08 CWE Content Team MITRE
updated Applicable_Platforms, Relationships, Other_Notes, Taxonomy_Mappings
2008-07-01 Eric Dalci Cigital
updated Time_of_Introduction
+ Previous Entry Names
Change Date Previous Entry Name
2011-03-29 Product-External Error Message Information Leak
2012-10-30 Information Exposure Through External Error Message
2020-02-24 Information Exposure Through Externally-Generated Error Message

CWE-1316: Fabric-Address Map Allows Programming of Unwarranted Overlaps of Protected and Unprotected Ranges

Weakness ID: 1316
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ Description
The address map of the on-chip fabric has protected and unprotected regions overlapping, allowing an attacker to bypass access control to the overlapping portion of the protected region.
+ Extended Description

Various ranges can be defined in the system-address map, either in the memory or in Memory-Mapped-IO (MMIO) space. These ranges are usually defined using special range registers that contain information, such as base address and size. Address decoding is the process of determining for which range the incoming transaction is destined. To ensure isolation, ranges containing secret data are access-control protected.

Occasionally, these ranges could overlap. The overlap could either be intentional (e.g. due to a limited number of range registers or limited choice in choosing size of the range) or unintentional (e.g. introduced by errors). Some hardware designs allow dynamic remapping of address ranges assigned to peripheral MMIO ranges. In such designs, intentional address overlaps can be created through misconfiguration by malicious software. When protected and unprotected ranges overlap, an attacker could send a transaction and potentially compromise the protections in place, violating the principle of least privilege.

+ Common Consequences
Section HelpThis 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.
Impact Details

Bypass Protection Mechanism; Read Memory; Modify Memory

Scope: Confidentiality, Integrity, Access Control, Authorization

Likelihood: Medium

+ Potential Mitigations
Phase(s) Mitigation

Architecture and Design

When architecting the address map of the chip, ensure that protected and unprotected ranges are isolated and do not overlap. When designing, ensure that ranges hardcoded in Register-Transfer Level (RTL) do not overlap.

Implementation

Ranges configured by firmware should not overlap. If overlaps are mandatory because of constraints such as a limited number of registers, then ensure that no assets are present in the overlapped portion.

Testing

Validate mitigation actions with robust testing.
+ Relationships
Section Help 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" (View-1000)
Nature Type ID Name
ChildOf Pillar Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things. 284 Improper Access Control
+ Relevant to the view "Hardware Design" (View-1194)
Nature Type ID Name
MemberOf Category Category - a CWE entry that contains a set of other entries that share a common characteristic. 1203 Peripherals, On-chip Fabric, and Interface/IO Problems
+ Modes Of Introduction
Section HelpThe 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
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
Languages

Class: Not Language-Specific (Undetermined Prevalence)

Operating Systems

Class: Not OS-Specific