CWE

Common Weakness Enumeration

A Community-Developed List of Software Weakness Types

CWE/SANS Top 25 Most Dangerous Software Errors
Home > CWE List > VIEW SLICE: CWE-1003: Weaknesses for Simplified Mapping of Published Vulnerabilities (2.11)  
ID

CWE VIEW: Weaknesses for Simplified Mapping of Published Vulnerabilities

View ID: 1003
Structure: Graph
Status: Incomplete
Presentation Filter:
+ View Data

View Objective

CWE entries in this view (graph) may be used to categorize potential weaknesses within sources that handle public, third-party vulnerability information, such as NVD. By design, this view is incomplete; it is limited to a small number of the most commonly-seen weaknesses, so that it is easier to use for humans.

This view is most similar to CWE-699 (Development Concepts), although it also has some relationships that are similar to those for CWE-1000 (Research Concepts).

Note: this view is likely to change significantly in the next version.

+ Relationships
Show Details:
1003 - Weaknesses for Simplified Mapping of Published Vulnerabilities
+CategoryCategoryCode - (17)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code)
Weaknesses in this category are typically introduced during code development, including specification, design, and implementation.
+CategoryCategorySource Code - (18)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code)
Weaknesses in this category are typically found within source code.
+CategoryCategoryChannel and Path Errors - (417)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 417 (Channel and Path Errors)
Weaknesses in this category are related to improper handling of communication channels and access paths.
*Weakness BaseWeakness BaseUncontrolled Search Path Element - (427)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 417 (Channel and Path Errors) > 427 (Uncontrolled Search Path Element)
The product uses a fixed or controlled search path to find resources, but one or more locations in that path can be under the control of unintended actors.DLL preloadingBinary plantingInsecure library loading
*Weakness BaseWeakness BaseUnquoted Search Path or Element - (428)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 417 (Channel and Path Errors) > 428 (Unquoted Search Path or Element)
The product uses a search path that contains an unquoted element, in which the element contains whitespace or other separators. This can cause the product to access resources in a parent path.
+Compound Element: CompositeCompound Element: CompositeUntrusted Search Path - (426)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 417 (Channel and Path Errors) > 426 (Untrusted Search Path)
The application searches for critical resources using an externally-supplied search path that can point to resources that are not under the application's direct control.Untrusted Path
*Weakness ClassWeakness ClassContainment Errors (Container Errors) - (216)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 417 (Channel and Path Errors) > 426 (Untrusted Search Path) > 216 (Containment Errors (Container Errors))
This tries to cover various problems in which improper data are included within a "container."
*Weakness BaseWeakness BaseModification of Assumed-Immutable Data (MAID) - (471)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 417 (Channel and Path Errors) > 426 (Untrusted Search Path) > 471 (Modification of Assumed-Immutable Data (MAID))
The software does not properly protect an assumed-immutable element from being modified by an attacker.
*CategoryCategoryPermission Issues - (275)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 417 (Channel and Path Errors) > 426 (Untrusted Search Path) > 275 (Permission Issues)
Weaknesses in this category are related to improper assignment or handling of permissions.
+CategoryCategoryData Processing Errors - (19)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 19 (Data Processing Errors)
Weaknesses in this category are typically found in functionality that processes data.
+Weakness ClassWeakness ClassIncorrect Access of Indexable Resource ('Range Error') - (118)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 19 (Data Processing Errors) > 118 (Incorrect Access of Indexable Resource ('Range Error'))
The software does not restrict or incorrectly restricts operations within the boundaries of a resource that is accessed using an index or pointer, such as memory or files.
+Weakness ClassWeakness ClassImproper Restriction of Operations within the Bounds of a Memory Buffer - (119)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 19 (Data Processing Errors) > 118 (Incorrect Access of Indexable Resource ('Range Error')) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer)
The software performs operations on a memory buffer, but it can read from or write to a memory location that is outside of the intended boundary of the buffer.Memory Corruption
*Weakness BaseWeakness BaseAccess of Uninitialized Pointer - (824)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 19 (Data Processing Errors) > 118 (Incorrect Access of Indexable Resource ('Range Error')) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) > 824 (Access of Uninitialized Pointer)
The program accesses or uses a pointer that has not been initialized.
*Weakness BaseWeakness BaseOut-of-bounds Read - (125)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 19 (Data Processing Errors) > 118 (Incorrect Access of Indexable Resource ('Range Error')) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) > 125 (Out-of-bounds Read)
The software reads data past the end, or before the beginning, of the intended buffer.
*Weakness BaseWeakness BaseOut-of-bounds Write - (787)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 19 (Data Processing Errors) > 118 (Incorrect Access of Indexable Resource ('Range Error')) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) > 787 (Out-of-bounds Write)
The software writes data past the end, or before the beginning, of the intended buffer.
*Weakness BaseWeakness BaseWrite-what-where Condition - (123)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 19 (Data Processing Errors) > 118 (Incorrect Access of Indexable Resource ('Range Error')) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) > 123 (Write-what-where Condition)
Any condition where the attacker has the ability to write an arbitrary value to an arbitrary location, often as the result of a buffer overflow.
*Weakness ClassWeakness ClassIncorrect Regular Expression - (185)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 19 (Data Processing Errors) > 185 (Incorrect Regular Expression)
The software specifies a regular expression in a way that causes data to be improperly matched or compared.
+CategoryCategoryNumeric Errors - (189)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 19 (Data Processing Errors) > 189 (Numeric Errors)
Weaknesses in this category are related to improper calculation or conversion of numbers.
+Weakness ClassWeakness ClassIncorrect Calculation - (682)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 19 (Data Processing Errors) > 189 (Numeric Errors) > 682 (Incorrect Calculation)
The software performs a calculation that generates incorrect or unintended results that are later used in security-critical decisions or resource management.
*Weakness BaseWeakness BaseDivide By Zero - (369)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 19 (Data Processing Errors) > 189 (Numeric Errors) > 682 (Incorrect Calculation) > 369 (Divide By Zero)
The product divides a value by zero.
*Weakness BaseWeakness BaseInteger Overflow or Wraparound - (190)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 19 (Data Processing Errors) > 189 (Numeric Errors) > 682 (Incorrect Calculation) > 190 (Integer Overflow or Wraparound)
The software performs a calculation that can produce an integer overflow or wraparound, when the logic assumes that the resulting value will always be larger than the original value. This can introduce other weaknesses when the calculation is used for resource management or execution control.
*Weakness BaseWeakness BaseInteger Underflow (Wrap or Wraparound) - (191)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 19 (Data Processing Errors) > 189 (Numeric Errors) > 682 (Incorrect Calculation) > 191 (Integer Underflow (Wrap or Wraparound))
The product subtracts one value from another, such that the result is less than the minimum allowable integer value, which produces a value that is not equal to the correct result.Integer underflow
+CategoryCategoryRepresentation Errors - (137)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 19 (Data Processing Errors) > 137 (Representation Errors)
Weaknesses in this category are introduced when inserting or converting data from one representation into another.
+CategoryCategoryCleansing, Canonicalization, and Comparison Errors - (171)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 19 (Data Processing Errors) > 137 (Representation Errors) > 171 (Cleansing, Canonicalization, and Comparison Errors)
Weaknesses in this category are related to improper handling of data within protection mechanisms that attempt to perform neutralization for untrusted data.
+Weakness ClassWeakness ClassImproper Enforcement of Message or Data Structure - (707)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 19 (Data Processing Errors) > 137 (Representation Errors) > 171 (Cleansing, Canonicalization, and Comparison Errors) > 707 (Improper Enforcement of Message or Data Structure)
The software does not enforce or incorrectly enforces that structured messages or data are well-formed before being read from an upstream component or sent to a downstream component.
*Weakness ClassWeakness ClassEncoding Error - (172)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 19 (Data Processing Errors) > 137 (Representation Errors) > 171 (Cleansing, Canonicalization, and Comparison Errors) > 707 (Improper Enforcement of Message or Data Structure) > 172 (Encoding Error)
The software does not properly encode or decode the data, resulting in unexpected values.
*Weakness ClassWeakness ClassImproper Encoding or Escaping of Output - (116)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 19 (Data Processing Errors) > 137 (Representation Errors) > 171 (Cleansing, Canonicalization, and Comparison Errors) > 707 (Improper Enforcement of Message or Data Structure) > 116 (Improper Encoding or Escaping of Output)
The software prepares a structured message for communication with another component, but encoding or escaping of the data is either missing or done incorrectly. As a result, the intended structure of the message is not preserved.Output SanitizationOutput ValidationOutput Encoding
+CategoryCategoryError Handling - (388)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 388 (Error Handling)
This category includes weaknesses that occur when an application does not properly handle errors that occur during processing.
*Weakness ClassWeakness ClassImproper Check for Unusual or Exceptional Conditions - (754)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 388 (Error Handling) > 754 (Improper Check for Unusual or Exceptional Conditions)
The software does not check or improperly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the software.
+Weakness ClassWeakness ClassIndicator of Poor Code Quality - (398)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 398 (Indicator of Poor Code Quality)
The code has features that do not directly introduce a weakness or vulnerability, but indicate that the product has not been carefully developed or maintained.
*Weakness BaseWeakness BaseNULL Pointer Dereference - (476)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 398 (Indicator of Poor Code Quality) > 476 (NULL Pointer Dereference)
A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit.
+CategoryCategoryResource Management Errors - (399)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 398 (Indicator of Poor Code Quality) > 399 (Resource Management Errors)
Weaknesses in this category are related to improper management of system resources.
+Weakness ClassWeakness ClassAsymmetric Resource Consumption (Amplification) - (405)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 398 (Indicator of Poor Code Quality) > 399 (Resource Management Errors) > 405 (Asymmetric Resource Consumption (Amplification))
Software that does not appropriately monitor or control resource consumption can lead to adverse system performance.
*Weakness BaseWeakness BaseAlgorithmic Complexity - (407)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 398 (Indicator of Poor Code Quality) > 399 (Resource Management Errors) > 405 (Asymmetric Resource Consumption (Amplification)) > 407 (Algorithmic Complexity)
An algorithm in a product has an inefficient worst-case computational complexity that may be detrimental to system performance and can be triggered by an attacker, typically using crafted manipulations that ensure that the worst case is being reached.
*Weakness VariantWeakness VariantDouble Free - (415)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 398 (Indicator of Poor Code Quality) > 399 (Resource Management Errors) > 415 (Double Free)
The product calls free() twice on the same memory address, potentially leading to modification of unexpected memory locations.Double-free
*Weakness BaseWeakness BaseImproper Resource Shutdown or Release - (404)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 398 (Indicator of Poor Code Quality) > 399 (Resource Management Errors) > 404 (Improper Resource Shutdown or Release)
The program does not release or incorrectly releases a resource before it is made available for re-use.
+Weakness BaseWeakness BaseUncontrolled Resource Consumption ('Resource Exhaustion') - (400)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 398 (Indicator of Poor Code Quality) > 399 (Resource Management Errors) > 400 (Uncontrolled Resource Consumption ('Resource Exhaustion'))
The software does not properly restrict the size or amount of resources that are requested or influenced by an actor, which can be used to consume more resources than intended.
+CategoryCategoryFile Descriptor Exhaustion - (769)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 398 (Indicator of Poor Code Quality) > 399 (Resource Management Errors) > 400 (Uncontrolled Resource Consumption ('Resource Exhaustion')) > 769 (File Descriptor Exhaustion)
The software can be influenced by an attacker to open more files than are supported by the system.
*Weakness VariantWeakness VariantAllocation of File Descriptors or Handles Without Limits or Throttling - (774)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 398 (Indicator of Poor Code Quality) > 399 (Resource Management Errors) > 400 (Uncontrolled Resource Consumption ('Resource Exhaustion')) > 769 (File Descriptor Exhaustion) > 774 (Allocation of File Descriptors or Handles Without Limits or Throttling)
The software allocates file descriptors or handles on behalf of an actor without imposing any restrictions on how many descriptors can be allocated, in violation of the intended security policy for that actor.
*Weakness VariantWeakness VariantMissing Release of File Descriptor or Handle after Effective Lifetime - (775)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 398 (Indicator of Poor Code Quality) > 399 (Resource Management Errors) > 400 (Uncontrolled Resource Consumption ('Resource Exhaustion')) > 769 (File Descriptor Exhaustion) > 775 (Missing Release of File Descriptor or Handle after Effective Lifetime)
The software does not release a file descriptor or handle after its effective lifetime has ended, i.e., after the file descriptor/handle is no longer needed.
*Weakness BaseWeakness BaseUse After Free - (416)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 398 (Indicator of Poor Code Quality) > 399 (Resource Management Errors) > 416 (Use After Free)
Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code.Dangling pointerUse-After-Free
+Weakness ClassWeakness ClassInsufficient Encapsulation - (485)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 485 (Insufficient Encapsulation)
The product does not sufficiently encapsulate critical data or functionality.
*Weakness BaseWeakness BaseExposed Dangerous Method or Function - (749)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 485 (Insufficient Encapsulation) > 749 (Exposed Dangerous Method or Function)
The software 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.
+CategoryCategorySecurity Features - (254)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features)
Software security is not security software. Here we're concerned with topics like authentication, access control, confidentiality, cryptography, and privilege management.
+CategoryCategoryCredentials Management - (255)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 255 (Credentials Management)
Weaknesses in this category are related to the management of credentials.
*Weakness BaseWeakness BaseUse of Hard-coded Credentials - (798)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 255 (Credentials Management) > 798 (Use of Hard-coded Credentials)
The software contains hard-coded credentials, such as a password or cryptographic key, which it uses for its own inbound authentication, outbound communication to external components, or encryption of internal data.
*Weakness BaseWeakness BaseWeak Password Recovery Mechanism for Forgotten Password - (640)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 255 (Credentials Management) > 640 (Weak Password Recovery Mechanism for Forgotten Password)
The software contains a mechanism for users to recover or change their passwords without knowing the original password, but the mechanism is weak.
+CategoryCategoryCryptographic Issues - (310)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 310 (Cryptographic Issues)
Weaknesses in this category are related to the use of cryptography.
*Weakness ClassWeakness ClassInadequate Encryption Strength - (326)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 310 (Cryptographic Issues) > 326 (Inadequate Encryption Strength)
The software stores or transmits sensitive data using an encryption scheme that is theoretically sound, but is not strong enough for the level of protection required.
*CategoryCategoryKey Management Errors - (320)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 310 (Cryptographic Issues) > 320 (Key Management Errors)
Weaknesses in this category are related to errors in the management of cryptographic keys.
*Weakness BaseWeakness BaseUse of a Broken or Risky Cryptographic Algorithm - (327)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 310 (Cryptographic Issues) > 327 (Use of a Broken or Risky Cryptographic Algorithm)
The use of a broken or risky cryptographic algorithm is an unnecessary risk that may result in the exposure of sensitive information.
+Weakness BaseWeakness BaseImproper Certificate Validation - (295)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 295 (Improper Certificate Validation)
The software does not validate, or incorrectly validates, a certificate.
*Weakness VariantWeakness VariantImproper Validation of Certificate with Host Mismatch - (297)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 295 (Improper Certificate Validation) > 297 (Improper Validation of Certificate with Host Mismatch)
The software communicates with a host that provides a certificate, but the software does not properly ensure that the certificate is actually associated with that host.
*Weakness BaseWeakness BaseImproperly Implemented Security Check for Standard - (358)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 358 (Improperly Implemented Security Check for Standard)
The software does not implement or incorrectly implements one or more security-relevant checks as specified by the design of a standardized algorithm, protocol, or technique.
+Weakness ClassWeakness ClassInsufficient Verification of Data Authenticity - (345)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 345 (Insufficient Verification of Data Authenticity)
The software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.
+Compound Element: CompositeCompound Element: CompositeCross-Site Request Forgery (CSRF) - (352)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 345 (Insufficient Verification of Data Authenticity) > 352 (Cross-Site Request Forgery (CSRF))
The web application does not, or can not, sufficiently verify whether a well-formed, valid, consistent request was intentionally provided by the user who submitted the request.Session RidingCross Site Reference ForgeryXSRF
*Weakness ClassWeakness ClassExternal Control of Critical State Data - (642)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 345 (Insufficient Verification of Data Authenticity) > 352 (Cross-Site Request Forgery (CSRF)) > 642 (External Control of Critical State Data)
The software stores security-critical state information about its users, or the software itself, in a location that is accessible to unauthorized actors.
*Weakness BaseWeakness BaseInsufficient Session Expiration - (613)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 345 (Insufficient Verification of Data Authenticity) > 352 (Cross-Site Request Forgery (CSRF)) > 613 (Insufficient Session Expiration)
According to WASC, "Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization."
*Weakness BaseWeakness BaseOrigin Validation Error - (346)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 345 (Insufficient Verification of Data Authenticity) > 352 (Cross-Site Request Forgery (CSRF)) > 346 (Origin Validation Error)
The software does not properly verify that the source of data or communication is valid.
*Weakness ClassWeakness ClassUnintended Proxy or Intermediary ('Confused Deputy') - (441)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 345 (Insufficient Verification of Data Authenticity) > 352 (Cross-Site Request Forgery (CSRF)) > 441 (Unintended Proxy or Intermediary ('Confused Deputy'))
The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor.Confused Deputy
*Weakness BaseWeakness BaseImproper Verification of Cryptographic Signature - (347)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 345 (Insufficient Verification of Data Authenticity) > 347 (Improper Verification of Cryptographic Signature)
The software does not verify, or incorrectly verifies, the cryptographic signature for data.
+CategoryCategoryPermissions, Privileges, and Access Controls - (264)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 264 (Permissions, Privileges, and Access Controls)
Weaknesses in this category are related to the management of permissions, privileges, and other security features that are used to perform access control.
+Weakness ClassWeakness ClassImproper Access Control - (284)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 264 (Permissions, Privileges, and Access Controls) > 284 (Improper Access Control)
The software does not restrict or incorrectly restricts access to a resource from an unauthorized actor.Authorization
+Weakness ClassWeakness ClassImproper Authentication - (287)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 264 (Permissions, Privileges, and Access Controls) > 284 (Improper Access Control) > 287 (Improper Authentication)
When an actor claims to have a given identity, the software does not prove or insufficiently proves that the claim is correct.authentificationAuthC
*Weakness VariantWeakness VariantMissing Authentication for Critical Function - (306)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 264 (Permissions, Privileges, and Access Controls) > 284 (Improper Access Control) > 287 (Improper Authentication) > 306 (Missing Authentication for Critical Function)
The software does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.
+Compound Element: CompositeCompound Element: CompositeSession Fixation - (384)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 264 (Permissions, Privileges, and Access Controls) > 284 (Improper Access Control) > 287 (Improper Authentication) > 384 (Session Fixation)
Authenticating a user, or otherwise establishing a new user session, without invalidating any existing session identifier gives an attacker the opportunity to steal authenticated sessions.
*Weakness BaseWeakness BaseExternal Control of Assumed-Immutable Web Parameter - (472)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 264 (Permissions, Privileges, and Access Controls) > 284 (Improper Access Control) > 287 (Improper Authentication) > 384 (Session Fixation) > 472 (External Control of Assumed-Immutable Web Parameter)
The web application does not sufficiently verify inputs that are assumed to be immutable but are actually externally controllable, such as hidden form fields.Assumed-Immutable Parameter Tampering
*Weakness BaseWeakness BaseOrigin Validation Error - (346)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 264 (Permissions, Privileges, and Access Controls) > 284 (Improper Access Control) > 287 (Improper Authentication) > 384 (Session Fixation) > 346 (Origin Validation Error)
The software does not properly verify that the source of data or communication is valid.
*Weakness ClassWeakness ClassUnintended Proxy or Intermediary ('Confused Deputy') - (441)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 264 (Permissions, Privileges, and Access Controls) > 284 (Improper Access Control) > 287 (Improper Authentication) > 384 (Session Fixation) > 441 (Unintended Proxy or Intermediary ('Confused Deputy'))
The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor.Confused Deputy
*Weakness ClassWeakness ClassImproper Authorization - (285)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 264 (Permissions, Privileges, and Access Controls) > 284 (Improper Access Control) > 285 (Improper Authorization)
The software does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action.AuthZ
+Weakness ClassWeakness ClassProtection Mechanism Failure - (693)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 693 (Protection Mechanism Failure)
The product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product.
+Weakness ClassWeakness ClassImproper Input Validation - (20)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 693 (Protection Mechanism Failure) > 20 (Improper Input Validation)
The product does not validate or incorrectly validates input that can affect the control flow or data flow of a program.
+Weakness ClassWeakness ClassImproper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') - (74)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 693 (Protection Mechanism Failure) > 20 (Improper Input Validation) > 74 (Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection'))
The software constructs all or part of a command, data structure, or record using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify how it is parsed or interpreted when it is sent to a downstream component.
*Weakness ClassWeakness ClassImproper Control of Generation of Code ('Code Injection') - (94)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 693 (Protection Mechanism Failure) > 20 (Improper Input Validation) > 74 (Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')) > 94 (Improper Control of Generation of Code ('Code Injection'))
The software constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment.
+Weakness BaseWeakness BaseImproper Control of Resource Identifiers ('Resource Injection') - (99)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 693 (Protection Mechanism Failure) > 20 (Improper Input Validation) > 74 (Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')) > 99 (Improper Control of Resource Identifiers ('Resource Injection'))
The software receives input from an upstream component, but it does not restrict or incorrectly restricts the input before it is used as an identifier for a resource that may be outside the intended sphere of control.Insecure Direct Object Reference
*Weakness BaseWeakness BaseUse of Multiple Resources with Duplicate Identifier - (694)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 693 (Protection Mechanism Failure) > 20 (Improper Input Validation) > 74 (Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')) > 99 (Improper Control of Resource Identifiers ('Resource Injection')) > 694 (Use of Multiple Resources with Duplicate Identifier)
The software uses multiple resources that can have the same identifier, in a context in which unique identifiers are required.
+Weakness BaseWeakness BaseImproper Neutralization of CRLF Sequences ('CRLF Injection') - (93)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 693 (Protection Mechanism Failure) > 20 (Improper Input Validation) > 74 (Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')) > 93 (Improper Neutralization of CRLF Sequences ('CRLF Injection'))
The software uses CRLF (carriage return line feeds) as a special element, e.g. to separate lines or records, but it does not neutralize or incorrectly neutralizes CRLF sequences from inputs.
*Weakness BaseWeakness BaseImproper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting') - (113)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 693 (Protection Mechanism Failure) > 20 (Improper Input Validation) > 74 (Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')) > 93 (Improper Neutralization of CRLF Sequences ('CRLF Injection')) > 113 (Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting'))
The software receives data from an upstream component, but does not neutralize or incorrectly neutralizes CR and LF characters before the data is included in outgoing HTTP headers.
*Weakness BaseWeakness BaseImproper Neutralization of Input During Web Page Generation ('Cross-site Scripting') - (79)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 693 (Protection Mechanism Failure) > 20 (Improper Input Validation) > 74 (Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')) > 79 (Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'))
The software does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.XSSCSS
+Weakness ClassWeakness ClassImproper Neutralization of Special Elements in Data Query Logic - (943)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 693 (Protection Mechanism Failure) > 20 (Improper Input Validation) > 74 (Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')) > 943 (Improper Neutralization of Special Elements in Data Query Logic)
The application generates a query intended to access or manipulate data in a data store such as a database, but it does not neutralize or incorrectly neutralizes special elements that can modify the intended logic of the query.
*Weakness BaseWeakness BaseImproper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection') - (90)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 693 (Protection Mechanism Failure) > 20 (Improper Input Validation) > 74 (Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')) > 943 (Improper Neutralization of Special Elements in Data Query Logic) > 90 (Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection'))
The software constructs all or part of an LDAP query using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended LDAP query when it is sent to a downstream component.
*Weakness BaseWeakness BaseImproper Neutralization of Special Elements used in an SQL Command ('SQL Injection') - (89)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 693 (Protection Mechanism Failure) > 20 (Improper Input Validation) > 74 (Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')) > 943 (Improper Neutralization of Special Elements in Data Query Logic) > 89 (Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'))
The software constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component.
+Weakness ClassWeakness ClassImproper Neutralization of Special Elements used in a Command ('Command Injection') - (77)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 693 (Protection Mechanism Failure) > 20 (Improper Input Validation) > 74 (Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')) > 77 (Improper Neutralization of Special Elements used in a Command ('Command Injection'))
The software constructs all or part of a command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended command when it is sent to a downstream component.
*Weakness BaseWeakness BaseArgument Injection or Modification - (88)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 693 (Protection Mechanism Failure) > 20 (Improper Input Validation) > 74 (Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')) > 77 (Improper Neutralization of Special Elements used in a Command ('Command Injection')) > 88 (Argument Injection or Modification)
The software does not sufficiently delimit the arguments being passed to a component in another control sphere, allowing alternate arguments to be provided, leading to potentially security-relevant changes.
*Weakness BaseWeakness BaseImproper Neutralization of Special Elements used in an OS Command ('OS Command Injection') - (78)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 693 (Protection Mechanism Failure) > 20 (Improper Input Validation) > 74 (Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')) > 77 (Improper Neutralization of Special Elements used in a Command ('Command Injection')) > 78 (Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'))
The software constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component.Shell injectionShell metacharacters
*Weakness BaseWeakness BaseUse of Externally-Controlled Format String - (134)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 693 (Protection Mechanism Failure) > 20 (Improper Input Validation) > 74 (Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')) > 134 (Use of Externally-Controlled Format String)
The software uses a function that accepts a format string as an argument, but the format string originates from an external source.
*Weakness BaseWeakness BaseXML Injection (aka Blind XPath Injection) - (91)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 693 (Protection Mechanism Failure) > 20 (Improper Input Validation) > 74 (Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')) > 91 (XML Injection (aka Blind XPath Injection))
The software does not properly neutralize special elements that are used in XML, allowing attackers to modify the syntax, content, or commands of the XML before it is processed by an end system.
*Weakness BaseWeakness BaseImproper Validation of Array Index - (129)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 693 (Protection Mechanism Failure) > 20 (Improper Input Validation) > 129 (Improper Validation of Array Index)
The product uses untrusted input when calculating or using an array index, but the product does not validate or incorrectly validates the index to ensure the index references a valid position within the array. out-of-bounds array indexindex-out-of-rangearray index underflow
+CategoryCategoryPathname Traversal and Equivalence Errors - (21)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 693 (Protection Mechanism Failure) > 20 (Improper Input Validation) > 21 (Pathname Traversal and Equivalence Errors)
Weaknesses in this category can be used to access files outside of a restricted directory (path traversal) or to perform operations on files that would otherwise be restricted (path equivalence).
*Weakness ClassWeakness ClassImproper Limitation of a Pathname to a Restricted Directory ('Path Traversal') - (22)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 693 (Protection Mechanism Failure) > 20 (Improper Input Validation) > 21 (Pathname Traversal and Equivalence Errors) > 22 (Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'))
The software uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the software does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.Directory traversalPath traversal
*Weakness BaseWeakness BaseImproper Link Resolution Before File Access ('Link Following') - (59)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 693 (Protection Mechanism Failure) > 20 (Improper Input Validation) > 21 (Pathname Traversal and Equivalence Errors) > 59 (Improper Link Resolution Before File Access ('Link Following'))
The software attempts to access a file based on the filename, but it does not properly prevent that filename from identifying a link or shortcut that resolves to an unintended resource.insecure temporary file
*Weakness VariantWeakness VariantURL Redirection to Untrusted Site ('Open Redirect') - (601)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 693 (Protection Mechanism Failure) > 20 (Improper Input Validation) > 601 (URL Redirection to Untrusted Site ('Open Redirect'))
A web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a Redirect. This simplifies phishing attacks.Open RedirectCross-site RedirectCross-domain Redirect
*Weakness BaseWeakness BaseIncomplete Blacklist - (184)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 693 (Protection Mechanism Failure) > 184 (Incomplete Blacklist)
An application uses a "blacklist" of prohibited values, but the blacklist is incomplete.
+Weakness ClassWeakness ClassUse of Insufficiently Random Values - (330)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 330 (Use of Insufficiently Random Values)
The software may use insufficiently random numbers or values in a security context that depends on unpredictable numbers.
+Weakness BaseWeakness BaseInsufficient Entropy - (331)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 330 (Use of Insufficiently Random Values) > 331 (Insufficient Entropy)
The software uses an algorithm or scheme that produces insufficient entropy, leaving patterns or clusters of values that are more likely to occur than others.
*Weakness VariantWeakness VariantInsufficient Entropy in PRNG - (332)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 330 (Use of Insufficiently Random Values) > 331 (Insufficient Entropy) > 332 (Insufficient Entropy in PRNG)
The lack of entropy available for, or used by, a Pseudo-Random Number Generator (PRNG) can be a stability and security threat.
*Weakness BaseWeakness BaseUse of Cryptographically Weak Pseudo-Random Number Generator (PRNG) - (338)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 254 (Security Features) > 330 (Use of Insufficiently Random Values) > 338 (Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG))
The product uses a Pseudo-Random Number Generator (PRNG) in a security context, but the PRNG is not cryptographically strong.
+CategoryCategoryTime and State - (361)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 361 (Time and State)
Weaknesses in this category are related to the improper management of time and state in an environment that supports simultaneous or near-simultaneous computation by multiple systems, processes, or threads.
*Weakness ClassWeakness ClassConcurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') - (362)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 361 (Time and State) > 362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))
The program contains a code sequence that can run concurrently with other code, and the code sequence requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence that is operating concurrently.
+Weakness ClassWeakness ClassExposure of Resource to Wrong Sphere - (668)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 361 (Time and State) > 668 (Exposure of Resource to Wrong Sphere)
The product exposes a resource to the wrong control sphere, providing unintended actors with inappropriate access to the resource.
*Weakness BaseWeakness BaseFiles or Directories Accessible to External Parties - (552)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 361 (Time and State) > 668 (Exposure of Resource to Wrong Sphere) > 552 (Files or Directories Accessible to External Parties)
Files or directories are accessible in the environment that should not be.
+Weakness ClassWeakness ClassInformation Exposure - (200)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 361 (Time and State) > 668 (Exposure of Resource to Wrong Sphere) > 200 (Information Exposure)
An information exposure is the intentional or unintentional disclosure of information to an actor that is not explicitly authorized to have access to that information.Information LeakInformation Disclosure
+Weakness BaseWeakness BaseFile and Directory Information Exposure - (538)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 361 (Time and State) > 668 (Exposure of Resource to Wrong Sphere) > 200 (Information Exposure) > 538 (File and Directory Information Exposure)
The product stores sensitive information in files or directories that are accessible to actors outside of the intended control sphere.
+Weakness VariantWeakness VariantInformation Exposure Through Log Files - (532)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 361 (Time and State) > 668 (Exposure of Resource to Wrong Sphere) > 200 (Information Exposure) > 538 (File and Directory Information Exposure) > 532 (Information Exposure Through Log Files)
Information written to log files can be of a sensitive nature and give valuable guidance to an attacker or expose sensitive user information.
*Weakness VariantWeakness VariantInformation Exposure Through Debug Log Files - (534)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 361 (Time and State) > 668 (Exposure of Resource to Wrong Sphere) > 200 (Information Exposure) > 538 (File and Directory Information Exposure) > 532 (Information Exposure Through Log Files) > 534 (Information Exposure Through Debug Log Files)
The application does not sufficiently restrict access to a log file that is used for debugging.
*Weakness VariantWeakness VariantSensitive Data Under FTP Root - (220)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 361 (Time and State) > 668 (Exposure of Resource to Wrong Sphere) > 220 (Sensitive Data Under FTP Root)
The application stores sensitive data under the FTP document root with insufficient access control, which might make it accessible to untrusted parties.
+Weakness ClassWeakness ClassImproper Control of a Resource Through its Lifetime - (664)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 361 (Time and State) > 664 (Improper Control of a Resource Through its Lifetime)
The software does not maintain or incorrectly maintains control over a resource throughout its lifetime of creation, use, and release.
+Weakness ClassWeakness ClassExternally Controlled Reference to a Resource in Another Sphere - (610)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 361 (Time and State) > 664 (Improper Control of a Resource Through its Lifetime) > 610 (Externally Controlled Reference to a Resource in Another Sphere)
The product uses an externally controlled name or reference that resolves to a resource that is outside of the intended control sphere.
*Weakness VariantWeakness VariantImproper Restriction of XML External Entity Reference ('XXE') - (611)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 361 (Time and State) > 664 (Improper Control of a Resource Through its Lifetime) > 610 (Externally Controlled Reference to a Resource in Another Sphere) > 611 (Improper Restriction of XML External Entity Reference ('XXE'))
The software processes an XML document that can contain XML entities with URIs that resolve to documents outside of the intended sphere of control, causing the product to embed incorrect documents into its output.XXE
+Weakness ClassWeakness ClassUnintended Proxy or Intermediary ('Confused Deputy') - (441)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 361 (Time and State) > 664 (Improper Control of a Resource Through its Lifetime) > 610 (Externally Controlled Reference to a Resource in Another Sphere) > 441 (Unintended Proxy or Intermediary ('Confused Deputy'))
The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor.Confused Deputy
*Weakness BaseWeakness BaseServer-Side Request Forgery (SSRF) - (918)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 361 (Time and State) > 664 (Improper Control of a Resource Through its Lifetime) > 610 (Externally Controlled Reference to a Resource in Another Sphere) > 441 (Unintended Proxy or Intermediary ('Confused Deputy')) > 918 (Server-Side Request Forgery (SSRF))
The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.XSPA
+Weakness ClassWeakness ClassImproper Control of Dynamically-Managed Code Resources - (913)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 361 (Time and State) > 664 (Improper Control of a Resource Through its Lifetime) > 913 (Improper Control of Dynamically-Managed Code Resources)
The software does not properly restrict reading from or writing to dynamically-managed code resources such as variables, objects, classes, attributes, functions, or executable instructions or statements.
*Weakness VariantWeakness VariantDeserialization of Untrusted Data - (502)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 361 (Time and State) > 664 (Improper Control of a Resource Through its Lifetime) > 913 (Improper Control of Dynamically-Managed Code Resources) > 502 (Deserialization of Untrusted Data)
The application deserializes untrusted data without sufficiently verifying that the resulting data will be valid.Marshaling, UnmarshalingPickling, Unpickling
*Weakness ClassWeakness ClassImproper Initialization - (665)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 361 (Time and State) > 664 (Improper Control of a Resource Through its Lifetime) > 665 (Improper Initialization)
The software does not initialize or incorrectly initializes a resource, which might leave the resource in an unexpected state when it is accessed or used.
*Weakness ClassWeakness ClassIncorrect Type Conversion or Cast - (704)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 361 (Time and State) > 664 (Improper Control of a Resource Through its Lifetime) > 704 (Incorrect Type Conversion or Cast)
The software does not correctly convert an object, resource or structure from one type to a different type.
+Weakness ClassWeakness ClassIncorrect Resource Transfer Between Spheres - (669)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 361 (Time and State) > 669 (Incorrect Resource Transfer Between Spheres)
The product does not properly transfer a resource/behavior to another sphere, or improperly imports a resource/behavior from another sphere, in a manner that provides unintended control over that resource.
*Weakness BaseWeakness BaseUnrestricted Upload of File with Dangerous Type - (434)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 361 (Time and State) > 669 (Incorrect Resource Transfer Between Spheres) > 434 (Unrestricted Upload of File with Dangerous Type)
The software allows the attacker to upload or transfer files of dangerous types that can be automatically processed within the product's environment.Unrestricted File Upload
+CategoryCategoryState Issues - (371)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 361 (Time and State) > 371 (State Issues)
Weaknesses in this category are related to improper management of system state.
*Weakness BaseWeakness BaseExternal Control of Assumed-Immutable Web Parameter - (472)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 17 (Code) > 18 (Source Code) > 361 (Time and State) > 371 (State Issues) > 472 (External Control of Assumed-Immutable Web Parameter)
The web application does not sufficiently verify inputs that are assumed to be immutable but are actually externally controllable, such as hidden form fields.Assumed-Immutable Parameter Tampering
*CategoryCategoryConfiguration - (16)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 16 (Configuration)
Weaknesses in this category are typically introduced during the configuration of the software.
+CategoryCategoryEnvironment - (2)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 2 (Environment)
Weaknesses in this category are typically introduced during unexpected environmental conditions.
+Weakness ClassWeakness ClassInteraction Error - (435)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 2 (Environment) > 435 (Interaction Error)
An interaction error occurs when two entities work correctly when running independently, but they interact in unexpected ways when they are run together.
+Weakness BaseWeakness BaseInterpretation Conflict - (436)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 2 (Environment) > 435 (Interaction Error) > 436 (Interpretation Conflict)
Product A handles inputs or steps differently than Product B, which causes A to perform incorrect actions based on its perception of B's state.
*Weakness BaseWeakness BaseInconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling') - (444)
1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 2 (Environment) > 435 (Interaction Error) > 436 (Interpretation Conflict) > 444 (Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling'))
When malformed or abnormal HTTP requests are interpreted by one or more entities in the data flow between the user and the web server, such as a proxy or firewall, they can be interpreted inconsistently, allowing the attacker to "smuggle" a request to one device without the other device being aware of it.
+ References
NIST. "CWE - Common Weakness Enumeration". <http://nvd.nist.gov/cwe.cfm>.
+ Maintenance Notes

This view contains many entries that are being considered for use in NVD in 2015. This list is expected to change with contributions from additional sources.

+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2015-12-07Internal CWE Team
Contributions
Contribution DateContributorOrganizationSource
2015-12-07NISTContent
Provided many relationships.
+ View Metrics
CWEs in this viewTotal CWEs
Total114out of1006
Views0out of33
Categories20out of245
Weaknesses91out of720
Compound_Elements3out of8
View Components
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-824: Access of Uninitialized Pointer

Weakness ID: 824
Abstraction: Base
Status: Incomplete
Presentation Filter:
+ Description

Description Summary

The program accesses or uses a pointer that has not been initialized.

Extended Description

If the pointer contains an uninitialized value, then the value might not point to a valid memory location. This could cause the program to read from or write to unexpected memory locations, leading to a denial of service. If the uninitialized pointer is used as a function call, then arbitrary functions could be invoked. If an attacker can influence the portion of uninitialized memory that is contained in the pointer, this weakness could be leveraged to execute code or perform other attacks.

Depending on memory layout, associated memory management behaviors, and program operation, the attacker might be able to influence the contents of the uninitialized pointer, thus gaining more fine-grained control of the memory location to be accessed.

+ Terminology Notes

Many weaknesses related to pointer dereferences fall under the general term of "memory corruption" or "memory safety." As of September 2010, there is no commonly-used terminology that covers the lower-level variants.

+ Common Consequences
ScopeEffect
Confidentiality

Technical Impact: Read memory

If the uninitialized pointer is used in a read operation, an attacker might be able to read sensitive portions of memory.

Availability

Technical Impact: DoS: crash / exit / restart

If the uninitialized pointer references a memory location that is not accessible to the program, or points to a location that is "malformed" (such as NULL) or larger than expected by a read or write operation, then a crash may occur.

Integrity
Confidentiality
Availability

Technical Impact: Execute unauthorized code or commands

If the uninitialized pointer is used in a function call, or points to unexpected data in a write operation, then code execution may be possible.

+ Observed Examples
ReferenceDescription
chain: unchecked return value (CWE-252) leads to free of invalid, uninitialized pointer (CWE-824).
Pointer in structure is not initialized, leading to NULL pointer dereference (CWE-476) and system crash.
Free of an uninitialized pointer.
Improper handling of invalid signatures leads to free of invalid pointer.
Invalid encoding triggers free of uninitialized pointer.
Crafted PNG image leads to free of uninitialized pointer.
Crafted GIF image leads to free of uninitialized pointer.
Access of uninitialized pointer might lead to code execution.
Step-based manipulation: invocation of debugging function before the primary initialization function leads to access of an uninitialized pointer and code execution.
Unchecked return values can lead to a write to an uninitialized pointer.
zero-length input leads to free of uninitialized pointer.
Crafted font leads to uninitialized function pointer.
Uninitialized function pointer in freed memory is invoked
LDAP server mishandles malformed BER queries, leading to free of uninitialized memory
Firewall can crash with certain ICMP packets that trigger access of an uninitialized pointer.
LDAP server does not initialize members of structs, which leads to free of uninitialized pointer if an LDAP request fails.
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class119Improper Restriction of Operations within the Bounds of a Memory Buffer
Development Concepts (primary)699
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfCategoryCategory465Pointer Issues
Development Concepts699
CanPrecedeWeakness BaseWeakness Base125Out-of-bounds Read
Research Concepts1000
CanPrecedeWeakness BaseWeakness Base787Out-of-bounds Write
Research Concepts1000
+ Research Gaps

Under-studied and probably under-reported as of September 2010. This weakness has been reported in high-visibility software, but applied vulnerability researchers have only been investigating it since approximately 2008, and there are only a few public reports. Few reports identify weaknesses at such a low level, which makes it more difficult to find and study real-world code examples.

+ References
[REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 7, "Variable Initialization", Page 312.. 1st Edition. Addison Wesley. 2006.
+ Maintenance Notes

There are close relationships between incorrect pointer dereferences and other weaknesses related to buffer operations. There may not be sufficient community agreement regarding these relationships. Further study is needed to determine when these relationships are chains, composites, perspective/layering, or other types of relationships. As of September 2010, most of the relationships are being captured as chains.

+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2010-09-22MITREInternal CWE Team
Modifications
Modification DateModifierOrganizationSource
2012-05-11CWE Content TeamMITREInternal
updated References
2015-12-07CWE Content TeamMITREInternal
updated Relationships

CWE-407: Algorithmic Complexity

Weakness ID: 407
Abstraction: Base
Status: Incomplete
Presentation Filter:
+ Description

Description Summary

An algorithm in a product has an inefficient worst-case computational complexity that may be detrimental to system performance and can be triggered by an attacker, typically using crafted manipulations that ensure that the worst case is being reached.
+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms

Languages

Language-independent

+ Common Consequences
ScopeEffect
Availability

Technical Impact: DoS: resource consumption (CPU); DoS: resource consumption (memory); DoS: resource consumption (other)

The typical consequence is CPU consumption, but memory consumption and consumption of other resources can also occur.

+ Likelihood of Exploit

Low to Medium

+ Observed Examples
ReferenceDescription
CPU consumption via inputs that cause many hash table collisions.
CPU consumption via inputs that cause many hash table collisions.
Product performs unnecessary processing before dropping an invalid packet.
CPU and memory consumption using many wildcards.
Product allows attackers to cause multiple copies of a program to be loaded more quickly than the program can detect that other copies are running, then exit. This type of error should probably have its own category, where teardown takes more time than initialization.
Network monitoring system allows remote attackers to cause a denial of service (CPU consumption and detection outage) via crafted network traffic, aka a "backtracking attack."
Wiki allows remote attackers to cause a denial of service (CPU consumption) by performing a diff between large, crafted pages that trigger the worst case algorithmic complexity.
Wiki allows remote attackers to cause a denial of service (CPU consumption) by performing a diff between large, crafted pages that trigger the worst case algorithmic complexity.
OS allows attackers to cause a denial of service (CPU consumption) via crafted Gregorian dates.
Memory leak by performing actions faster than the software can clear them.
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class405Asymmetric Resource Consumption (Amplification)
Development Concepts (primary)699
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfCategoryCategory977SFP Secondary Cluster: Design
Software Fault Pattern (SFP) Clusters (primary)888
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
+ Functional Areas
  • Cryptography
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERAlgorithmic Complexity
+ References
Crosby and Wallach. "Algorithmic Complexity Attacks". <http://www.cs.rice.edu/~scrosby/hash/CrosbyWallach_UsenixSec2003/index.html>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2009-07-27CWE Content TeamMITREInternal
updated Functional_Areas, Other_Notes
2009-10-29CWE Content TeamMITREInternal
updated Common_Consequences
2009-12-28CWE Content TeamMITREInternal
updated Applicable_Platforms, Likelihood_of_Exploit
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Observed_Examples, Relationships
2014-07-30CWE Content TeamMITREInternal
updated Relationships
2015-12-07CWE Content TeamMITREInternal
updated Relationships

CWE-774: Allocation of File Descriptors or Handles Without Limits or Throttling

Weakness ID: 774
Abstraction: Variant
Status: Incomplete
Presentation Filter:
+ Description

Description Summary

The software allocates file descriptors or handles on behalf of an actor without imposing any restrictions on how many descriptors can be allocated, in violation of the intended security policy for that actor.

Extended Description

This can cause the software to consume all available file descriptors or handles, which can prevent other processes from performing critical file processing operations.

+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Common Consequences
ScopeEffect
Availability

Technical Impact: DoS: resource consumption (other)

When allocating resources without limits, an attacker could prevent all other processes from accessing the same type of resource.

+ Likelihood of Exploit

Medium to High

+ Potential Mitigations

Phases: Operation; Architecture and Design

Strategy: Limit Resource Consumption

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
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory769File Descriptor Exhaustion
Development Concepts (primary)699
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfWeakness BaseWeakness Base770Allocation of Resources Without Limits or Throttling
Research Concepts (primary)1000
ChildOfCategoryCategory985SFP Secondary Cluster: Unrestricted Consumption
Software Fault Pattern (SFP) Clusters (primary)888
+ Theoretical Notes

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 NameNode IDFitMapped Node Name
Software Fault PatternsSFP13Unrestricted Consumption
+ References
[REF-7] 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 DateSubmitterOrganizationSource
2009-05-13Internal CWE Team
Modifications
Modification DateModifierOrganizationSource
2010-04-05CWE Content TeamMITREInternal
updated Potential_Mitigations
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated References, Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITREInternal
updated Relationships

CWE-88: Argument Injection or Modification

Weakness ID: 88
Abstraction: Base
Status: Draft
Presentation Filter:
+ Description

Description Summary

The software does not sufficiently delimit the arguments being passed to a component in another control sphere, allowing alternate arguments to be provided, leading to potentially security-relevant changes.
+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms

Languages

All

+ Common Consequences
ScopeEffect
Confidentiality
Integrity
Availability
Other

Technical Impact: Execute unauthorized code or commands; Alter execution logic; Read application data; Modify application data

An attacker could include arguments that allow unintended commands or code to be executed, allow sensitive data to be read or modified or could cause other unintended behavior.

+ Demonstrative Examples

Example 1

The following simple program accepts a filename as a command line argument and displays the contents of the file back to the user. The program is installed setuid root because it is intended for use as a learning tool to allow system administrators in-training to inspect privileged system files without giving them the ability to modify them or damage the system.

(Bad Code)
Example Language:
int main(int argc, char** argv) {
char cmd[CMD_MAX] = "/usr/bin/cat ";
strcat(cmd, argv[1]);
system(cmd);
}

Because the program runs with root privileges, the call to system() also executes with root privileges. If a user specifies a standard filename, the call works as expected. However, if an attacker passes a string of the form ";rm -rf /", then the call to system() fails to execute cat due to a lack of arguments and then plows on to recursively delete the contents of the root partition.

Note that if argv[1] is a very long argument, then this issue might also be subject to a buffer overflow (CWE-120).

+ Observed Examples
ReferenceDescription
Canonical Example
Web browser executes Telnet sessions using command line arguments that are specified by the web site, which could allow remote attackers to execute arbitrary commands.
Web browser allows remote attackers to execute commands by spawning Telnet with a log file option on the command line and writing arbitrary code into an executable file which is later executed.
Argument injection vulnerability in the mail function for PHP may allow attackers to bypass safe mode restrictions and modify command line arguments to the MTA (e.g. sendmail) possibly executing commands.
Help and Support center in windows does not properly validate HCP URLs, which allows remote attackers to execute arbitrary code via quotation marks in an "hcp://" URL.
Mail client does not sufficiently filter parameters of mailto: URLs when using them as arguments to mail executable, which allows remote attackers to execute arbitrary programs.
Web browser doesn't filter "-" when invoking various commands, allowing command-line switches to be specified.
Mail client allows remote attackers to execute arbitrary code via a URI that uses a UNC network share pathname to provide an alternate configuration file.
SSH URI handler for web browser allows remote attackers to execute arbitrary code or conduct port forwarding via the a command line option.
Web browser doesn't filter "-" when invoking various commands, allowing command-line switches to be specified.
Argument injection vulnerability in TellMe 1.2 and earlier allows remote attackers to modify command line arguments for the Whois program and obtain sensitive information via "--" style options in the q_Host parameter.
Beagle before 0.2.5 can produce certain insecure command lines to launch external helper applications while indexing, which allows attackers to execute arbitrary commands. NOTE: it is not immediately clear whether this issue involves argument injection, shell metacharacters, or other issues.
Argument injection vulnerability in Internet Explorer 6 for Windows XP SP2 allows user-assisted remote attackers to modify command line arguments to an invoked mail client via " (double quote) characters in a mailto: scheme handler, as demonstrated by launching Microsoft Outlook with an arbitrary filename as an attachment. NOTE: it is not clear whether this issue is implementation-specific or a problem in the Microsoft API.
Argument injection vulnerability in Mozilla Firefox 1.0.6 allows user-assisted remote attackers to modify command line arguments to an invoked mail client via " (double quote) characters in a mailto: scheme handler, as demonstrated by launching Microsoft Outlook with an arbitrary filename as an attachment. NOTE: it is not clear whether this issue is implementation-specific or a problem in the Microsoft API.
Argument injection vulnerability in Avant Browser 10.1 Build 17 allows user-assisted remote attackers to modify command line arguments to an invoked mail client via " (double quote) characters in a mailto: scheme handler, as demonstrated by launching Microsoft Outlook with an arbitrary filename as an attachment. NOTE: it is not clear whether this issue is implementation-specific or a problem in the Microsoft API.
Argument injection vulnerability in the URI handler in Skype 2.0.*.104 and 2.5.*.0 through 2.5.*.78 for Windows allows remote authorized attackers to download arbitrary files via a URL that contains certain command-line switches.
Argument injection vulnerability in WinSCP 3.8.1 build 328 allows remote attackers to upload or download arbitrary files via encoded spaces and double-quote characters in a scp or sftp URI.
Argument injection vulnerability in the Windows Object Packager (packager.exe) in Microsoft Windows XP SP1 and SP2 and Server 2003 SP1 and earlier allows remote user-assisted attackers to execute arbitrary commands via a crafted file with a "/" (slash) character in the filename of the Command Line property, followed by a valid file extension, which causes the command before the slash to be executed, aka "Object Packager Dialogue Spoofing Vulnerability."
Argument injection vulnerability in HyperAccess 8.4 allows user-assisted remote attackers to execute arbitrary vbscript and commands via the /r option in a telnet:// URI, which is configured to use hawin32.exe.
Argument injection vulnerability in the telnet daemon (in.telnetd) in Solaris 10 and 11 (SunOS 5.10 and 5.11) misinterprets certain client "-f" sequences as valid requests for the login program to skip authentication, which allows remote attackers to log into certain accounts, as demonstrated by the bin account.
Language interpreter's mail function accepts another argument that is concatenated to a string used in a dangerous popen() call. Since there is no neutralization of this argument, both OS Command Injection (CWE-78) and Argument Injection (CWE-88) are possible.
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Input Validation

Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, request headers as well as content, URL components, e-mail, files, databases, and any external systems that provide data to the application. Perform input validation at well-defined interfaces.

Phase: Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist 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 (i.e., do not rely on a blacklist). A blacklist 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, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

Phase: Implementation

Directly convert your input type into the expected data type, such as using a conversion function that translates a string into a number. After converting to the expected data type, ensure that the input's values fall within the expected range of allowable values and that multi-field consistencies are maintained.

Phase: Implementation

Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180, CWE-181). Make sure that your application does not inadvertently decode the same input twice (CWE-174). Such errors could be used to bypass whitelist schemes by introducing dangerous inputs after they have been checked. Use libraries such as the OWASP ESAPI Canonicalization control.

Consider performing repeated canonicalization until your input does not change any more. This will avoid double-decoding and similar scenarios, but it might inadvertently modify inputs that are allowed to contain properly-encoded dangerous content.

Phase: Implementation

When exchanging data between components, ensure that both components are using the same character encoding. Ensure that the proper encoding is applied at each interface. Explicitly set the encoding you are using whenever the protocol allows you to do so.

Phase: Implementation

When your application combines data from multiple sources, perform the validation after the sources have been combined. The individual data elements may pass the validation step but violate the intended restrictions after they have been combined.

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

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

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class77Improper Neutralization of Special Elements used in a Command ('Command Injection')
Development Concepts (primary)699
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfCategoryCategory634Weaknesses that Affect System Processes
Resource-specific Weaknesses (primary)631
ChildOfCategoryCategory741CERT C Secure Coding Section 07 - Characters and Strings (STR)
Weaknesses Addressed by the CERT C Secure Coding Standard (primary)734
ChildOfCategoryCategory744CERT C Secure Coding Section 10 - Environment (ENV)
Weaknesses Addressed by the CERT C Secure Coding Standard734
ChildOfCategoryCategory810OWASP Top Ten 2010 Category A1 - Injection
Weaknesses in OWASP Top Ten (2010) (primary)809
ChildOfCategoryCategory875CERT C++ Secure Coding Section 07 - Characters and Strings (STR)
Weaknesses Addressed by the CERT C++ Secure Coding Standard (primary)868
ChildOfCategoryCategory878CERT C++ Secure Coding Section 10 - Environment (ENV)
Weaknesses Addressed by the CERT C++ Secure Coding Standard868
ChildOfCategoryCategory929OWASP Top Ten 2013 Category A1 - Injection
Weaknesses in OWASP Top Ten (2013) (primary)928
ChildOfCategoryCategory990SFP Secondary Cluster: Tainted Input to Command
Software Fault Pattern (SFP) Clusters (primary)888
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
CanAlsoBeWeakness BaseWeakness Base78Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Research Concepts1000
+ Relationship Notes

At one layer of abstraction, this can overlap other weaknesses that have whitespace problems, e.g. injection of javascript into attributes of HTML tags.

+ Affected Resources
  • System Process
+ Causal Nature

Explicit

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERArgument Injection or Modification
CERT C Secure CodingENV03-CSanitize the environment when invoking external programs
CERT C Secure CodingENV04-CDo not call system() if you do not need a command processor
CERT C Secure CodingSTR02-CSanitize data passed to complex subsystems
WASC30Mail Command Injection
CERT C++ Secure CodingSTR02-CPPSanitize data passed to complex subsystems
CERT C++ Secure CodingENV03-CPPSanitize the environment when invoking external programs
CERT C++ Secure CodingENV04-CPPDo not call system() if you do not need a command processor
+ References
Steven Christey. "Argument injection issues". <http://www.securityfocus.com/archive/1/archive/1/460089/100/100/threaded>.
[REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 10, "The Argument Array", Page 567.. 1st Edition. Addison Wesley. 2006.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-11-24CWE Content TeamMITREInternal
updated Observed_Examples, Relationships, Taxonomy_Mappings
2009-07-27CWE Content TeamMITREInternal
updated Other_Notes, Relationship_Notes
2009-10-29CWE Content TeamMITREInternal
updated Observed_Examples
2010-02-16CWE Content TeamMITREInternal
updated Potential_Mitigations, Relationships, Taxonomy_Mappings
2010-04-05CWE Content TeamMITREInternal
updated Related_Attack_Patterns
2010-06-21CWE Content TeamMITREInternal
updated Observed_Examples, Relationships
2010-09-27CWE Content TeamMITREInternal
updated Relationships
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2011-09-13CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Common_Consequences, Demonstrative_Examples, Observed_Examples, References, Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-06-23CWE Content TeamMITREInternal
updated Relationships
2014-07-30CWE Content TeamMITREInternal
updated Relationships
2015-12-07CWE Content TeamMITREInternal
updated Demonstrative_Examples, Relationships

CWE-405: Asymmetric Resource Consumption (Amplification)

Weakness ID: 405
Abstraction: Class
Status: Incomplete
Presentation Filter:
+ Description

Description Summary

Software that does not appropriately monitor or control resource consumption can lead to adverse system performance.

Extended Description

This situation is amplified if the software allows malicious users or attackers to consume more resources than their access level permits. Exploiting such a weakness can lead to asymmetric resource consumption, aiding in amplification attacks against the system or the network.

+ Time of Introduction
  • Operation
  • Architecture and Design
  • Implementation
+ Applicable Platforms

Languages

All

+ Common Consequences
ScopeEffect
Availability

Technical Impact: DoS: amplification; DoS: resource consumption (other)

Sometimes this is a factor in "flood" attacks, but other types of amplification exist.

+ Potential Mitigations

Phase: Architecture and Design

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

Phase: Architecture and Design

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

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory399Resource Management Errors
Development Concepts (primary)699
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfWeakness ClassWeakness Class664Improper Control of a Resource Through its Lifetime
Research Concepts (primary)1000
ChildOfCategoryCategory730OWASP Top Ten 2004 Category A9 - Denial of Service
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory855CERT Java Secure Coding Section 10 - Thread Pools (TPS)
Weaknesses Addressed by the CERT Java Secure Coding Standard844
ChildOfCategoryCategory857CERT Java Secure Coding Section 12 - Input Output (FIO)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory977SFP Secondary Cluster: Design
Software Fault Pattern (SFP) Clusters (primary)888
ParentOfWeakness BaseWeakness Base406Insufficient Control of Network Message Volume (Network Amplification)
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base407Algorithmic Complexity
Development Concepts (primary)699
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ParentOfWeakness BaseWeakness Base408Incorrect Behavior Order: Early Amplification
Development Concepts (primary)699
Research Concepts1000
ParentOfWeakness BaseWeakness Base409Improper Handling of Highly Compressed Data (Data Amplification)
Development Concepts (primary)699
Research Concepts (primary)1000
PeerOfWeakness BaseWeakness Base404Improper Resource Shutdown or Release
Research Concepts1000
+ Functional Areas
  • Non-specific
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERAsymmetric resource consumption (amplification)
OWASP Top Ten 2004A9CWE More SpecificDenial of Service
WASC41XML Attribute Blowup
CERT Java Secure CodingTPS00-JUse thread pools to enable graceful degradation of service during traffic bursts
CERT Java Secure CodingFIO04-JRelease resources when they are no longer needed
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITREInternal
updated Description
2009-07-27CWE Content TeamMITREInternal
updated Common_Consequences, Other_Notes
2010-02-16CWE Content TeamMITREInternal
updated Taxonomy_Mappings
2010-12-13CWE Content TeamMITREInternal
updated Description
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-07-30CWE Content TeamMITREInternal
updated Relationships
2015-12-07CWE Content TeamMITREInternal
updated Relationships

CWE CATEGORY: Channel and Path Errors

Category ID: 417
Status: Draft
+ Description

Description Summary

Weaknesses in this category are related to improper handling of communication channels and access paths.
+ Applicable Platforms

Languages

All

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory18Source Code
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ParentOfCategoryCategory418Channel Errors
Development Concepts (primary)699
ParentOfWeakness ClassWeakness Class424Improper Protection of Alternate Path
Development Concepts (primary)699
ParentOfCompound Element: CompositeCompound Element: Composite426Untrusted Search Path
Development Concepts (primary)699
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ParentOfWeakness BaseWeakness Base427Uncontrolled Search Path Element
Development Concepts (primary)699
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ParentOfWeakness BaseWeakness Base428Unquoted Search Path or Element
Development Concepts (primary)699
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
MemberOfViewView699Development Concepts
Development Concepts (primary)699
+ Relationship Notes

A number of vulnerabilities are specifically related to problems in creating, managing, or removing alternate channels and alternate paths. Some of these can overlap virtual file problems. They are commonly used in "bypass" attacks, such as those that exploit authentication errors.

+ Research Gaps

Most of these issues are probably under-studied. Only a handful of public reports exist.

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERCHAP.VIRTFILEChannel and Path Errors
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-07-27CWE Content TeamMITREInternal
updated Other_Notes, Relationship_Notes
2015-12-07CWE Content TeamMITREInternal
updated Relationships
2017-01-19CWE Content TeamMITREInternal
updated Relationships

CWE CATEGORY: Cleansing, Canonicalization, and Comparison Errors

Category ID: 171
Status: Draft
+ Description

Description Summary

Weaknesses in this category are related to improper handling of data within protection mechanisms that attempt to perform neutralization for untrusted data.
+ Applicable Platforms

Languages

Language-independent

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory137Representation Errors
Development Concepts (primary)699
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfCategoryCategory845CERT Java Secure Coding Section 00 - Input Validation and Data Sanitization (IDS)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
CanPrecedeWeakness VariantWeakness Variant289Authentication Bypass by Alternate Name
Research Concepts1000
ParentOfWeakness ClassWeakness Class172Encoding Error
Development Concepts (primary)699
ParentOfWeakness BaseWeakness Base178Improper Handling of Case Sensitivity
Development Concepts (primary)699
ParentOfWeakness BaseWeakness Base179Incorrect Behavior Order: Early Validation
Development Concepts699
ParentOfWeakness BaseWeakness Base180Incorrect Behavior Order: Validate Before Canonicalize
Development Concepts699
ParentOfWeakness BaseWeakness Base181Incorrect Behavior Order: Validate Before Filter
Development Concepts699
ParentOfWeakness BaseWeakness Base182Collapse of Data into Unsafe Value
Development Concepts (primary)699
ParentOfWeakness BaseWeakness Base183Permissive Whitelist
Development Concepts (primary)699
ParentOfWeakness BaseWeakness Base184Incomplete Blacklist
Development Concepts (primary)699
ParentOfWeakness ClassWeakness Class185Incorrect Regular Expression
Development Concepts (primary)699
ParentOfWeakness BaseWeakness Base187Partial Comparison
Development Concepts (primary)699
ParentOfWeakness VariantWeakness Variant478Missing Default Case in Switch Statement
Development Concepts699
ParentOfWeakness VariantWeakness Variant486Comparison of Classes by Name
Development Concepts699
ParentOfWeakness BaseWeakness Base595Comparison of Object References Instead of Object Contents
Development Concepts699
ParentOfWeakness BaseWeakness Base596Incorrect Semantic Object Comparison
Development Concepts699
ParentOfWeakness ClassWeakness Class697Insufficient Comparison
Development Concepts (primary)699
ParentOfWeakness ClassWeakness Class707Improper Enforcement of Message or Data Structure
Development Concepts (primary)699
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ParentOfWeakness VariantWeakness Variant768Incorrect Short Circuit Evaluation
Development Concepts (primary)699
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERCleansing, Canonicalization, and Comparison Errors
CERT Java Secure CodingIDS02-JCanonicalize path names before validating them
+ References
[REF-11] M. Howard and D. LeBlanc. "Writing Secure Code". 2nd Edition. Microsoft. 2002.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITREInternal
updated Relationships
2009-12-28CWE Content TeamMITREInternal
updated Applicable_Platforms
2011-06-01CWE Content TeamMITREInternal
updated Description, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated References, Related_Attack_Patterns, Taxonomy_Mappings
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2013-02-21CWE Content TeamMITREInternal
updated Potential_Mitigations
2015-12-07CWE Content TeamMITREInternal
updated Relationships
2017-01-19CWE Content TeamMITREInternal
updated Relationships

CWE CATEGORY: Code

Category ID: 17
Status: Draft
+ Description

Description Summary

Weaknesses in this category are typically introduced during code development, including specification, design, and implementation.
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ParentOfCategoryCategory18Source Code
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
MemberOfViewView1003Weaknesses for Simplified Mapping of Published Vulnerabilities
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
+ Maintenance Notes

This entry is being considered for deprecation. It was originally used for organizing the Development View (CWE-699), but it introduced unnecessary complexity and depth to the resulting tree. It cannot be deprecated until after the CWE team has reviewed whether other CWE elements are appropriately capturing the "location" in which the weaknesses are introduced.

+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-09-08CWE Content TeamMITREInternal
updated Relationships
2015-12-07CWE Content TeamMITREInternal
updated Relationships
2017-01-19CWE Content TeamMITREInternal
updated Maintenance_Notes, Relationships

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

Weakness ID: 362
Abstraction: Class
Status: Draft
Presentation Filter:
+ Description

Description Summary

The program contains a code sequence that can run concurrently with other code, and the code sequence requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence that is operating concurrently.

Extended Description

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

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

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

  • Exclusivity - the code sequence is given exclusive access to the shared resource, i.e., no other code sequence can modify properties of the shared resource before the original sequence has completed execution.

  • Atomicity - the code sequence is behaviorally atomic, i.e., no other thread or process can concurrently execute the same sequence of instructions (or a subset) against the same resource.

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

The interfering code sequence could be "trusted" or "untrusted." A trusted interfering code sequence occurs within the program; 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 program.

+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms

Languages

C: (Sometimes)

C++: (Sometimes)

Java: (Sometimes)

Language-independent

Architectural Paradigms

Concurrent Systems Operating on Shared Resources: (Often)

+ Common Consequences
ScopeEffect
Availability

Technical Impact: DoS: resource consumption (CPU); DoS: resource consumption (memory); DoS: resource consumption (other)

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

Availability

Technical Impact: DoS: crash / exit / restart; DoS: instability

When a race condition allows multiple control flows to access a resource simultaneously, it might lead the program(s) into unexpected states, possibly resulting in a crash.

Confidentiality
Integrity

Technical Impact: Read files or directories; Read application data

When a race condition is combined with predictable resource names and loose permissions, it may be possible for an attacker to overwrite or access confidential data (CWE-59).

+ Likelihood of Exploit

Medium

+ Detection Methods

Black Box

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

White Box

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

Automated Dynamic Analysis

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

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

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

Effectiveness: Moderate

Automated Static Analysis - Binary / 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: SOAR 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: SOAR 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: SOAR 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: SOAR High

Architecture / 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: SOAR High

+ 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)
Example Language: 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 it to higher levels.

(Good Code)
 
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);
}
+ Observed Examples
ReferenceDescription
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
+ Potential Mitigations

Phase: Architecture and Design

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

Phase: Architecture and Design

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

Phase: Architecture and Design

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

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

Phase: Implementation

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

Phase: Implementation

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

Phase: Implementation

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

Phase: Implementation

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

Phase: Implementation

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

Phase: Implementation

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

Phases: Architecture and Design; Operation

Strategy: Environment Hardening

Run your code using the lowest privileges that are required to accomplish the necessary tasks [R.362.11]. 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
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory361Time and State
Development Concepts (primary)699
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfWeakness ClassWeakness Class691Insufficient Control Flow Management
Research Concepts (primary)1000
ChildOfCategoryCategory743CERT C Secure Coding Section 09 - Input Output (FIO)
Weaknesses Addressed by the CERT C Secure Coding Standard (primary)734
ChildOfCategoryCategory7512009 Top 25 - Insecure Interaction Between Components
Weaknesses in the 2009 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)750
ChildOfCategoryCategory8012010 Top 25 - Insecure Interaction Between Components
Weaknesses in the 2010 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)800
ChildOfCategoryCategory852CERT Java Secure Coding Section 07 - Visibility and Atomicity (VNA)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory8672011 Top 25 - Weaknesses On the Cusp
Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors (primary)900
ChildOfCategoryCategory877CERT C++ Secure Coding Section 09 - Input Output (FIO)
Weaknesses Addressed by the CERT C++ Secure Coding Standard868
ChildOfCategoryCategory882CERT C++ Secure Coding Section 14 - Concurrency (CON)
Weaknesses Addressed by the CERT C++ Secure Coding Standard (primary)868
ChildOfCategoryCategory988SFP Secondary Cluster: Race Condition Window
Software Fault Pattern (SFP) Clusters (primary)888
RequiredByCompound Element: CompositeCompound Element: Composite61UNIX Symbolic Link (Symlink) Following
Research Concepts1000
RequiredByCompound Element: CompositeCompound Element: Composite689Permission Race Condition During Resource Copy
Research Concepts1000
ParentOfWeakness BaseWeakness Base364Signal Handler Race Condition
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base366Race Condition within a Thread
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base367Time-of-check Time-of-use (TOCTOU) Race Condition
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base368Context Switching Race Condition
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base421Race Condition During Access to Alternate Channel
Development Concepts699
Research Concepts1000
MemberOfViewView635Weaknesses Used by NVD
Weaknesses Used by NVD (primary)635
CanFollowWeakness BaseWeakness Base662Improper Synchronization
Development Concepts699
Research Concepts1000
CanAlsoBeCategoryCategory557Concurrency Issues
Research Concepts1000
+ Research Gaps

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

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.

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERRace Conditions
CERT C Secure CodingFIO31-CDo not simultaneously open the same file multiple times
CERT Java Secure CodingVNA03-JDo not assume that a group of calls to independently atomic methods is atomic
CERT C++ Secure CodingFIO31-CPPDo not simultaneously open the same file multiple times
CERT C++ Secure CodingCON02-CPPUse lock classes for mutex management
+ References
[R.362.1] [REF-17] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 13: Race Conditions." Page 205. McGraw-Hill. 2010.
[R.362.2] Andrei Alexandrescu. "volatile - Multithreaded Programmer's Best Friend". Dr. Dobb's. 2008-02-01. <http://www.ddj.com/cpp/184403766>.
[R.362.3] Steven Devijver. "Thread-safe webapps using Spring". <http://www.javalobby.org/articles/thread-safe/index.jsp>.
[R.362.4] David Wheeler. "Prevent race conditions". 2007-10-04. <http://www.ibm.com/developerworks/library/l-sprace.html>.
[R.362.5] Matt Bishop. "Race Conditions, Files, and Security Flaws; or the Tortoise and the Hare Redux". September 1995. <http://www.cs.ucdavis.edu/research/tech-reports/1995/CSE-95-9.pdf>.
[R.362.6] David Wheeler. "Secure Programming for Linux and Unix HOWTO". 2003-03-03. <http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/avoid-race.html>.
[R.362.7] Blake Watts. "Discovering and Exploiting Named Pipe Security Flaws for Fun and Profit". April 2002. <http://www.blakewatts.com/namedpipepaper.html>.
[R.362.8] 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>.
[R.362.9] "Avoiding Race Conditions and Insecure File Operations". Apple Developer Connection. <http://developer.apple.com/documentation/Security/Conceptual/SecureCodingGuide/Articles/RaceConditions.html>.
[R.362.10] Johannes Ullrich. "Top 25 Series - Rank 25 - Race Conditions". SANS Software Security Institute. 2010-03-26. <http://blogs.sans.org/appsecstreetfighter/2010/03/26/top-25-series-rank-25-race-conditions/>.
[R.362.11] [REF-31] Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14. <https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/351.html>.
+ Maintenance Notes

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.

+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Contributions
Contribution DateContributorOrganizationSource
2010-04-30Martin SeborCisco Systems, Inc. Content
Provided Demonstrative Example
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITREInternal
updated Relationships
2008-11-24CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITREInternal
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Likelihood_of_Exploit, Maintenance_Notes, Observed_Examples, Potential_Mitigations, References, Relationships, Research_Gaps
2009-03-10CWE Content TeamMITREInternal
updated Demonstrative_Examples, Potential_Mitigations
2009-05-27CWE Content TeamMITREInternal
updated Relationships
2010-02-16CWE Content TeamMITREInternal
updated Detection_Factors, References, Relationships
2010-06-21CWE Content TeamMITREInternal
updated Common_Consequences, Demonstrative_Examples, Detection_Factors, Potential_Mitigations, References
2010-09-27CWE Content TeamMITREInternal
updated Observed_Examples, Potential_Mitigations, Relationships
2010-12-13CWE Content TeamMITREInternal
updated Applicable_Platforms, Demonstrative_Examples, Description, Name, Potential_Mitigations, Relationships
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITREInternal
updated Relationships
2011-09-13CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Potential_Mitigations, References, Relationships
2014-07-30CWE Content TeamMITREInternal
updated Detection_Factors, Relationships
2015-12-07CWE Content TeamMITREInternal
updated Relationships
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Race Conditions
2010-12-13Race Condition

CWE CATEGORY: Configuration

Category ID: 16
Status: Draft
+ Description

Description Summary

Weaknesses in this category are typically introduced during the configuration of the software.
+ Detection Methods

Automated Static Analysis - Binary / Bytecode

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

Cost effective for partial coverage:

  • Rebuild & Compare

Effectiveness: SOAR Partial

Dynamic Analysis with automated results interpretation

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

Highly cost effective:

  • Network Vulnerability Scanner – scan for already-known vulnerabilities for specific products

  • Host-based Vulnerability Scanners – Examine configuration for flaws, verifying that audit mechanisms work, ensure host configuration meets certain predefined criteria

  • Web Application Scanner

  • Web Services Scanner

  • Database Scanners

Cost effective for partial coverage:

  • Network Scanner - id (sub)systems & ports. (what systems are there, ports up? Should they be?)

Effectiveness: SOAR High

Dynamic Analysis with manual results interpretation

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

Highly cost effective:

  • Fuzz Tester

  • Framework-based Fuzzer

Effectiveness: SOAR High

Manual Static Analysis - Source Code

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

Highly cost effective:

  • Focused Manual Spotcheck - Focused manual analysis of source

  • Manual Source Code Review (not inspections)

Effectiveness: SOAR 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:

Highly cost effective:

  • Configuration Checker

Cost effective for partial coverage:

  • Origin Analysis

Effectiveness: SOAR High

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

Cost effective for partial coverage:

  • Attack Modeling

Effectiveness: SOAR High

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory933OWASP Top Ten 2013 Category A5 - Security Misconfiguration
Weaknesses in OWASP Top Ten (2013) (primary)928
ParentOfCategoryCategory4J2EE Environment Issues
Development Concepts (primary)699
ParentOfCategoryCategory519.NET Environment Issues
Development Concepts (primary)699
MemberOfViewView635Weaknesses Used by NVD
Weaknesses Used by NVD (primary)635
MemberOfViewView699Development Concepts
Development Concepts (primary)699
MemberOfViewView1003Weaknesses for Simplified Mapping of Published Vulnerabilities
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
WASC14Server Misconfiguration
WASC15Application Misconfiguration
+ Maintenance Notes

This entry is a Category, but various sources map to it anyway, e.g. by NVD, despite CWE guidance that Categories should not be mapped. In this case, there are no clear CWE Weaknesses that can be utilized. "Inappropriate Configuration" might be better described as a Weakness, so this entry might be converted to a Weakness in a later version. Further research is required, however, as a "configuration weakness" might be Primary to many other CWEs, i.e., it might be better described in terms of chaining relationships.

+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-09-08CWE Content TeamMITREInternal
updated Relationships
2010-02-16CWE Content TeamMITREInternal
updated Taxonomy_Mappings
2013-07-17CWE Content TeamMITREInternal
updated Relationships
2014-07-30CWE Content TeamMITREInternal
updated Detection_Factors
2015-12-07CWE Content TeamMITREInternal
updated Relationships
2017-01-19CWE Content TeamMITREInternal
updated Maintenance_Notes, Relationships

CWE CATEGORY: Credentials Management

Category ID: 255
Status: Draft
+ Description

Description Summary

Weaknesses in this category are related to the management of credentials.
+ Applicable Platforms

Languages

All

+ Detection Methods

Automated Static Analysis - Binary / Bytecode

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

Cost effective for partial coverage:

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

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

Effectiveness: SOAR Partial

Manual Static Analysis - Binary / 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

Manual Static Analysis - Source Code

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

Highly cost effective:

  • Focused Manual Spotcheck - Focused manual analysis of source

Cost effective for partial coverage:

  • Manual Source Code Review (not inspections)

Effectiveness: SOAR High

Automated Static Analysis - Source Code

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

Cost effective for partial coverage:

  • Source code Weakness Analyzer

  • Context-configured Source Code Weakness Analyzer

Effectiveness: SOAR Partial

Architecture / 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: SOAR High

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory254Security Features
Development Concepts (primary)699
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfCategoryCategory724OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management
Weaknesses in OWASP Top Ten (2004) (primary)711
ParentOfWeakness VariantWeakness Variant261Weak Cryptography for Passwords
Development Concepts (primary)699
ParentOfWeakness VariantWeakness Variant262Not Using Password Aging
Development Concepts (primary)699
ParentOfWeakness BaseWeakness Base263Password Aging with Long Expiration
Development Concepts (primary)699
ParentOfWeakness BaseWeakness Base521Weak Password Requirements
Development Concepts (primary)699
ParentOfWeakness BaseWeakness Base522Insufficiently Protected Credentials
Development Concepts (primary)699
ParentOfWeakness VariantWeakness Variant549Missing Password Field Masking
Development Concepts (primary)699
ParentOfWeakness VariantWeakness Variant620Unverified Password Change
Development Concepts699
ParentOfWeakness BaseWeakness Base640Weak Password Recovery Mechanism for Forgotten Password
Development Concepts (primary)699
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ParentOfWeakness BaseWeakness Base798Use of Hard-coded Credentials
Development Concepts (primary)699
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
MemberOfViewView635Weaknesses Used by NVD
Weaknesses Used by NVD (primary)635
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
OWASP Top Ten 2004A3CWE More SpecificBroken Authentication and Session Management
+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2010-02-16CWE Content TeamMITREInternal
updated Relationships
2014-07-30CWE Content TeamMITREInternal
updated Detection_Factors
2015-12-07CWE Content TeamMITREInternal
updated Relationships

CWE-352: Cross-Site Request Forgery (CSRF)

Compound Element ID: 352
Abstraction: Variant
Structure: Composite
Status: Draft
Presentation Filter:
+ Description

Description Summary

The web application does not, or can not, sufficiently verify whether a well-formed, valid, consistent request was intentionally provided by the user who submitted the request.

Extended Description

When a web server is designed to receive a request from a client without any mechanism for verifying that it was intentionally sent, then it might be possible for an attacker to trick a client into making an unintentional request to the web server which will be treated as an authentic request. This can be done via a URL, image load, XMLHttpRequest, etc. and can result in exposure of data or unintended code execution.

+ Alternate Terms
Session Riding
Cross Site Reference Forgery
XSRF
+ Time of Introduction
  • Architecture and Design
+ Applicable Platforms

Languages

Language-independent

Technology Classes

Web-Server

+ Common Consequences
ScopeEffect
Confidentiality
Integrity
Availability
Non-Repudiation
Access Control

Technical Impact: Gain privileges / assume identity; Bypass protection mechanism; Read application data; Modify application data; DoS: crash / exit / restart

The consequences will vary depending on the nature of the functionality that is vulnerable to CSRF. An attacker could effectively perform any operations as the victim. If the victim is an administrator or privileged user, the consequences may include obtaining complete control over the web application - deleting or stealing data, uninstalling the product, or using it to launch other attacks against all of the product's users. Because the attacker has the identity of the victim, the scope of CSRF is limited only by the victim's privileges.

+ Likelihood of Exploit

Medium to High

+ Detection Methods

Manual Analysis

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

Specifically, manual analysis can be useful for finding this weakness, and for minimizing false positives assuming an understanding of business logic. However, it might not achieve desired code coverage within limited time constraints. For black-box analysis, if credentials are not known for privileged accounts, then the most security-critical portions of the application may not receive sufficient attention.

Consider using OWASP CSRFTester to identify potential issues and aid in manual analysis.

Effectiveness: High

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

Automated Static Analysis

CSRF is currently difficult to detect reliably using automated techniques. This is because each application has its own implicit security policy that dictates which requests can be influenced by an outsider and automatically performed on behalf of a user, versus which requests require strong confidence that the user intends to make the request. For example, a keyword search of the public portion of a web site is typically expected to be encoded within a link that can be launched automatically when the user clicks on the link.

Effectiveness: Limited

Automated Static Analysis - Binary / Bytecode

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

Cost effective for partial coverage:

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

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

Effectiveness: SOAR Partial

Manual Static Analysis - Binary / Bytecode

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

Cost effective for partial coverage:

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

Effectiveness: SOAR Partial

Dynamic Analysis with automated results interpretation

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

Highly cost effective:

  • Web Application Scanner

Effectiveness: SOAR High

Dynamic Analysis with manual results interpretation

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

Highly cost effective:

  • Fuzz Tester

  • Framework-based Fuzzer

Effectiveness: SOAR High

Manual Static Analysis - Source Code

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

Cost effective for partial coverage:

  • Focused Manual Spotcheck - Focused manual analysis of source

  • Manual Source Code Review (not inspections)

Effectiveness: SOAR Partial

Automated Static Analysis - Source Code

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

Cost effective for partial coverage:

  • Source code Weakness Analyzer

  • Context-configured Source Code Weakness Analyzer

Effectiveness: SOAR Partial

Architecture / Design Review

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

Cost effective for partial coverage:

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

  • Formal Methods / Correct-By-Construction

Effectiveness: SOAR Partial

+ Demonstrative Examples

Example 1

This example PHP code attempts to secure the form submission process by validating that the user submitting the form has a valid session. A CSRF attack would not be prevented by this countermeasure because the attacker forges a request through the user's web browser in which a valid session already exists.

The following HTML is intended to allow a user to update a profile.

(Bad Code)
Example Language: HTML 
<form action="/url/profile.php" method="post">
<input type="text" name="firstname"/>
<input type="text" name="lastname"/>
<br/>
<input type="text" name="email"/>
<input type="submit" name="submit" value="Update"/>
</form>

profile.php contains the following code.

(Bad Code)
Example Language: PHP 
// initiate the session in order to validate sessions

session_start();

//if the session is registered to a valid user then allow update

if (! session_is_registered("username")) {

echo "invalid session detected!";

// Redirect user to login page
[...]

exit;
}

// The user session is valid, so process the request
// and update the information

update_profile();

function update_profile {
// read in the data from $POST and send an update
// to the database
SendUpdateToDatabase($_SESSION['username'], $_POST['email']);
[...]
echo "Your profile has been successfully updated.";
}

This code may look protected since it checks for a valid session. However, CSRF attacks can be staged from virtually any tag or HTML construct, including image tags, links, embed or object tags, or other attributes that load background images.

The attacker can then host code that will silently change the username and email address of any user that visits the page while remaining logged in to the target web application. The code might be an innocent-looking web page such as:

(Attack)
Example Language: HTML 
<SCRIPT>
function SendAttack () {
form.email = "attacker@example.com";
// send to profile.php
form.submit();
}
</SCRIPT>

<BODY onload="javascript:SendAttack();">

<form action="http://victim.example.com/profile.php" id="form" method="post">
<input type="hidden" name="firstname" value="Funny">
<input type="hidden" name="lastname" value="Joke">
<br/>
<input type="hidden" name="email">
</form>

Notice how the form contains hidden fields, so when it is loaded into the browser, the user will not notice it. Because SendAttack() is defined in the body's onload attribute, it will be automatically called when the victim loads the web page.

Assuming that the user is already logged in to victim.example.com, profile.php will see that a valid user session has been established, then update the email address to the attacker's own address. At this stage, the user's identity has been compromised, and messages sent through this profile could be sent to the attacker's address.

+ Observed Examples
ReferenceDescription
Add user accounts via a URL in an img tag
Add user accounts via a URL in an img tag
Arbitrary code execution by specifying the code in a crafted img tag or URL
Gain administrative privileges via a URL in an img tag
Delete a victim's information via a URL or an img tag
Change another user's settings via a URL or an img tag
Perform actions as administrator via a URL or an img tag
modify password for the administrator
CMS allows modification of configuration via CSRF attack against the administrator
web interface allows password changes or stopping a virtual machine via CSRF
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Libraries or Frameworks

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

For example, use anti-CSRF packages such as the OWASP CSRFGuard. [R.352.3]

Another example is the ESAPI Session Management control, which includes a component for CSRF. [R.352.9]

Phase: Implementation

Ensure that the application is free of cross-site scripting issues (CWE-79), because most CSRF defenses can be bypassed using attacker-controlled script.

Phase: Architecture and Design

Generate a unique nonce for each form, place the nonce into the form, and verify the nonce upon receipt of the form. Be sure that the nonce is not predictable (CWE-330). [R.352.5]

Note that this can be bypassed using XSS (CWE-79).

Phase: Architecture and Design

Identify especially dangerous operations. When the user performs a dangerous operation, send a separate confirmation request to ensure that the user intended to perform that operation.

Note that this can be bypassed using XSS (CWE-79).

Phase: Architecture and Design

Use the "double-submitted cookie" method as described by Felten and Zeller:

When a user visits a site, the site should generate a pseudorandom value and set it as a cookie on the user's machine. The site should require every form submission to include this value as a form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same.

Because of the same-origin policy, an attacker cannot read or modify the value stored in the cookie. To successfully submit a form on behalf of the user, the attacker would have to correctly guess the pseudorandom value. If the pseudorandom value is cryptographically strong, this will be prohibitively difficult.

This technique requires Javascript, so it may not work for browsers that have Javascript disabled. [R.352.4]

Note that this can probably be bypassed using XSS (CWE-79), or when using web technologies that enable the attacker to read raw headers from HTTP requests.

Phase: Architecture and Design

Do not use the GET method for any request that triggers a state change.

Phase: Implementation

Check the HTTP Referer header to see if the request originated from an expected page. This could break legitimate functionality, because users or proxies may have disabled sending the Referer for privacy reasons.

Note that this can be bypassed using XSS (CWE-79). An attacker could use XSS to generate a spoofed Referer, or to generate a malicious request from a page whose Referer would be allowed.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
RequiresWeakness BaseWeakness Base346Origin Validation Error
Research Concepts1000
RequiresWeakness ClassWeakness Class441Unintended Proxy or Intermediary ('Confused Deputy')
Research Concepts1000
RequiresWeakness BaseWeakness Base613Insufficient Session Expiration
Research Concepts1000
RequiresWeakness ClassWeakness Class642External Control of Critical State Data
Research Concepts1000
ChildOfWeakness ClassWeakness Class345Insufficient Verification of Data Authenticity
Development Concepts (primary)699
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfCategoryCategory442Web Problems
Development Concepts699
ChildOfCategoryCategory716OWASP Top Ten 2007 Category A5 - Cross Site Request Forgery (CSRF)
Weaknesses in OWASP Top Ten (2007) (primary)629
ChildOfCategoryCategory7512009 Top 25 - Insecure Interaction Between Components
Weaknesses in the 2009 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)750
ChildOfCategoryCategory8012010 Top 25 - Insecure Interaction Between Components
Weaknesses in the 2010 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)800
ChildOfCategoryCategory814OWASP Top Ten 2010 Category A5 - Cross-Site Request Forgery(CSRF)
Weaknesses in OWASP Top Ten (2010) (primary)809
ChildOfCategoryCategory8642011 Top 25 - Insecure Interaction Between Components
Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors (primary)900
ChildOfCategoryCategory936OWASP Top Ten 2013 Category A8 - Cross-Site Request Forgery (CSRF)
Weaknesses in OWASP Top Ten (2013) (primary)928
MemberOfViewView635Weaknesses Used by NVD
Weaknesses Used by NVD (primary)635
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
PeerOfWeakness BaseWeakness Base79Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Research Concepts1000
+ Relationship Notes

This can be resultant from XSS, although XSS is not necessarily required.

+ Research Gaps

This issue was under-reported in CVE until around 2008, when it began to gain prominence. It is likely to be present in most web applications.

+ Theoretical Notes

The CSRF topology is multi-channel:

1. Attacker (as outsider) to intermediary (as user). The interaction point is either an external or internal channel.

2. Intermediary (as user) to server (as victim). The activation point is an internal channel.

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERCross-Site Request Forgery (CSRF)
OWASP Top Ten 2007A5ExactCross Site Request Forgery (CSRF)
WASC9Cross-site Request Forgery
+ References
[R.352.1] [REF-17] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 2: Web-Server Related Vulnerabilities (XSS, XSRF, and Response Splitting)." Page 37. McGraw-Hill. 2010.
[R.352.2] Peter W. "Cross-Site Request Forgeries (Re: The Dangers of Allowing Users to Post Images)". Bugtraq. <http://marc.info/?l=bugtraq&m=99263135911884&w=2>.
[R.352.3] OWASP. "Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet". <http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet>.
[R.352.4] Edward W. Felten and William Zeller. "Cross-Site Request Forgeries: Exploitation and Prevention". 2008-10-18. <http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.147.1445>.
[R.352.5] Robert Auger. "CSRF - The Cross-Site Request Forgery (CSRF/XSRF) FAQ". <http://www.cgisecurity.com/articles/csrf-faq.shtml>.
[R.352.6] "Cross-site request forgery". Wikipedia. 2008-12-22. <http://en.wikipedia.org/wiki/Cross-site_request_forgery>.
[R.352.7] Jason Lam. "Top 25 Series - Rank 4 - Cross Site Request Forgery". SANS Software Security Institute. 2010-03-03. <http://software-security.sans.org/blog/2010/03/03/top-25-series-rank-4-cross-site-request-forgery>.
[R.352.8] Jeff Atwood. "Preventing CSRF and XSRF Attacks". 2008-10-14. <http://www.codinghorror.com/blog/2008/10/preventing-csrf-and-xsrf-attacks.html>.
[R.352.9] [REF-21] OWASP. "OWASP Enterprise Security API (ESAPI) Project". <http://www.owasp.org/index.php/ESAPI>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Alternate_Terms, Description, Relationships, Other_Notes, Relationship_Notes, Taxonomy_Mappings
2009-01-12CWE Content TeamMITREInternal
updated Applicable_Platforms, Description, Likelihood_of_Exploit, Observed_Examples, Other_Notes, Potential_Mitigations, References, Relationship_Notes, Relationships, Research_Gaps, Theoretical_Notes
2009-03-10CWE Content TeamMITREInternal
updated Potential_Mitigations
2009-05-20Tom StracenerExternal
Added demonstrative example for profile.
2009-05-27CWE Content TeamMITREInternal
updated Demonstrative_Examples, Related_Attack_Patterns
2009-12-28CWE Content TeamMITREInternal
updated Common_Consequences, Demonstrative_Examples, Detection_Factors, Likelihood_of_Exploit, Observed_Examples, Potential_Mitigations, Time_of_Introduction
2010-02-16CWE Content TeamMITREInternal
updated Applicable_Platforms, Detection_Factors, References, Relationships, Taxonomy_Mappings
2010-06-21CWE Content TeamMITREInternal
updated Common_Consequences, Detection_Factors, Potential_Mitigations, References, Relationships
2010-09-27CWE Content TeamMITREInternal
updated Potential_Mitigations
2011-03-29CWE Content TeamMITREInternal
updated Description
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2011-06-27CWE Content TeamMITREInternal
updated Relationships
2011-09-13CWE Content TeamMITREInternal
updated Potential_Mitigations, References
2012-05-11CWE Content TeamMITREInternal
updated Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2013-02-21CWE Content TeamMITREInternal
updated Relationships
2013-07-17CWE Content TeamMITREInternal
updated References, Relationships
2014-07-30CWE Content TeamMITREInternal
updated Detection_Factors
2015-12-07CWE Content TeamMITREInternal
updated Relationships

CWE CATEGORY: Cryptographic Issues

Category ID: 310
Status: Draft
+ Description

Description Summary

Weaknesses in this category are related to the use of cryptography.
+ Applicable Platforms

Languages

All

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory254Security Features
Development Concepts (primary)699
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfCategoryCategory934OWASP Top Ten 2013 Category A6 - Sensitive Data Exposure
Weaknesses in OWASP Top Ten (2013) (primary)928
ParentOfWeakness BaseWeakness Base295Improper Certificate Validation
Development Concepts (primary)699
ParentOfWeakness BaseWeakness Base311Missing Encryption of Sensitive Data
Development Concepts (primary)699
ParentOfCategoryCategory320Key Management Errors
Development Concepts (primary)699
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ParentOfWeakness BaseWeakness Base325Missing Required Cryptographic Step
Development Concepts (primary)699
ParentOfWeakness ClassWeakness Class326Inadequate Encryption Strength
Development Concepts (primary)699
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ParentOfWeakness BaseWeakness Base327Use of a Broken or Risky Cryptographic Algorithm
Development Concepts (primary)699
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ParentOfWeakness BaseWeakness Base328Reversible One-Way Hash
Development Concepts (primary)699
ParentOfWeakness VariantWeakness Variant329Not Using a Random IV with CBC Mode
Development Concepts (primary)699
ParentOfWeakness BaseWeakness Base347Improper Verification of Cryptographic Signature
Development Concepts (primary)699
ParentOfWeakness VariantWeakness Variant780Use of RSA Algorithm without OAEP
Development Concepts (primary)699
MemberOfViewView635Weaknesses Used by NVD
Weaknesses Used by NVD (primary)635
+ Relationship Notes

Some of these can be resultant.

+ Functional Areas
  • Cryptography
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERCryptographic Issues
+ References
[REF-11] M. Howard and D. LeBlanc. "Writing Secure Code". Chapter 8, "Cryptographic Foibles" Page 259. 2nd Edition. Microsoft. 2002.
+ Maintenance Notes

This category is incomplete and needs refinement, as there is good documentation of cryptographic flaws and related attacks.

Relationships between CWE-310, CWE-326, and CWE-327 and all their children need to be reviewed and reorganized.

+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-09-08CWE Content TeamMITREInternal
updated Maintenance_Notes, Relationships, Relationship_Notes, Taxonomy_Mappings
2009-07-27CWE Content TeamMITREInternal
updated Maintenance_Notes, Relationship_Notes, Relationships
2009-10-29CWE Content TeamMITREInternal
updated Relationships
2010-02-16CWE Content TeamMITREInternal
updated References
2013-07-17CWE Content TeamMITREInternal
updated Relationships
2014-02-18CWE Content TeamMITREInternal
updated Related_Attack_Patterns
2015-12-07CWE Content TeamMITREInternal
updated Relationships
2017-01-19CWE Content TeamMITREInternal
updated Relationships

CWE CATEGORY: Data Processing Errors

Category ID: 19
Status: Draft
+ Description

Description Summary

Weaknesses in this category are typically found in functionality that processes data.
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory18Source Code
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ParentOfWeakness ClassWeakness Class20Improper Input Validation
Development Concepts (primary)699
ParentOfWeakness ClassWeakness Class116Improper Encoding or Escaping of Output
Development Concepts (primary)699
ParentOfWeakness ClassWeakness Class118Incorrect Access of Indexable Resource ('Range Error')
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ParentOfWeakness ClassWeakness Class119Improper Restriction of Operations within the Bounds of a Memory Buffer
Development Concepts (primary)699
ParentOfCategoryCategory133String Errors
Development Concepts (primary)699
ParentOfCategoryCategory136Type Errors
Development Concepts (primary)699
ParentOfCategoryCategory137Representation Errors
Development Concepts (primary)699
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ParentOfWeakness ClassWeakness Class185Incorrect Regular Expression
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ParentOfCategoryCategory189Numeric Errors
Development Concepts (primary)699
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ParentOfCategoryCategory199Information Management Errors
Development Concepts (primary)699
ParentOfCategoryCategory461Data Structure Issues
Development Concepts (primary)699
ParentOfWeakness BaseWeakness Base471Modification of Assumed-Immutable Data (MAID)
Development Concepts (primary)699
MemberOfViewView699Development Concepts
Development Concepts (primary)699
+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-09-08CWE Content TeamMITREInternal
updated Relationships
2014-02-18CWE Content TeamMITREInternal
updated Related_Attack_Patterns
2015-12-07CWE Content TeamMITREInternal
updated Relationships
2017-01-19CWE Content TeamMITREInternal
updated Relationships
2017-05-03CWE Content TeamMITREInternal
updated Name, Relationships
Previous Entry Names
Change DatePrevious Entry Name
2017-05-03Data Handling

CWE-502: Deserialization of Untrusted Data

Weakness ID: 502
Abstraction: Variant
Status: Draft
Presentation Filter:
+ Description

Description Summary

The application deserializes untrusted data without sufficiently verifying that the resulting data will be valid.

Extended Description

It is often convenient to serialize objects for communication or to save them for later use. However, deserialized data or code can often be modified without using the provided accessor functions if it does not use cryptography to protect itself. Furthermore, any cryptography would still be client-side security -- which is a dangerous security assumption.

Data that is untrusted can not be trusted to be well-formed.

When developers place no restrictions on "gadget chains," or series of instances and method invocations that can self-execute during the deserialization process (i.e., before the object is returned to the caller), it is sometimes possible for attackers to leverage them to perform unauthorized actions, like generating a shell.

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

+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms

Languages

Java

Ruby

PHP

Python

Node.js

Language-independent

+ Common Consequences
ScopeEffect

Technical Impact: Varies by context

The consequences can vary widely, because it depends on which objects or methods are being deserialized, and how they are used.

Integrity

Technical Impact: Modify application data; Unexpected state

Attackers can modify unexpected objects or data that was assumed to be safe from modification.

Availability

Technical Impact: DoS: resource consumption (CPU)

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

Authorization
Other

Technical Impact: Other

Code could potentially make the assumption that information in the deserialized object is valid. Functions that make this dangerous assumption could be exploited.

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

Example 2

In Python, the Pickle library handles the serialization and deserialization processes. In this example derived from [R.502.7], 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.

+ Observed Examples
ReferenceDescription
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.
+ Potential Mitigations

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

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

Phase: Implementation

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"); }

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

Phase: Implementation

Avoid having unnecessary types or gadgets 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. Whitelist acceptable classes. Note: new gadgets are constantly being discovered, so this alone is not a sufficient mitigation.

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

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory858CERT Java Secure Coding Section 13 - Serialization (SER)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfWeakness ClassWeakness Class913Improper Control of Dynamically-Managed Code Resources
Development Concepts (primary)699
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfCategoryCategory994SFP Secondary Cluster: Tainted Input to Variable
Software Fault Pattern (SFP) Clusters (primary)888
PeerOfWeakness BaseWeakness Base915Improperly Controlled Modification of Dynamically-Determined Object Attributes
Research Concepts1000
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPDeserialization of untrusted data
CERT Java Secure CodingSER01-JDo not deviate from the proper signatures of serialization methods
CERT Java Secure CodingSER03-JDo not serialize unencrypted, sensitive data
CERT Java Secure CodingSER06-JMake defensive copies of private mutable components during deserialization
CERT Java Secure CodingSER08-JDo not use the default serialized form for implementation defined invariants
Software Fault PatternsSFP25Tainted input to variable
+ References
Matthias Kaiser. "Exploiting Deserialization Vulnerabilities in Java". 2015-10-28. <http://www.slideshare.net/codewhitesec/exploiting-deserialization-vulnerabilities-in-java-54707478>.
Sam Thomas. "PHP unserialization vulnerabilities: What are we missing?". 2015-08-27. <http://www.slideshare.net/_s_n_t/php-unserialization-vulnerabilities-what-are-we-missing>.
Gabriel Lawrence and Chris Frohoff. "Marshalling Pickles: How deserializing objects can ruin your day". 2015-01-28. <http://www.slideshare.net/frohoff1/appseccali-2015-marshalling-pickles>.
Heine Deelstra. "Unserializing user-supplied data, a bad idea". 2010-08-25. <http://heine.familiedeelstra.com/security/unserialize>.
Manish S. Saindane. "Black Hat EU 2010 - Attacking Java Serialized Communication". 2010-04-26. <http://www.slideshare.net/msaindane/black-hat-eu-2010-attacking-java-serialized-communication>.
Nadia Alramli. "Why Python Pickle is Insecure". 2009-09-09. <http://nadiana.com/python-pickle-insecure>.
Nelson Elhage. "Exploiting misuse of Python's "pickle"". 2011-03-20. <https://blog.nelhage.com/2011/03/exploiting-pickle/>.
Chris Frohoff. "Deserialize My Shorts: Or How I Learned to Start Worrying and Hate Java Object Deserialization". 2016-03-21. <https://www.slideshare.net/frohoff1/deserialize-my-shorts-or-how-i-learned-to-start-worrying-and-hate-java-object-deserialization>.
+ Maintenance Notes

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.

+ Content History
Submissions
Submission DateSubmitterOrganizationSource
CLASPExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Common_Consequences, Description, Relationships, Other_Notes, Taxonomy_Mappings
2009-10-29CWE Content TeamMITREInternal
updated Description, Other_Notes, Potential_Mitigations
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITREInternal
updated Demonstrative_Examples
2013-02-21CWE Content TeamMITREInternal
updated Alternate_Terms, Applicable_Platforms, Background_Details, Common_Consequences, Maintenance_Notes, Observed_Examples, Potential_Mitigations, References, Relationships
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITREInternal
updated Observed_Examples, References, Relationships
2017-05-03CWE Content TeamMITREInternal
updated Applicable_Platforms, Demonstrative_Examples, Description, Potential_Mitigations, References

CWE-369: Divide By Zero

Weakness ID: 369
Abstraction: Base
Status: Draft
Presentation Filter:
+ Description

Description Summary

The product divides a value by zero.

Extended Description

This weakness typically occurs when an unexpected value is provided to the product, or if an error occurs that is not properly detected. It frequently occurs in calculations involving physical dimensions such as size, length, width, and height.

+ Time of Introduction
  • Implementation
+ Common Consequences
ScopeEffect
Availability

Technical Impact: DoS: crash / exit / restart

A Divide by Zero results in a crash.

+ Likelihood of Exploit

Medium

+ Demonstrative Examples

Example 1

The following Java example contains a function to compute an average but does not validate that the input value used as the denominator is not zero. This will create an exception for attempting to divide by zero. If this error is not handled by Java exception handling, unexpected results can occur.

(Bad Code)
Example Language: Java 
public int computeAverageResponseTime (int totalTime, int numRequests) {
return totalTime / numRequests;
}

By validating the input value used as the denominator the following code will ensure that a divide by zero error will not cause unexpected results. The following Java code example will validate the input value, output an error message, and throw an exception.

(Good Code)
 
public int computeAverageResponseTime (int totalTime, int numRequests) throws ArithmeticException {
if (numRequests == 0) {
System.out.println("Division by zero attempted!");
throw ArithmeticException;
}
return totalTime / numRequests;
}

Example 2

The following C/C++ example contains a function that divides two numeric values without verifying that the input value used as the denominator is not zero. This will create an error for attempting to divide by zero, if this error is not caught by the error handling capabilities of the language, unexpected results can occur.

(Bad Code)
Example Languages: C and C++ 
double divide(double x, double y){
return x/y;
}

By validating the input value used as the denominator the following code will ensure that a divide by zero error will not cause unexpected results. If the method is called and a zero is passed as the second argument a DivideByZero error will be thrown and should be caught by the calling block with an output message indicating the error.

(Good Code)
 
const int DivideByZero = 10;
double divide(double x, double y){
if ( 0 == y ){
throw DivideByZero;
}
return x/y;
}
...
try{
divide(10, 0);
}
catch( int i ){
if(i==DivideByZero) {
cerr<<"Divide by zero error";
}
}

Example 3

The following C# example contains a function that divides two numeric values without verifying that the input value used as the denominator is not zero. This will create an error for attempting to divide by zero, if this error is not caught by the error handling capabilities of the language, unexpected results can occur.

(Bad Code)
Example Language: C# 
int Division(int x, int y){
return (x / y);
}

The method can be modified to raise, catch and handle the DivideByZeroException if the input value used as the denominator is zero.

(Good Code)
 
int SafeDivision(int x, int y){
try{
return (x / y);
}
catch (System.DivideByZeroException dbz){
System.Console.WriteLine("Division by zero attempted!");
return 0;
}
}

Example 3 References:

+ Observed Examples
ReferenceDescription
Invalid size value leads to divide by zero.
"Empty" content triggers divide by zero.
Height value of 0 triggers divide by zero.
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class682Incorrect Calculation
Development Concepts (primary)699
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfCategoryCategory730OWASP Top Ten 2004 Category A9 - Denial of Service
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory738CERT C Secure Coding Section 04 - Integers (INT)
Weaknesses Addressed by the CERT C Secure Coding Standard (primary)734
ChildOfCategoryCategory739CERT C Secure Coding Section 05 - Floating Point (FLP)
Weaknesses Addressed by the CERT C Secure Coding Standard734
ChildOfCategoryCategory848CERT Java Secure Coding Section 03 - Numeric Types and Operations (NUM)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory872CERT C++ Secure Coding Section 04 - Integers (INT)
Weaknesses Addressed by the CERT C++ Secure Coding Standard (primary)868
ChildOfCategoryCategory873CERT C++ Secure Coding Section 05 - Floating Point Arithmetic (FLP)
Weaknesses Addressed by the CERT C++ Secure Coding Standard868
ChildOfCategoryCategory998SFP Secondary Cluster: Glitch in Computation
Software Fault Pattern (SFP) Clusters (primary)888
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
OWASP Top Ten 2004A9CWE More SpecificDenial of Service
CERT C Secure CodingFLP03-CDetect and handle floating point errors
CERT C Secure CodingINT33-CEnsure that division and modulo operations do not result in divide-by-zero errors
CERT Java Secure CodingNUM02-JEnsure that division and modulo operations do not result in divide-by-zero errors
CERT C++ Secure CodingINT33-CPPEnsure that division and modulo operations do not result in divide-by-zero errors
CERT C++ Secure CodingFLP03-CPPDetect and handle floating point errors
Software Fault PatternsSFP1Glitch in computation
+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-07-01Sean EidemillerCigitalExternal
added/updated demonstrative examples
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Common_Consequences, Description, Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITREInternal
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITREInternal
updated Other_Notes
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-09-13CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITREInternal
updated Relationships

CWE-415: Double Free

Weakness ID: 415
Abstraction: Variant
Status: Draft
Presentation Filter:
+ Description

Description Summary

The product calls free() twice on the same memory address, potentially leading to modification of unexpected memory locations.

Extended Description

When a program calls free() twice with the same argument, the program's memory management data structures become corrupted. This corruption can cause the program to crash or, in some circumstances, cause two later calls to malloc() to return the same pointer. If malloc() returns the same value twice and the program later gives the attacker control over the data that is written into this doubly-allocated memory, the program becomes vulnerable to a buffer overflow attack.

+ Alternate Terms
Double-free
+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms

Languages

C

C++

+ Common Consequences
ScopeEffect
Integrity
Confidentiality
Availability

Technical Impact: Execute unauthorized code or commands

Doubly freeing memory may result in a write-what-where condition, allowing an attacker to execute arbitrary code.

+ Likelihood of Exploit

Low to Medium

+ Demonstrative Examples

Example 1

The following code shows a simple example of a double free vulnerability.

(Bad Code)
Example Language:
char* ptr = (char*)malloc (SIZE);
...
if (abrt) {
free(ptr);
}
...
free(ptr);

Double free vulnerabilities have two common (and sometimes overlapping) causes:

  • Error conditions and other exceptional circumstances

  • Confusion over which part of the program is responsible for freeing the memory

Although some double free vulnerabilities are not much more complicated than the previous example, most are spread out across hundreds of lines of code or even different files. Programmers seem particularly susceptible to freeing global variables more than once.

Example 2

While contrived, this code should be exploitable on Linux distributions which do not ship with heap-chunk check summing turned on.

(Bad Code)
Example Language:
#include <stdio.h>
#include <unistd.h>
#define BUFSIZE1 512
#define BUFSIZE2 ((BUFSIZE1/2) - 8)

int main(int argc, char **argv) {
char *buf1R1;
char *buf2R1;
char *buf1R2;
buf1R1 = (char *) malloc(BUFSIZE2);
buf2R1 = (char *) malloc(BUFSIZE2);
free(buf1R1);
free(buf2R1);
buf1R2 = (char *) malloc(BUFSIZE1);
strncpy(buf1R2, argv[1], BUFSIZE1-1);
free(buf2R1);
free(buf1R2);
}
+ Observed Examples
ReferenceDescription
Chain: Signal handler contains too much functionality (CWE-828), introducing a race condition that leads to a double free (CWE-415).
Double free resultant from certain error conditions.
Double free resultant from certain error conditions.
Double free resultant from certain error conditions.
Double free from invalid ASN.1 encoding.
Double free from malformed GIF.
Double free from malformed GIF.
Double free from malformed compressed data.
+ Potential Mitigations

Phase: Architecture and Design

Choose a language that provides automatic memory management.

Phase: Implementation

Ensure that each allocation is freed only once. After freeing a chunk, set the pointer to NULL to ensure the pointer cannot be freed again. In complicated error conditions, be sure that clean-up routines respect the state of allocation properly. If the language is object oriented, ensure that object destructors delete each chunk of memory only once.

Phase: Implementation

Use a static analysis tool to find double free instances.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class398Indicator of Poor Code Quality
Seven Pernicious Kingdoms (primary)700
ChildOfCategoryCategory399Resource Management Errors
Development Concepts (primary)699
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfCategoryCategory633Weaknesses that Affect Memory
Resource-specific Weaknesses (primary)631
ChildOfWeakness BaseWeakness Base666Operation on Resource in Wrong Phase of Lifetime
Research Concepts1000
ChildOfWeakness ClassWeakness Class675Duplicate Operations on Resource
Research Concepts1000
ChildOfCategoryCategory742CERT C Secure Coding Section 08 - Memory Management (MEM)
Weaknesses Addressed by the CERT C Secure Coding Standard (primary)734
ChildOfWeakness BaseWeakness Base825Expired Pointer Dereference
Research Concepts (primary)1000
ChildOfCategoryCategory876CERT C++ Secure Coding Section 08 - Memory Management (MEM)
Weaknesses Addressed by the CERT C++ Secure Coding Standard (primary)868
ChildOfCategoryCategory969SFP Secondary Cluster: Faulty Memory Release
Software Fault Pattern (SFP) Clusters (primary)888
PeerOfWeakness BaseWeakness Base123Write-what-where Condition
Research Concepts1000
PeerOfWeakness BaseWeakness Base416Use After Free
Development Concepts699
Research Concepts1000
MemberOfViewView630Weaknesses Examined by SAMATE
Weaknesses Examined by SAMATE (primary)630
CanFollowWeakness BaseWeakness Base364Signal Handler Race Condition
Research Concepts1000
+ Relationship Notes

This is usually resultant from another weakness, such as an unhandled error or race condition between threads. It could also be primary to weaknesses such as buffer overflows.

+ Affected Resources
  • Memory
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERDFREE - Double-Free Vulnerability
7 Pernicious KingdomsDouble Free
CLASPDoubly freeing memory
CERT C Secure CodingMEM00-CAllocate and free memory in the same module, at the same level of abstraction
CERT C Secure CodingMEM01-CStore a new value in pointers immediately after free()
CERT C Secure CodingMEM31-CFree dynamically allocated memory exactly once
CERT C++ Secure CodingMEM01-CPPStore a valid value in pointers immediately after deallocation
CERT C++ Secure CodingMEM31-CPPFree dynamically allocated memory exactly once
Software Fault PatternsSFP12Faulty Memory Release
+ White Box Definitions

A weakness where code path has:

1. start statement that relinquishes a dynamically allocated memory resource

2. end statement that relinquishes the dynamically allocated memory resource

+ References
[REF-17] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 8: C++ Catastrophes." Page 143. McGraw-Hill. 2010.
[REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 7, "Double Frees", Page 379.. 1st Edition. Addison Wesley. 2006.
+ Maintenance Notes

It could be argued that Double Free would be most appropriately located as a child of "Use after Free", but "Use" and "Release" are considered to be distinct operations within vulnerability theory, therefore this is more accurately "Release of a Resource after Expiration or Release", which doesn't exist yet.

+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Potential_Mitigations, Time_of_Introduction
2008-08-01KDM AnalyticsExternal
added/updated white box definitions
2008-09-08CWE Content TeamMITREInternal
updated Applicable_Platforms, Common_Consequences, Description, Maintenance_Notes, Relationships, Other_Notes, Relationship_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2009-05-27CWE Content TeamMITREInternal
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITREInternal
updated Other_Notes
2010-09-27CWE Content TeamMITREInternal
updated Relationships
2010-12-13CWE Content TeamMITREInternal
updated Observed_Examples, Relationships
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2011-09-13CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated References, Relationships
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2015-12-07CWE Content TeamMITREInternal
updated Relationships

CWE-172: Encoding Error

Weakness ID: 172
Abstraction: Class
Status: Draft
Presentation Filter:
+ Description

Description Summary

The software does not properly encode or decode the data, resulting in unexpected values.
+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

All

+ Common Consequences
ScopeEffect
Integrity

Technical Impact: Unexpected state

+ Potential Mitigations

Phase: Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist 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 (i.e., do not rely on a blacklist). A blacklist 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, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

Phase: Implementation

Strategy: Output Encoding

While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict whitelist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88).

Phase: 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 whitelist validation schemes by introducing dangerous inputs after they have been checked.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory171Cleansing, Canonicalization, and Comparison Errors
Development Concepts (primary)699
ChildOfWeakness ClassWeakness Class707Improper Enforcement of Message or Data Structure
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfCategoryCategory992SFP Secondary Cluster: Faulty Input Transformation
Software Fault Pattern (SFP) Clusters (primary)888
CanPrecedeWeakness ClassWeakness Class22Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Research Concepts1000
CanPrecedeWeakness BaseWeakness Base41Improper Resolution of Path Equivalence
Research Concepts1000
ParentOfWeakness VariantWeakness Variant173Improper Handling of Alternate Encoding
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant174Double Decoding of the Same Data
Development Concepts (primary)699
Research Concepts1000
ParentOfWeakness VariantWeakness Variant175Improper Handling of Mixed Encoding
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant176Improper Handling of Unicode Encoding
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant177Improper Handling of URL Encoding (Hex Encoding)
Development Concepts (primary)699
Research Concepts (primary)1000
+ Relationship Notes

Partially overlaps path traversal and equivalence weaknesses.

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVEREncoding Error
+ Maintenance Notes

This is more like a category than a weakness.

Many other types of encodings should be listed in this category.

+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Maintenance_Notes, Relationships, Relationship_Notes, Taxonomy_Mappings
2009-07-27CWE Content TeamMITREInternal
updated Potential_Mitigations
2010-12-13CWE Content TeamMITREInternal
updated Description
2011-03-29CWE Content TeamMITREInternal
updated Potential_Mitigations
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Description
2011-06-27CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2013-02-21CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-07-30CWE Content TeamMITREInternal
updated Relationships
2015-12-07CWE Content TeamMITREInternal
updated Relationships

CWE CATEGORY: Environment

Category ID: 2
Status: Draft
+ Description

Description Summary

Weaknesses in this category are typically introduced during unexpected environmental conditions.
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory933OWASP Top Ten 2013 Category A5 - Security Misconfiguration
Weaknesses in OWASP Top Ten (2013) (primary)928
ParentOfWeakness VariantWeakness Variant5J2EE Misconfiguration: Data Transmission Without Encryption
Seven Pernicious Kingdoms (primary)700
ParentOfWeakness VariantWeakness Variant6J2EE Misconfiguration: Insufficient Session-ID Length
Seven Pernicious Kingdoms (primary)700
ParentOfWeakness VariantWeakness Variant7J2EE Misconfiguration: Missing Custom Error Page
Seven Pernicious Kingdoms (primary)700
ParentOfWeakness VariantWeakness Variant8J2EE Misconfiguration: Entity Bean Declared Remote
Seven Pernicious Kingdoms (primary)700
ParentOfWeakness VariantWeakness Variant9J2EE Misconfiguration: Weak Access Permissions for EJB Methods
Seven Pernicious Kingdoms (primary)700
ParentOfWeakness VariantWeakness Variant11ASP.NET Misconfiguration: Creating Debug Binary
Seven Pernicious Kingdoms (primary)700
ParentOfWeakness VariantWeakness Variant12ASP.NET Misconfiguration: Missing Custom Error Page
Seven Pernicious Kingdoms (primary)700
ParentOfWeakness VariantWeakness Variant13ASP.NET Misconfiguration: Password in Configuration File
Seven Pernicious Kingdoms (primary)700
ParentOfWeakness BaseWeakness Base14Compiler Removal of Code to Clear Buffers
Seven Pernicious Kingdoms (primary)700
ParentOfWeakness ClassWeakness Class435Interaction Error
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
MemberOfViewView700Seven Pernicious Kingdoms
Seven Pernicious Kingdoms (primary)700
MemberOfViewView1003Weaknesses for Simplified Mapping of Published Vulnerabilities
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
+ Maintenance Notes

This entry is being considered for deprecation. It was originally used for organizing the Development View (CWE-699), but it introduced unnecessary complexity and depth to the resulting tree. It cannot be deprecated until after the CWE team has reviewed whether other CWE elements are appropriately capturing the "location" in which the weaknesses are introduced.

+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-09-08CWE Content TeamMITREInternal
updated Relationships
2013-07-17CWE Content TeamMITREInternal
updated Relationships
2015-12-07CWE Content TeamMITREInternal
updated Relationships
2017-01-19CWE Content TeamMITREInternal
updated Maintenance_Notes, Relationships

CWE CATEGORY: Error Handling

Category ID: 388
Status: Draft
+ Description

Description Summary

This category includes weaknesses that occur when an application does not properly handle errors that occur during processing.

Extended Description

An attacker may discover this type of error, as forcing these errors can occur with a variety of corrupt input.

+ Common Consequences
ScopeEffect
Integrity
Confidentiality

Technical Impact: Read application data; Modify files or directories

Generally, the consequences of improper error handling are the disclosure of the internal workings of the application to the attacker, providing details to use in further attacks. Web applications that do not properly handle error conditions frequently generate error messages such as stack traces, detailed diagnostics, and other inner details of the application.

+ Demonstrative Examples

Example 1

In the snippet below, an unchecked runtime exception thrown from within the try block may cause the container to display its default error page (which may contain a full stack trace, among other things).

(Bad Code)
Example Language: Java 
Public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
try {
...
}
catch (ApplicationSpecificException ase) {
logger.error("Caught: " + ase.toString());
}
}
+ Potential Mitigations

Use a standard exception handling mechanism to be sure that your application properly handles all types of processing errors. All error messages sent to the user should contain as little detail as necessary to explain what happened.

If the error was caused by unexpected and likely malicious input, it may be appropriate to send the user no error message other than a simple "could not process the request" response.

The details of the error and its cause should be recorded in a detailed diagnostic log for later analysis. Do not allow the application to throw errors up to the application container, generally the web application server.

Be sure that the container is properly configured to handle errors if you choose to let any errors propagate up to it.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory18Source Code
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfCategoryCategory728OWASP Top Ten 2004 Category A7 - Improper Error Handling
Weaknesses in OWASP Top Ten (2004) (primary)711
ParentOfCategoryCategory389Error Conditions, Return Values, Status Codes
Development Concepts (primary)699
ParentOfWeakness BaseWeakness Base391Unchecked Error Condition
Seven Pernicious Kingdoms (primary)700
ParentOfWeakness BaseWeakness Base395Use of NullPointerException Catch to Detect NULL Pointer Dereference
Seven Pernicious Kingdoms (primary)700
ParentOfWeakness BaseWeakness Base396Declaration of Catch for Generic Exception
Seven Pernicious Kingdoms (primary)700
ParentOfWeakness BaseWeakness Base397Declaration of Throws for Generic Exception
Seven Pernicious Kingdoms (primary)700
ParentOfWeakness BaseWeakness Base544Missing Standardized Error Handling Mechanism
Development Concepts (primary)699
ParentOfWeakness BaseWeakness Base600Uncaught Exception in Servlet
Development Concepts (primary)699
ParentOfWeakness VariantWeakness Variant617Reachable Assertion
Development Concepts699
ParentOfWeakness ClassWeakness Class636Not Failing Securely ('Failing Open')
Development Concepts699
ParentOfWeakness ClassWeakness Class703Improper Check or Handling of Exceptional Conditions
Development Concepts (primary)699
ParentOfWeakness ClassWeakness Class754Improper Check for Unusual or Exceptional Conditions
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ParentOfWeakness ClassWeakness Class756Missing Custom Error Page
Development Concepts (primary)699
MemberOfViewView699Development Concepts
Development Concepts (primary)699
MemberOfViewView700Seven Pernicious Kingdoms
Seven Pernicious Kingdoms (primary)700
PeerOfWeakness BaseWeakness Base619Dangling Database Cursor ('Cursor Injection')
Research Concepts1000
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsError Handling
OWASP Top Ten 2004A7CWE More SpecificImproper Error Handling
+ References
[REF-17] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 11: Failure to Handle Errors Correctly." Page 183. McGraw-Hill. 2010.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
7 Pernicious KingdomsExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Sean EidemillerCigitalExternal
added/updated demonstrative examples
2008-09-08CWE Content TeamMITREInternal
updated Common_Consequences, Description, Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITREInternal
updated Description
2009-03-10CWE Content TeamMITREInternal
updated Relationships
2009-10-29CWE Content TeamMITREInternal
updated Common_Consequences
2010-02-16CWE Content TeamMITREInternal
updated Relationships
2010-04-05CWE Content TeamMITREInternal
updated Related_Attack_Patterns
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated References
2015-12-07CWE Content TeamMITREInternal
updated Relationships
2017-01-19CWE Content TeamMITREInternal
updated Relationships

CWE-749: Exposed Dangerous Method or Function

Weakness ID: 749
Abstraction: Base
Status: Incomplete
Presentation Filter:
+ Description

Description Summary

The software 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:

1) The function/method was never intended to be exposed to outside actors.

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

+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms

Languages

Language-independent

+ Common Consequences
ScopeEffect
Integrity
Confidentiality
Availability
Access Control
Other

Technical Impact: Gain privileges / assume identity; Read application data; Modify application data; Execute unauthorized code or commands; 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.

+ Likelihood of Exploit

Low to Medium

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

+ Observed Examples
ReferenceDescription
arbitrary Java code execution via exposed method
security tool ActiveX control allows download or upload of files
+ Potential Mitigations

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

Phases: Architecture and Design; Implementation

Strategy: Identify and Reduce Attack Surface

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.

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class485Insufficient Encapsulation
Development Concepts (primary)699
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfWeakness ClassWeakness Class691Insufficient Control Flow Management
Research Concepts1000
ChildOfCategoryCategory8082010 Top 25 - Weaknesses On the Cusp
Weaknesses in the 2010 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)800
ChildOfCategoryCategory975SFP Secondary Cluster: Architecture
Software Fault Pattern (SFP) Clusters (primary)888
ParentOfWeakness BaseWeakness Base618Exposed Unsafe ActiveX Method
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant782Exposed IOCTL with Insufficient Access Control
Development Concepts (primary)699
Research Concepts (primary)1000
+ Research Gaps

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.

+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2008-11-24Internal CWE Team
Modifications
Modification DateModifierOrganizationSource
2009-01-12CWE Content TeamMITREInternal
updated Name
2009-07-27CWE Content TeamMITREInternal
updated Relationships
2009-12-28CWE Content TeamMITREInternal
updated Applicable_Platforms, Likelihood_of_Exploit
2010-02-16CWE Content TeamMITREInternal
updated Common_Consequences, Demonstrative_Examples, Potential_Mitigations, References, Related_Attack_Patterns, Relationships
2010-04-05CWE Content TeamMITREInternal
updated Demonstrative_Examples, Related_Attack_Patterns
2010-06-21CWE Content TeamMITREInternal
updated Common_Consequences
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Relationships
2014-02-18CWE Content TeamMITREInternal
updated Demonstrative_Examples
2014-07-30CWE Content TeamMITREInternal
updated Relationships
2015-12-07CWE Content TeamMITREInternal
updated Relationships
Previous Entry Names
Change DatePrevious Entry Name
2009-01-12Exposed Insecure Method or Function

CWE-668: Exposure of Resource to Wrong Sphere

Weakness ID: 668
Abstraction: Class
Status: Draft
Presentation Filter:
+ Description

Description Summary

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.

+ Time of Introduction
  • Architecture and Design
  • Implementation
  • Operation
+ Common Consequences
ScopeEffect
Confidentiality
Integrity
Other

Technical Impact: Read application data; Modify application data; Other

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory361Time and State
Development Concepts (primary)699
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfWeakness ClassWeakness Class664Improper Control of a Resource Through its Lifetime
Research Concepts (primary)1000
ChildOfCategoryCategory963SFP Secondary Cluster: Exposed Data
Software Fault Pattern (SFP) Clusters (primary)888
ParentOfWeakness VariantWeakness Variant8J2EE Misconfiguration: Entity Bean Declared Remote
Research Concepts (primary)1000
ParentOfWeakness ClassWeakness Class22Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Research Concepts1000
ParentOfWeakness ClassWeakness Class200Information Exposure
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ParentOfWeakness VariantWeakness Variant220Sensitive Data Under FTP Root
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ParentOfWeakness BaseWeakness Base374Passing Mutable Objects to an Untrusted Method
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base375Returning a Mutable Object to an Untrusted Caller
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base377Insecure Temporary File
Research Concepts (primary)1000
ParentOfWeakness ClassWeakness Class402Transmission of Private Resources into a New Sphere ('Resource Leak')
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base427Uncontrolled Search Path Element
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base428Unquoted Search Path or Element
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant491Public cloneable() Method Without Final ('Object Hijack')
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant492Use of Inner Class Containing Sensitive Data
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant493Critical Public Variable Without Final Modifier
Research Concepts (primary)1000
ParentOfWeakness ClassWeakness Class514Covert Channel
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base522Insufficiently Protected Credentials
Research Concepts1000
ParentOfWeakness BaseWeakness Base552Files or Directories Accessible to External Parties
Development Concepts (primary)699
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ParentOfWeakness VariantWeakness Variant582Array Declared Public, Final, and Static
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant583finalize() Method Declared Public
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant608Struts: Non-private Field in ActionForm Class
Research Concepts (primary)1000
ParentOfWeakness ClassWeakness Class642External Control of Critical State Data
Research Concepts (primary)1000
ParentOfWeakness ClassWeakness Class732Incorrect Permission Assignment for Critical Resource
Research Concepts1000
ParentOfWeakness VariantWeakness Variant766Critical Variable Declared Public
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant767Access to Critical Private Variable via Public Method
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant927Use of Implicit Intent for Sensitive Communication
Research Concepts1000
ParentOfWeakness VariantWeakness Variant942Overly Permissive Cross-domain Whitelist
Research Concepts1000
ParentOfWeakness VariantWeakness Variant1004Sensitive Cookie Without 'HttpOnly' Flag
Research Concepts1000
CanFollowWeakness VariantWeakness Variant219Sensitive Data Under Web Root
Research Concepts1000
CanFollowWeakness ClassWeakness Class441Unintended Proxy or Intermediary ('Confused Deputy')
Research Concepts1000
+ Theoretical Notes

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.

+ Relevant Properties
  • Accessibility
+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Other_Notes
2008-11-24CWE Content TeamMITREInternal
updated Relationships
2009-05-27CWE Content TeamMITREInternal
updated Relationships
2009-07-22
(Critical)
CWE Content TeamMITREInternal
Clarified description to include permissions.
2009-07-27CWE Content TeamMITREInternal
updated Description, Relationships
2009-10-29CWE Content TeamMITREInternal
updated Other_Notes, Theoretical_Notes
2009-12-28CWE Content TeamMITREInternal
updated Relationships
2010-09-27CWE Content TeamMITREInternal
updated Relationships
2011-03-29CWE Content TeamMITREInternal
updated Relationships
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Relationships
2013-02-21CWE Content TeamMITREInternal
updated Relationships
2013-07-17CWE Content TeamMITREInternal
updated Relationships
2014-06-23CWE Content TeamMITREInternal
updated Relationships
2014-07-30CWE Content TeamMITREInternal
updated Relationships
2015-12-07CWE Content TeamMITREInternal
updated Relationships
2017-01-19CWE Content TeamMITREInternal
updated Relationships

CWE-472: External Control of Assumed-Immutable Web Parameter

Weakness ID: 472
Abstraction: Base
Status: Draft
Presentation Filter:
+ Description

Description Summary

The web application does not sufficiently verify inputs that are assumed to be immutable but are actually externally controllable, such as hidden form fields.

Extended Description

If a web product does not properly protect assumed-immutable values from modification in hidden form fields, parameters, cookies, or URLs, this can lead to modification of critical data. Web applications often mistakenly make the assumption that data passed to the client in hidden fields or cookies is not susceptible to tampering. Improper validation of data that are user-controllable can lead to the application processing incorrect, and often malicious, input.

For example, custom cookies commonly store session data or persistent data across sessions. This kind of session data is normally involved in security related decisions on the server side, such as user authentication and access control. Thus, the cookies might contain sensitive data such as user credentials and privileges. This is a dangerous practice, as it can often lead to improper reliance on the value of the client-provided cookie by the server side application.

+ Alternate Terms
Assumed-Immutable Parameter Tampering
+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

All

+ Common Consequences
ScopeEffect
Integrity

Technical Impact: Modify application data

Without appropriate protection mechanisms, the client can easily tamper with cookies and similar web data. Reliance on the cookies without detailed validation can lead to problems such as SQL injection. If you use cookie values for security related decisions on the server side, manipulating the cookies might lead to violations of security policies such as authentication bypassing, user impersonation and privilege escalation. In addition, storing sensitive data in the cookie without appropriate protection can also lead to disclosure of sensitive user data, especially data stored in persistent cookies.

+ Demonstrative Examples

Example 1

Here, a web application uses the value of a hidden form field (accountID) without having done any input validation because it was assumed to be immutable.

(Bad Code)
Example Language: Java 
String accountID = request.getParameter("accountID");
User user = getUserFromID(Long.parseLong(accountID));

Example 2

Hidden fields should not be trusted as secure parameters. An attacker can intercept and alter hidden fields in a post to the server as easily as user input fields. An attacker can simply parse the HTML for the substring:

(Bad Code)
Example Language: HTML 
< input type "hidden"

or even just "hidden". Hidden field values displayed later in the session, such as on the following page, can open a site up to cross-site scripting attacks.

+ Observed Examples
ReferenceDescription
Forum product allows spoofed messages of other users via hidden form fields for name and e-mail address.
Shopping cart allows price modification via hidden form field.
Shopping cart allows price modification via hidden form field.
Shopping cart allows price modification via hidden form field.
Shopping cart allows price modification via hidden form field.
Shopping cart allows price modification via hidden form field.
Allows admin access by modifying value of form field.
Read messages by modifying message ID parameter.
Send email to arbitrary users by modifying email parameter.
Authentication bypass by setting a parameter.
Product does not check authorization for configuration change admin script, leading to password theft via modified e-mail address field.
Logic error leads to password disclosure.
Modification of message number parameter allows attackers to read other people's messages.
+ Potential Mitigations

Phase: Implementation

Strategy: Input Validation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist 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 (i.e., do not rely on a blacklist). A blacklist 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, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

Phase: 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 whitelist validation schemes by introducing dangerous inputs after they have been checked.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory371State Issues
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfWeakness BaseWeakness Base471Modification of Assumed-Immutable Data (MAID)
Development Concepts (primary)699
Research Concepts1000
ChildOfWeakness ClassWeakness Class642External Control of Critical State Data
Research Concepts (primary)1000
ChildOfCategoryCategory715OWASP Top Ten 2007 Category A4 - Insecure Direct Object Reference
Weaknesses in OWASP Top Ten (2007) (primary)629
ChildOfCategoryCategory722OWASP Top Ten 2004 Category A1 - Unvalidated Input
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory991SFP Secondary Cluster: Tainted Input to Environment
Software Fault Pattern (SFP) Clusters (primary)888
RequiredByCompound Element: CompositeCompound Element: Composite384Session Fixation
Research Concepts1000
CanFollowWeakness BaseWeakness Base656Reliance on Security Through Obscurity
Research Concepts1000
+ Relationship Notes

This is a primary weakness for many other weaknesses and functional consequences, including XSS, SQL injection, path disclosure, and file inclusion.

+ Theoretical Notes

This is a technology-specific MAID problem.

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERWeb Parameter Tampering
OWASP Top Ten 2007A4CWE More SpecificInsecure Direct Object Reference
OWASP Top Ten 2004A1CWE More SpecificUnvalidated Input
+ References
[REF-17] 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.
[REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 17, "Embedding State in HTML and URLs", Page 1032.. 1st Edition. Addison Wesley. 2006.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Sean EidemillerCigitalExternal
added/updated demonstrative examples
2008-07-01Eric DalciCigitalExternal
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Description, Relationships, Other_Notes, Taxonomy_Mappings
2009-01-12CWE Content TeamMITREInternal
updated Relationships
2009-07-27CWE Content TeamMITREInternal
updated Potential_Mitigations
2009-10-29CWE Content TeamMITREInternal
updated Common_Consequences, Demonstrative_Examples, Description, Other_Notes, Relationship_Notes, Theoretical_Notes
2010-04-05CWE Content TeamMITREInternal
updated Related_Attack_Patterns
2010-12-13CWE Content TeamMITREInternal
updated Description
2011-03-29CWE Content TeamMITREInternal
updated Potential_Mitigations
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2011-06-27CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Demonstrative_Examples, References, Relationships
2014-07-30CWE Content TeamMITREInternal
updated Relationships
2015-12-07CWE Content TeamMITREInternal
updated Relationships
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Web Parameter Tampering

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

Weakness ID: 610
Abstraction: Class
Status: Draft
Presentation Filter:
+ Description

Description Summary

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

Extended Description

+ Time of Introduction
  • Architecture and Design
+ Common Consequences
ScopeEffect
Confidentiality
Integrity

Technical Impact: Read application data; Modify application data

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory265Privilege / Sandbox Issues
Development Concepts (primary)699
ChildOfWeakness ClassWeakness Class664Improper Control of a Resource Through its Lifetime
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfCategoryCategory980SFP Secondary Cluster: Link in Resource Name Resolution
Software Fault Pattern (SFP) Clusters (primary)888
ParentOfWeakness BaseWeakness Base15External Control of System or Configuration Setting
Research Concepts1000
ParentOfWeakness ClassWeakness Class73External Control of File Name or Path
Research Concepts1000
ParentOfWeakness ClassWeakness Class441Unintended Proxy or Intermediary ('Confused Deputy')
Development Concepts (primary)699
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ParentOfWeakness BaseWeakness Base470Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')
Research Concepts1000
ParentOfWeakness VariantWeakness Variant601URL Redirection to Untrusted Site ('Open Redirect')
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant611Improper Restriction of XML External Entity Reference ('XXE')
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
PeerOfWeakness BaseWeakness Base386Symbolic Name not Mapping to Correct Object
Research Concepts1000
+ Relationship Notes

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 Notes

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 DateSubmitterOrganizationSource
Anonymous Tool Vendor (under NDA)Externally Mined
Modifications
Modification DateModifierOrganizationSource
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-10-29CWE Content TeamMITREInternal
updated Other_Notes, Relationship_Notes
2010-04-05CWE Content TeamMITREInternal
updated Related_Attack_Patterns
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Relationships
2013-02-21CWE Content TeamMITREInternal
updated Maintenance_Notes
2014-07-30CWE Content TeamMITREInternal
updated Relationships
2015-12-07CWE Content TeamMITREInternal
updated Relationships
2017-01-19CWE Content TeamMITREInternal
updated Relationships
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Externally Controlled Reference to an Internal Resource

CWE-538: File and Directory Information Exposure

Weakness ID: 538
Abstraction: Base
Status: Draft
Presentation Filter:
+ Description

Description Summary

The product stores sensitive information in files or directories that are accessible to actors outside of the intended control sphere.
+ Time of Introduction
  • Implementation
  • Operation
+ Applicable Platforms

Languages

All

+ Common Consequences
ScopeEffect
Confidentiality

Technical Impact: Read files or directories

+ Potential Mitigations

Phases: Architecture and Design; Operation; System Configuration

Do not expose file and directory information to the user.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class200Information Exposure
Development Concepts (primary)699
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfCategoryCategory815OWASP Top Ten 2010 Category A6 - Security Misconfiguration
Weaknesses in OWASP Top Ten (2010) (primary)809
ChildOfCategoryCategory963SFP Secondary Cluster: Exposed Data
Software Fault Pattern (SFP) Clusters (primary)888
ParentOfWeakness VariantWeakness Variant527Exposure of CVS Repository to an Unauthorized Control Sphere
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant528Exposure of Core Dump File to an Unauthorized Control Sphere
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant529Exposure of Access Control List Files to an Unauthorized Control Sphere
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant530Exposure of Backup File to an Unauthorized Control Sphere
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant532Information Exposure Through Log Files
Development Concepts (primary)699
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ParentOfWeakness VariantWeakness Variant539Information Exposure Through Persistent Cookies
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant540Information Exposure Through Source Code
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant548Information Exposure Through Directory Listing
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant651Information Exposure Through WSDL File
Development Concepts (primary)699
Research Concepts (primary)1000
+ References
[REF-17] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 12: Information Leakage." Page 191. McGraw-Hill. 2010.
+ Maintenance Notes

Depending on usage, this could be a weakness or a category. Further study of all its children is needed, and the entire sub-tree may need to be clarified. The current organization is based primarily on the exposure of sensitive information as a consequence, instead of as a primary weakness.

There is a close relationship with CWE-552, which is more focused on weaknesses. As a result, it may be more appropriate to convert CWE-538 to a category.

+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Type
2009-12-28CWE Content TeamMITREInternal
updated Description, Maintenance_Notes, Name
2010-09-09VeracodeExternal
Suggested OWASP Top Ten mapping
2010-09-27CWE Content TeamMITREInternal
updated Relationships
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated References, Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2013-02-21CWE Content TeamMITREInternal
updated Relationships
2014-07-30CWE Content TeamMITREInternal
updated Relationships
2015-12-07CWE Content TeamMITREInternal
updated Relationships
2017-05-03CWE Content TeamMITREInternal
updated Related_Attack_Patterns
Previous Entry Names
Change DatePrevious Entry Name
2009-12-28File and Directory Information Leaks

CWE CATEGORY: File Descriptor Exhaustion

Category ID: 769
Status: Incomplete
+ Description

Description Summary

The software can be influenced by an attacker to open more files than are supported by the system.

Extended Description

There are at least three distinct scenarios which can commonly lead to file descriptor exhaustion:

  • Lack of throttling for the number of open file descriptors

  • Losing all references to a file descriptor before reaching the shutdown stage

  • Not closing file descriptors after processing

+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Likelihood of Exploit

Low to Medium

+ Potential Mitigations

Phases: Implementation; Architecture and Design

If file I/O is being supported by an application for multiple users, balancing the resource allotment across the group may help to prevent exhaustion as well as differentiate malicious activity from an insufficient resource pool.

Phase: Implementation

Consider using the getrlimit() function included in the sys/resources library in order to determine how many files are currently allowed to be opened for the process.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness BaseWeakness Base400Uncontrolled Resource Consumption ('Resource Exhaustion')
Development Concepts (primary)699
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ParentOfWeakness VariantWeakness Variant773Missing Reference to Active File Descriptor or Handle
Development Concepts (primary)699
ParentOfWeakness VariantWeakness Variant774Allocation of File Descriptors or Handles Without Limits or Throttling
Development Concepts (primary)699
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ParentOfWeakness VariantWeakness Variant775Missing Release of File Descriptor or Handle after Effective Lifetime
Development Concepts (primary)699
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
+ References
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2009-05-08Internal CWE Team
Modifications
Modification DateModifierOrganizationSource
2010-04-05CWE Content TeamMITREInternal
updated Potential_Mitigations
2010-06-21CWE Content TeamMITREInternal
updated Description
2010-12-13CWE Content TeamMITREInternal
updated Description
2013-02-21CWE Content TeamMITREInternal
updated Maintenance_Notes
2015-12-07CWE Content TeamMITREInternal
updated Relationships

CWE-552: Files or Directories Accessible to External Parties

Weakness ID: 552
Abstraction: Base
Status: Draft
Presentation Filter:
+ Description

Description Summary

Files or directories are accessible in the environment that should not be.
+ Time of Introduction
  • Implementation
  • Operation
+ Common Consequences
ScopeEffect
Confidentiality
Integrity

Technical Impact: Read files or directories; Modify files or directories

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory632Weaknesses that Affect Files or Directories
Resource-specific Weaknesses (primary)631
ChildOfWeakness ClassWeakness Class668Exposure of Resource to Wrong Sphere
Development Concepts (primary)699
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfCategoryCategory731OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory743CERT C Secure Coding Section 09 - Input Output (FIO)
Weaknesses Addressed by the CERT C Secure Coding Standard (primary)734
ChildOfCategoryCategory815OWASP Top Ten 2010 Category A6 - Security Misconfiguration
Weaknesses in OWASP Top Ten (2010) (primary)809
ChildOfCategoryCategory877CERT C++ Secure Coding Section 09 - Input Output (FIO)
Weaknesses Addressed by the CERT C++ Secure Coding Standard (primary)868
ChildOfCategoryCategory963SFP Secondary Cluster: Exposed Data
Software Fault Pattern (SFP) Clusters (primary)888
ParentOfWeakness VariantWeakness Variant527Exposure of CVS Repository to an Unauthorized Control Sphere
Development Concepts699
Research Concepts1000
ParentOfWeakness VariantWeakness Variant528Exposure of Core Dump File to an Unauthorized Control Sphere
Development Concepts699
Research Concepts1000
ParentOfWeakness VariantWeakness Variant529Exposure of Access Control List Files to an Unauthorized Control Sphere
Development Concepts699
Research Concepts1000
ParentOfWeakness VariantWeakness Variant530Exposure of Backup File to an Unauthorized Control Sphere
Research Concepts1000
ParentOfWeakness VariantWeakness Variant532Information Exposure Through Log Files
Development Concepts699
Research Concepts1000
ParentOfWeakness VariantWeakness Variant540Information Exposure Through Source Code
Development Concepts699
Research Concepts1000
ParentOfWeakness VariantWeakness Variant548Information Exposure Through Directory Listing
Research Concepts1000
ParentOfWeakness VariantWeakness Variant553Command Shell in Externally Accessible Directory
Development Concepts (primary)699
Research Concepts (primary)1000
+ Affected Resources
  • File/Directory
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
OWASP Top Ten 2004A10CWE More SpecificInsecure Configuration Management
CERT C Secure CodingFIO15-CEnsure that file operations are performed in a secure directory
CERT C++ Secure CodingFIO15-CPPEnsure that file operations are performed in a secure directory
+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-08-15VeracodeExternal
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2008-11-24CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2009-07-27CWE Content TeamMITREInternal
updated Relationships
2010-09-09VeracodeExternal
Suggested OWASP Top Ten mapping
2010-09-27CWE Content TeamMITREInternal
updated Relationships
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2011-09-13CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Relationships
2014-07-30CWE Content TeamMITREInternal
updated Relationships
2015-12-07CWE Content TeamMITREInternal
updated Relationships
2017-01-19CWE Content TeamMITREInternal
updated Relationships
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Errant Files or Directories Accessible

CWE-284: Improper Access Control

Weakness ID: 284
Abstraction: Class
Status: Incomplete
Presentation Filter:
+ Description

Description Summary

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

Extended Description

Access control involves the use of several protection mechanisms such as authentication (proving the identity of an actor) authorization (ensuring that a given actor can access a resource), and accountability (tracking of activities that were performed). When any mechanism is not applied or otherwise fails, attackers can compromise the security of the software by gaining privileges, reading sensitive information, executing commands, evading detection, etc.

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

  • Specification: incorrect privileges, permissions, ownership, etc. are explicitly specified for either the user or the resource (for example, setting a password file to be world-writable, or giving administrator capabilities to a guest user). This action could be performed by the program or the administrator.

  • Enforcement: the mechanism contains errors that prevent it from properly enforcing the specified access control requirements (e.g., allowing the user to specify their own privileges, or allowing a syntactically-incorrect ACL to produce insecure settings). This problem occurs within the program itself, in that it does not actually enforce the intended security policy that the administrator specifies.

+ Alternate Terms
Authorization:

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

+ Time of Introduction
  • Architecture and Design
  • Implementation
  • Operation
+ Common Consequences
ScopeEffect
Other

Technical Impact: Varies by context

+ Potential Mitigations

Phases: Architecture and Design; Operation

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

Phase: Architecture and Design

Strategy: Separation of Privilege

Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.

Ensure that appropriate compartmentalization is built into the system design and that the compartmentalization serves to allow for and further reinforce privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide when it is appropriate to use and to drop system privileges.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory264Permissions, Privileges, and Access Controls
Development Concepts (primary)699
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfCategoryCategory632Weaknesses that Affect Files or Directories
Resource-specific Weaknesses (primary)631
ChildOfWeakness ClassWeakness Class664Improper Control of a Resource Through its Lifetime
Research Concepts1000
ChildOfWeakness ClassWeakness Class693Protection Mechanism Failure
Research Concepts (primary)1000
ChildOfCategoryCategory723OWASP Top Ten 2004 Category A2 - Broken Access Control
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory944SFP Secondary Cluster: Access Management
Software Fault Pattern (SFP) Clusters (primary)888
ParentOfWeakness BaseWeakness Base269Improper Privilege Management
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness ClassWeakness Class282Improper Ownership Management
Research Concepts (primary)1000
ParentOfWeakness ClassWeakness Class285Improper Authorization
Development Concepts (primary)699
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ParentOfWeakness ClassWeakness Class286Incorrect User Management
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness ClassWeakness Class287Improper Authentication
Development Concepts (primary)699
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ParentOfWeakness BaseWeakness Base346Origin Validation Error
Development Concepts699
Research Concepts1000
ParentOfWeakness VariantWeakness Variant782Exposed IOCTL with Insufficient Access Control
Development Concepts699
ParentOfWeakness ClassWeakness Class923Improper Restriction of Communication Channel to Intended Endpoints
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant942Overly Permissive Cross-domain Whitelist
Development Concepts (primary)699
Research Concepts (primary)1000
+ Affected Resources
  • File/Directory
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERAccess Control List (ACL) errors
WASC2Insufficient Authorization
+ References
[REF-11] M. Howard and D. LeBlanc. "Writing Secure Code". Chapter 6, "Determining Appropriate Access Control" Page 171. 2nd Edition. Microsoft. 2002.
[REF-17] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 17: Failure to Protect Stored Data." Page 253. McGraw-Hill. 2010.
+ Maintenance Notes

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

* Trusted group includes undesired entities (partially covered by CWE-286)

* Group can perform undesired actions

* ACL parse error does not fail closed

+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Alternate_Terms, Background_Details, Description, Maintenance_Notes, Name, Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITREInternal
updated Relationships
2009-03-10CWE Content TeamMITREInternal
updated Relationships
2009-07-27CWE Content TeamMITREInternal
updated Alternate_Terms, Relationships
2009-12-28CWE Content TeamMITREInternal
updated Potential_Mitigations
2010-02-16CWE Content TeamMITREInternal
updated References, Taxonomy_Mappings
2010-06-21CWE Content TeamMITREInternal
updated Potential_Mitigations
2011-03-24
(Critical)
CWE Content TeamMITREInternal
Changed name and description; clarified difference between "access control" and "authorization."
2011-03-29CWE Content TeamMITREInternal
updated Alternate_Terms, Background_Details, Description, Maintenance_Notes, Name, Relationships
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2011-06-27CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated References, Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-02-18CWE Content TeamMITREInternal
updated Related_Attack_Patterns, Relationships
2014-06-23CWE Content TeamMITREInternal
updated Relationships
2014-07-30CWE Content TeamMITREInternal
updated Relationships
2015-12-07CWE Content TeamMITREInternal
updated Relationships
Previous Entry Names
Change DatePrevious Entry Name
2008-09-09Access Control Issues
2011-03-29Access Control (Authorization) Issues

CWE-287: Improper Authentication

Weakness ID: 287
Abstraction: Class
Status: Draft
Presentation Filter:
+ Description

Description Summary

When an actor claims to have a given identity, the software does not prove or insufficiently proves that the claim is correct.
+ Alternate Terms
authentification:

An alternate term is "authentification", which appears to be most commonly used by people from non-English-speaking countries.

AuthC:

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

+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms

Languages

Language-independent

+ Common Consequences
ScopeEffect
Integrity
Confidentiality
Availability
Access Control

Technical Impact: Read application data; Gain privileges / assume identity; Execute unauthorized code or commands

This weakness can lead to the exposure of resources or functionality to unintended actors, possibly providing attackers with sensitive information or even execute arbitrary code.

+ Likelihood of Exploit

Medium to High

+ Detection Methods

Automated Static Analysis

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

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

Effectiveness: Limited

Manual Static Analysis

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.

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

Effectiveness: High

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

Manual Static Analysis - Binary / Bytecode

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

Cost effective for partial coverage:

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

Effectiveness: SOAR Partial

Dynamic Analysis with automated results interpretation

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

Cost effective for partial coverage:

  • Web Application Scanner

  • Web Services Scanner

  • Database Scanners

Effectiveness: SOAR Partial

Dynamic Analysis with manual results interpretation

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

Cost effective for partial coverage:

  • Fuzz Tester

  • Framework-based Fuzzer

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

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

Cost effective for partial coverage:

  • Manual Source Code Review (not inspections)

Effectiveness: SOAR Partial

Automated Static Analysis - Source Code

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

Cost effective for partial coverage:

  • Source code Weakness Analyzer

  • Context-configured Source Code Weakness Analyzer

Effectiveness: SOAR Partial

Automated Static Analysis

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

Cost effective for partial coverage:

  • Configuration Checker

Effectiveness: SOAR Partial

Architecture / Design Review

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

Highly cost effective:

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

  • Formal Methods / Correct-By-Construction

Effectiveness: SOAR High

+ Demonstrative Examples

Example 1

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

(Bad Code)
Example Language: Perl 
my $q = new CGI;

if ($q->cookie('loggedin') ne "true") {
if (! AuthenticateUser($q->param('username'), $q->param('password'))) {
ExitError("Error: you need to log in first");
}
else {
# Set loggedin and user cookies.
$q->cookie(
-name => 'loggedin',
-value => 'true'
);
$q->cookie(
-name => 'user',
-value => $q->param('username')
);
}
}

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

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

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

[body of request]

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

Example 2

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

Example 2 References:

Kim Zetter. "Weak Password Brings 'Happiness' to Twitter Hacker". 2009-01-09. <http://www.wired.com/threatlevel/2009/01/professed-twitt/>.
+ Observed Examples
ReferenceDescription
login script for guestbook allows bypassing authentication by setting a "login_ok" parameter to 1.
admin script allows authentication bypass by setting a cookie value to "LOGGEDIN".
VOIP product allows authentication bypass using 127.0.0.1 in the Host header.
product uses default "Allow" action, instead of default deny, leading to authentication bypass.
chain: redirect without exit (CWE-698) leads to resultant authentication bypass.
product does not restrict access to a listening port for a critical service, allowing authentication to be bypassed.
product does not properly implement a security-related configuration setting, allowing authentication bypass.
authentication routine returns "nil" instead of "false" in some situations, allowing authentication bypass using an invalid username.
authentication update script does not properly handle when admin does not select any authentication modules, allowing authentication bypass.
use of LDAP authentication with anonymous binds causes empty password to result in successful authentication
product authentication succeeds if user-provided MD5 hash matches the hash in its database; this can be subjected to replay attacks.
chain: product generates predictable MD5 hashes using a constant value combined with username, allowing authentication bypass.
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Libraries or Frameworks

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

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class284Improper Access Control
Development Concepts (primary)699
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfCategoryCategory718OWASP Top Ten 2007 Category A7 - Broken Authentication and Session Management
Weaknesses in OWASP Top Ten (2007) (primary)629
ChildOfCategoryCategory724OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory812OWASP Top Ten 2010 Category A3 - Broken Authentication and Session Management
Weaknesses in OWASP Top Ten (2010) (primary)809
ChildOfCategoryCategory930OWASP Top Ten 2013 Category A2 - Broken Authentication and Session Management
Weaknesses in OWASP Top Ten (2013) (primary)928
ChildOfCategoryCategory935OWASP Top Ten 2013 Category A7 - Missing Function Level Access Control
Weaknesses in OWASP Top Ten (2013)928
ChildOfCategoryCategory947SFP Secondary Cluster: Authentication Bypass
Software Fault Pattern (SFP) Clusters (primary)888
ParentOfWeakness VariantWeakness Variant261Weak Cryptography for Passwords
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant262Not Using Password Aging
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base263Password Aging with Long Expiration
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base288Authentication Bypass Using an Alternate Path or Channel
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant289Authentication Bypass by Alternate Name
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base290Authentication Bypass by Spoofing
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base294Authentication Bypass by Capture-replay
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant301Reflection Attack in an Authentication Protocol
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant302Authentication Bypass by Assumed-Immutable Data
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base303Incorrect Implementation of Authentication Algorithm
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base304Missing Critical Step in Authentication
Development Concepts (primary)699
ParentOfWeakness BaseWeakness Base305Authentication Bypass by Primary Weakness
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant306Missing Authentication for Critical Function
Development Concepts (primary)699
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ParentOfWeakness BaseWeakness Base307Improper Restriction of Excessive Authentication Attempts
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base308Use of Single-factor Authentication
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base309Use of Password System for Primary Authentication
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfCompound Element: CompositeCompound Element: Composite384Session Fixation
Development Concepts699
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ParentOfWeakness BaseWeakness Base521Weak Password Requirements
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base522Insufficiently Protected Credentials
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant593Authentication Bypass: OpenSSL CTX Object Modified after SSL Objects are Created
Development Concepts (primary)699
Research Concepts1000
ParentOfWeakness BaseWeakness Base603Use of Client-Side Authentication
Development Concepts (primary)699
Research Concepts1000
ParentOfWeakness VariantWeakness Variant620Unverified Password Change
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base640Weak Password Recovery Mechanism for Forgotten Password
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base645Overly Restrictive Account Lockout Mechanism
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base798Use of Hard-coded Credentials
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base804Guessable CAPTCHA
Development Concepts699
Research Concepts1000
ParentOfWeakness BaseWeakness Base836Use of Password Hash Instead of Password for Authentication
Development Concepts (primary)699
Research Concepts (primary)1000
MemberOfViewView635Weaknesses Used by NVD
Weaknesses Used by NVD (primary)635
CanFollowWeakness BaseWeakness Base613Insufficient Session Expiration
Development Concepts699
Research Concepts1000
+ Relationship Notes

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

+ Functional Areas
  • Authentication
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERAuthentication Error
OWASP Top Ten 2007A7CWE More SpecificBroken Authentication and Session Management
OWASP Top Ten 2004A3CWE More SpecificBroken Authentication and Session Management
WASC1Insufficient Authentication
+ References
OWASP. "Top 10 2007-Broken Authentication and Session Management". <http://www.owasp.org/index.php/Top_10_2007-A7>.
OWASP. "Guide to Authentication". <http://www.owasp.org/index.php/Guide_to_Authentication>.
[REF-11] M. Howard and D. LeBlanc. "Writing Secure Code". Chapter 4, "Authentication" Page 109. 2nd Edition. Microsoft. 2002.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-08-15VeracodeExternal
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITREInternal
updated Alternate_Terms, Common_Consequences, Relationships, Relationship_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITREInternal
updated Relationships
2009-01-12CWE Content TeamMITREInternal
updated Name
2009-05-27CWE Content TeamMITREInternal
updated Description, Related_Attack_Patterns
2009-07-27CWE Content TeamMITREInternal
updated Relationships
2009-10-29CWE Content TeamMITREInternal
updated Common_Consequences, Observed_Examples
2009-12-28CWE Content TeamMITREInternal
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Detection_Factors, Likelihood_of_Exploit, References
2010-02-16CWE Content TeamMITREInternal
updated Alternate_Terms, Detection_Factors, Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2010-06-21CWE Content TeamMITREInternal
updated Relationships
2011-03-29CWE Content TeamMITREInternal
updated Relationships
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Relationships
2013-07-17CWE Content TeamMITREInternal
updated Relationships
2014-02-18CWE Content TeamMITREInternal
updated Relationships
2014-06-23CWE Content TeamMITREInternal
updated Relationships
2014-07-30CWE Content TeamMITREInternal
updated Detection_Factors, Relationships
2015-12-07CWE Content TeamMITREInternal
updated Relationships
2017-01-19CWE Content TeamMITREInternal
updated Relationships
2017-05-03CWE Content TeamMITREInternal
updated Related_Attack_Patterns, Relationships
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Authentication Issues
2009-01-12Insufficient Authentication

CWE-285: Improper Authorization

Weakness ID: 285
Abstraction: Class
Status: Draft
Presentation Filter:
+ Description

Description Summary

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

Extended Description

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

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

+ Alternate Terms
AuthZ:

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

+ Time of Introduction
  • Architecture and Design
  • Implementation
  • Operation
+ Applicable Platforms

Languages

Language-independent

Technology Classes

Web-Server: (Often)

Database-Server: (Often)

+ Modes of Introduction

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

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

+ Common Consequences
ScopeEffect
Confidentiality

Technical Impact: Read application data; Read files or directories

An attacker could read sensitive data, either by reading the data directly from a data store that is not properly restricted, or by accessing insufficiently-protected, privileged functionality to read the data.

Integrity

Technical Impact: Modify application data; Modify files or directories

An attacker could modify sensitive data, either by writing the data directly to a data store that is not properly restricted, or by accessing insufficiently-protected, privileged functionality to write the data.

Access Control

Technical Impact: Gain privileges / assume identity

An attacker could gain privileges by modifying or reading critical data directly, or by accessing insufficiently-protected, privileged functionality.

+ Likelihood of Exploit

High

+ Detection Methods

Automated Static Analysis

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

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

Effectiveness: Limited

Automated Dynamic Analysis

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

Manual Analysis

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

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

Effectiveness: Moderate

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

Manual Static Analysis - Binary / Bytecode

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

Cost effective for partial coverage:

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

Effectiveness: SOAR Partial

Dynamic Analysis with automated results interpretation

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

Cost effective for partial coverage:

  • Web Application Scanner

  • Web Services Scanner

  • Database Scanners

Effectiveness: SOAR Partial

Dynamic Analysis with manual results interpretation

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

Cost effective for partial coverage:

  • Host Application Interface Scanner

  • Fuzz Tester

  • Framework-based Fuzzer

  • Forced Path Execution

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

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

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

Cost effective for partial coverage:

  • Focused Manual Spotcheck - Focused manual analysis of source

  • Manual Source Code Review (not inspections)

Effectiveness: SOAR Partial

Automated Static Analysis - Source Code

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

Cost effective for partial coverage:

  • Context-configured Source Code Weakness Analyzer

Effectiveness: SOAR Partial

Architecture / 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: SOAR High

+ Demonstrative Examples

Example 1

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

(Bad Code)
Example Language: PHP 
function runEmployeeQuery($dbName, $name){
mysql_select_db($dbName,$globalDbHandle) or die("Could not open Database".$dbName);
//Use a prepared statement to avoid CWE-89
$preparedStatement = $globalDbHandle->prepare('SELECT * FROM employees WHERE name = :name');
$preparedStatement->execute(array(':name' => $name));
return $preparedStatement->fetchAll();
}
/.../
$employeeRecord = runEmployeeQuery('EmployeeDB',$_GET['EmployeeName']);

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

Example 2

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

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

my $q = new CGI;
# For purposes of this example, assume that CWE-309 and
# CWE-523 do not apply.
if (! AuthenticateUser($q->param('username'), $q->param('password'))) {
ExitError("invalid username or password");
}

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

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

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

+ Observed Examples
ReferenceDescription
Web application does not restrict access to admin scripts, allowing authenticated users to reset administrative passwords.
Web application does not restrict access to admin scripts, allowing authenticated users to modify passwords of other users.
Web application stores database file under the web root with insufficient access control (CWE-219), allowing direct request.
Terminal server does not check authorization for guest access.
Database server does not use appropriate privileges for certain sensitive operations.
Gateway uses default "Allow" configuration for its authorization settings.
Chain: product does not properly interpret a configuration option for a system group, allowing users to gain privileges.
Chain: SNMP product does not properly parse a configuration option for which hosts are allowed to connect, allowing unauthorized IP addresses to connect.
System monitoring software allows users to bypass authorization by creating custom forms.
Chain: reliance on client-side security (CWE-602) allows attackers to bypass authorization using a custom client.
Chain: product does not properly handle wildcards in an authorization policy list, allowing unintended access.
Content management system does not check access permissions for private files, allowing others to view those files.
ACL-based protection mechanism treats negative access rights as if they are positive, allowing bypass of intended restrictions.
Product does not check the ACL of a page accessed using an "include" directive, allowing attackers to read unauthorized files.
Default ACL list for a DNS server does not set certain ACLs, allowing unauthorized DNS queries.
Product relies on the X-Forwarded-For HTTP header for authorization, allowing unintended access by spoofing the header.
OS kernel does not check for a certain privilege before setting ACLs for files.
Chain: file-system code performs an incorrect comparison (CWE-697), preventing default ACLs from being properly applied.
Chain: product does not properly check the result of a reverse DNS lookup because of operator precedence (CWE-783), allowing bypass of DNS-based access restrictions.
+ Potential Mitigations

Phase: Architecture and Design

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

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

Phase: Architecture and Design

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

Phase: Architecture and Design

Strategy: Libraries or Frameworks

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

For example, consider using authorization frameworks such as the JAAS Authorization Framework [R.285.5] and the OWASP ESAPI Access Control feature [R.285.4].

Phase: Architecture and Design

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

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

Phases: System Configuration; Installation

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

+ Background Details

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

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory254Security Features
Seven Pernicious Kingdoms (primary)700
ChildOfWeakness ClassWeakness Class284Improper Access Control
Development Concepts (primary)699
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfCategoryCategory721OWASP Top Ten 2007 Category A10 - Failure to Restrict URL Access
Weaknesses in OWASP Top Ten (2007) (primary)629
ChildOfCategoryCategory723OWASP Top Ten 2004 Category A2 - Broken Access Control
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory7532009 Top 25 - Porous Defenses
Weaknesses in the 2009 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)750
ChildOfCategoryCategory8032010 Top 25 - Porous Defenses
Weaknesses in the 2010 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)800
ChildOfCategoryCategory817OWASP Top Ten 2010 Category A8 - Failure to Restrict URL Access
Weaknesses in OWASP Top Ten (2010) (primary)809
ChildOfCategoryCategory840Business Logic Errors
Development Concepts699
ChildOfCategoryCategory935OWASP Top Ten 2013 Category A7 - Missing Function Level Access Control
Weaknesses in OWASP Top Ten (2013) (primary)928
ChildOfCategoryCategory945SFP Secondary Cluster: Insecure Resource Access
Software Fault Pattern (SFP) Clusters (primary)888
ParentOfWeakness VariantWeakness Variant219Sensitive Data Under Web Root
Research Concepts (primary)1000
ParentOfWeakness ClassWeakness Class732Incorrect Permission Assignment for Critical Resource
Research Concepts (primary)1000
ParentOfWeakness ClassWeakness Class862Missing Authorization
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness ClassWeakness Class863Incorrect Authorization
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant926Improper Export of Android Application Components
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant927Use of Implicit Intent for Sensitive Communication
Development Concepts (primary)699
Research Concepts (primary)1000
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsMissing Access Control
OWASP Top Ten 2007A10CWE More SpecificFailure to Restrict URL Access
OWASP Top Ten 2004A2CWE More SpecificBroken Access Control
Software Fault PatternsSFP35Insecure resource access
+ References
[R.285.1] NIST. "Role Based Access Control and Role Based Security". <http://csrc.nist.gov/groups/SNS/rbac/>.
[R.285.2] [REF-11] M. Howard and D. LeBlanc. "Writing Secure Code". Chapter 4, "Authorization" Page 114; Chapter 6, "Determining Appropriate Access Control" Page 171. 2nd Edition. Microsoft. 2002.
[R.285.3] Frank Kim. "Top 25 Series - Rank 5 - Improper Access Control (Authorization)". SANS Software Security Institute. 2010-03-04. <http://blogs.sans.org/appsecstreetfighter/2010/03/04/top-25-series-rank-5-improper-access-control-authorization/>.
[R.285.4] [REF-21] OWASP. "OWASP Enterprise Security API (ESAPI) Project". <http://www.owasp.org/index.php/ESAPI>.
[R.285.5] [REF-23] Rahul Bhattacharjee. "Authentication using JAAS". <http://www.javaranch.com/journal/2008/04/authentication-using-JAAS.html>.
[R.285.6] [REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 2, "Common Vulnerabilities of Authorization", Page 39.. 1st Edition. Addison Wesley. 2006.
[R.285.7] [REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 11, "ACL Inheritance", Page 649.. 1st Edition. Addison Wesley. 2006.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
7 Pernicious KingdomsExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-08-15VeracodeExternal
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-01-12CWE Content TeamMITREInternal
updated Common_Consequences, Description, Likelihood_of_Exploit, Name, Other_Notes, Potential_Mitigations, References, Relationships
2009-03-10CWE Content TeamMITREInternal
updated Potential_Mitigations
2009-05-27CWE Content TeamMITREInternal
updated Description, Related_Attack_Patterns
2009-07-27CWE Content TeamMITREInternal
updated Relationships
2009-10-29CWE Content TeamMITREInternal
updated Type
2009-12-28CWE Content TeamMITREInternal
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Detection_Factors, Modes_of_Introduction, Observed_Examples, Relationships
2010-02-16CWE Content TeamMITREInternal
updated Alternate_Terms, Detection_Factors, Potential_Mitigations, References, Relationships
2010-04-05CWE Content TeamMITREInternal
updated Potential_Mitigations
2010-06-21CWE Content TeamMITREInternal
updated Common_Consequences, References, Relationships
2010-09-27CWE Content TeamMITREInternal
updated Description
2011-03-24
(Critical)
CWE Content TeamMITREInternal
Changed name and description; clarified difference between "access control" and "authorization."
2011-03-29CWE Content TeamMITREInternal
updated Background_Details, Demonstrative_Examples, Description, Name, Relationships
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Observed_Examples, Relationships
2012-05-11CWE Content TeamMITREInternal
updated Demonstrative_Examples, Potential_Mitigations, References, Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2013-07-17CWE Content TeamMITREInternal
updated Relationships
2014-07-30CWE Content TeamMITREInternal