Home > CWE List > VIEW SLICE: CWE-1003: Weaknesses for Simplified Mapping of Published Vulnerabilities (4.15) |
|
CWE VIEW: Weaknesses for Simplified Mapping of Published Vulnerabilities
CWE entries in this view (graph) may be used to categorize potential weaknesses within sources that handle public, third-party vulnerability information, such as the National Vulnerability Database (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 for humans to use. This view uses a shallow hierarchy of two levels in order to simplify the complex navigation of the entire CWE corpus. The following graph shows the tree-like relationships between weaknesses that exist at different levels of abstraction. At the highest level, categories and pillars exist to group weaknesses. Categories (which are not technically weaknesses) are special CWE entries used to group weaknesses that share a common characteristic. Pillars are weaknesses that are described in the most abstract fashion. Below these top-level entries are weaknesses are varying levels of abstraction. Classes are still very abstract, typically independent of any specific language or technology. Base level weaknesses are used to present a more specific type of weakness. A variant is a weakness that is described at a very low level of detail, typically limited to a specific language or technology. A chain is a set of weaknesses that must be reachable consecutively in order to produce an exploitable vulnerability. While a composite is a set of weaknesses that must all be present simultaneously in order to produce an exploitable vulnerability. Show Details:
1003 - Weaknesses for Simplified Mapping of Published Vulnerabilities
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Improper Input Validation - (20) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 20 (Improper Input Validation) The product receives input or data, but it does
not validate or incorrectly validates that the input has the
properties that are required to process the data safely and
correctly. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Validation of Specified Quantity in Input - (1284) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 20 (Improper Input Validation) > 1284 (Improper Validation of Specified Quantity in Input) The product receives input that is expected to specify a quantity (such as size or length), but it does not validate or incorrectly validates that the quantity has the required properties. Variant - a weakness
that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.Improper Validation of Array Index - (129) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 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 Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') - (74) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 74 (Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')) The product 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. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Neutralization of Formula Elements in a CSV File - (1236) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 74 (Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')) > 1236 (Improper Neutralization of Formula Elements in a CSV File) The product saves user-provided information into a Comma-Separated Value (CSV) file, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as a command when the file is opened by a spreadsheet product.CSV InjectionFormula InjectionExcel Macro Injection Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Improper Neutralization of Special Elements used in a Command ('Command Injection') - (77) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 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 product 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.Command injection Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') - (78) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 74 (Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')) > 78 (Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')) The product 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 metacharactersOS Command Injection Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') - (79) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 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 product 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.XSSHTML InjectionCSS Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Neutralization of Argument Delimiters in a Command ('Argument Injection') - (88) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 74 (Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')) > 88 (Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')) The product constructs a string for a command to be executed by a separate component
in another control sphere, but it does not properly delimit the
intended arguments, options, or switches within that command string. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') - (89) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 74 (Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')) > 89 (Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')) The product 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. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data.SQL injectionSQLi Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.XML Injection (aka Blind XPath Injection) - (91) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 74 (Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')) > 91 (XML Injection (aka Blind XPath Injection)) The product 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. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection') - (917) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 74 (Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')) > 917 (Improper Neutralization of Special Elements used in an Expression Language Statement ('Expression Language Injection')) The product constructs all or part of an expression language (EL) statement in a framework such as a Java Server Page (JSP) using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended EL statement before it is executed.EL Injection Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Control of Generation of Code ('Code Injection') - (94) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 74 (Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')) > 94 (Improper Control of Generation of Code ('Code Injection')) The product 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. Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Improper Encoding or Escaping of Output - (116) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 116 (Improper Encoding or Escaping of Output) The product 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 Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Inappropriate Encoding for Output Context - (838) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 116 (Improper Encoding or Escaping of Output) > 838 (Inappropriate Encoding for Output Context) The product uses or specifies an encoding when generating output to a downstream component, but the specified encoding is not the same as the encoding that is expected by the downstream component. Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Improper Restriction of Operations within the Bounds of a Memory Buffer - (119) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.Buffer Overflowbuffer overrunmemory safety Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') - (120) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) > 120 (Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')) The product copies an input buffer to an output buffer without verifying that the size of the input buffer is less than the size of the output buffer, leading to a buffer overflow.Classic Buffer OverflowUnbounded Transfer Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Out-of-bounds Read - (125) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) > 125 (Out-of-bounds Read) The product reads data past the end, or before the beginning, of the intended buffer.OOB read Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Out-of-bounds Write - (787) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) > 787 (Out-of-bounds Write) The product writes data past the end, or before the beginning, of the intended buffer.Memory Corruption Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Access of Uninitialized Pointer - (824) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) > 824 (Access of Uninitialized Pointer) The product accesses or uses a pointer that has not been initialized. Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Exposure of Sensitive Information to an Unauthorized Actor - (200) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 200 (Exposure of Sensitive Information to an Unauthorized Actor) The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.Information DisclosureInformation Leak Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Observable Discrepancy - (203) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 200 (Exposure of Sensitive Information to an Unauthorized Actor) > 203 (Observable Discrepancy) The product behaves differently or sends different responses under different circumstances in a way that is observable to an unauthorized actor, which exposes security-relevant information about the state of the product, such as whether a particular operation was successful or not.Side Channel Attack Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Generation of Error Message Containing Sensitive Information - (209) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 200 (Exposure of Sensitive Information to an Unauthorized Actor) > 209 (Generation of Error Message Containing Sensitive Information) The product generates an error message that includes sensitive information about its environment, users, or associated data. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Insertion of Sensitive Information into Log File - (532) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 200 (Exposure of Sensitive Information to an Unauthorized Actor) > 532 (Insertion of Sensitive Information into Log File) Information written to log files can be of a sensitive nature and give valuable guidance to an attacker or expose sensitive user information. Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Improper Privilege Management - (269) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 269 (Improper Privilege Management) The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor. Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Improper Authentication - (287) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 287 (Improper Authentication) When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.authentificationAuthNAuthC Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Authentication Bypass by Spoofing - (290) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 287 (Improper Authentication) > 290 (Authentication Bypass by Spoofing) This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Authentication Bypass by Capture-replay - (294) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 287 (Improper Authentication) > 294 (Authentication Bypass by Capture-replay) A capture-replay flaw exists when the design of the product makes it possible for a malicious user to sniff network traffic and bypass authentication by replaying it to the server in question to the same effect as the original message (or with minor changes). Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Certificate Validation - (295) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 287 (Improper Authentication) > 295 (Improper Certificate Validation) The product does not validate, or incorrectly validates, a certificate. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Missing Authentication for Critical Function - (306) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 287 (Improper Authentication) > 306 (Missing Authentication for Critical Function) The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Restriction of Excessive Authentication Attempts - (307) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 287 (Improper Authentication) > 307 (Improper Restriction of Excessive Authentication Attempts) The product does not implement sufficient measures to prevent multiple failed authentication attempts within a short time frame, making it more susceptible to brute force attacks. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Weak Password Requirements - (521) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 287 (Improper Authentication) > 521 (Weak Password Requirements) The product does not require that users should have strong passwords, which makes it easier for attackers to compromise user accounts. Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Insufficiently Protected Credentials - (522) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 287 (Improper Authentication) > 522 (Insufficiently Protected Credentials) The product transmits or stores authentication credentials, but it uses an insecure method that is susceptible to unauthorized interception and/or retrieval. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Weak Password Recovery Mechanism for Forgotten Password - (640) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 287 (Improper Authentication) > 640 (Weak Password Recovery Mechanism for Forgotten Password) The product contains a mechanism for users to recover or change their passwords without knowing the original password, but the mechanism is weak. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Use of Hard-coded Credentials - (798) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 287 (Improper Authentication) > 798 (Use of Hard-coded Credentials) The product contains hard-coded credentials, such as a password or cryptographic key. Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Missing Encryption of Sensitive Data - (311) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 311 (Missing Encryption of Sensitive Data) The product does not encrypt sensitive or critical information before storage or transmission. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Cleartext Storage of Sensitive Information - (312) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 311 (Missing Encryption of Sensitive Data) > 312 (Cleartext Storage of Sensitive Information) The product stores sensitive information in cleartext within a resource that might be accessible to another control sphere. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Cleartext Transmission of Sensitive Information - (319) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 311 (Missing Encryption of Sensitive Data) > 319 (Cleartext Transmission of Sensitive Information) The product transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors. Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Inadequate Encryption Strength - (326) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 326 (Inadequate Encryption Strength) The product stores or transmits sensitive data using an encryption scheme that is theoretically sound, but is not strong enough for the level of protection required. Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Use of a Broken or Risky Cryptographic Algorithm - (327) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 327 (Use of a Broken or Risky Cryptographic Algorithm) The product uses a broken or risky cryptographic algorithm or protocol. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Use of Password Hash With Insufficient Computational Effort - (916) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 327 (Use of a Broken or Risky Cryptographic Algorithm) > 916 (Use of Password Hash With Insufficient Computational Effort) The product generates a hash for a password, but it uses a scheme that does not provide a sufficient level of computational effort that would make password cracking attacks infeasible or expensive. Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Use of Insufficiently Random Values - (330) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 330 (Use of Insufficiently Random Values) The product uses insufficiently random numbers or values in a security context that depends on unpredictable numbers. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Insufficient Entropy - (331) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 330 (Use of Insufficiently Random Values) > 331 (Insufficient Entropy) The product uses an algorithm or scheme that produces insufficient entropy, leaving patterns or clusters of values that are more likely to occur than others. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Incorrect Usage of Seeds in Pseudo-Random Number Generator (PRNG) - (335) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 330 (Use of Insufficiently Random Values) > 335 (Incorrect Usage of Seeds in Pseudo-Random Number Generator (PRNG)) The product uses a Pseudo-Random Number Generator (PRNG) but does not correctly manage seeds. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG) - (338) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 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's algorithm is not cryptographically strong. Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Insufficient Verification of Data Authenticity - (345) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 345 (Insufficient Verification of Data Authenticity) The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data. Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Origin Validation Error - (346) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 345 (Insufficient Verification of Data Authenticity) > 346 (Origin Validation Error) The product does not properly verify that the source of data or communication is valid. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Verification of Cryptographic Signature - (347) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 345 (Insufficient Verification of Data Authenticity) > 347 (Improper Verification of Cryptographic Signature) The product does not verify, or incorrectly verifies, the cryptographic signature for data. Composite - a Compound Element that consists of two or more distinct weaknesses, in which all weaknesses must be present at the same time in order for a potential vulnerability to arise. Removing any of the weaknesses eliminates or sharply reduces the risk. One weakness, X, can be "broken down" into component weaknesses Y and Z. There can be cases in which one weakness might not be essential to a composite, but changes the nature of the composite when it becomes a vulnerability.Cross-Site Request Forgery (CSRF) - (352) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 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 Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Validation of Integrity Check Value - (354) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 345 (Insufficient Verification of Data Authenticity) > 354 (Improper Validation of Integrity Check Value) The product does not validate or incorrectly validates the integrity check values or "checksums" of a message. This may prevent it from detecting if the data has been modified or corrupted in transmission. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Enforcement of Message Integrity During Transmission in a Communication Channel - (924) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 345 (Insufficient Verification of Data Authenticity) > 924 (Improper Enforcement of Message Integrity During Transmission in a Communication Channel) The product establishes a communication channel with an endpoint and receives a message from that endpoint, but it does not sufficiently ensure that the message was not modified during transmission. Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') - (362) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')) The product contains a code sequence that can run concurrently with other code, and the code sequence requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence that is operating concurrently. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Time-of-check Time-of-use (TOCTOU) Race Condition - (367) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')) > 367 (Time-of-check Time-of-use (TOCTOU) Race Condition) The product checks the state of a resource before using that resource, but the resource's state can change between the check and the use in a way that invalidates the results of the check. This can cause the product to perform invalid actions when the resource is in an unexpected state.TOCTTOUTOCCTOU Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Uncontrolled Resource Consumption - (400) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 400 (Uncontrolled Resource Consumption) The product does not properly control the allocation and maintenance of a limited resource, thereby enabling an actor to influence the amount of resources consumed, eventually leading to the exhaustion of available resources.Resource Exhaustion Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Allocation of Resources Without Limits or Throttling - (770) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 400 (Uncontrolled Resource Consumption) > 770 (Allocation of Resources Without Limits or Throttling) The product allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Restriction of Power Consumption - (920) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 400 (Uncontrolled Resource Consumption) > 920 (Improper Restriction of Power Consumption) The product operates in an environment in which power is a limited resource that cannot be automatically replenished, but the product does not properly restrict the amount of power that its operation consumes. Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Improper Resource Shutdown or Release - (404) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 404 (Improper Resource Shutdown or Release) The product does not release or incorrectly releases a resource before it is made available for re-use. Variant - a weakness
that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.Missing Release of Memory after Effective Lifetime - (401) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 404 (Improper Resource Shutdown or Release) > 401 (Missing Release of Memory after Effective Lifetime) The product does not sufficiently track and release allocated memory after it has been used, which slowly consumes remaining memory.Memory Leak Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Incomplete Cleanup - (459) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 404 (Improper Resource Shutdown or Release) > 459 (Incomplete Cleanup) The product does not properly "clean up" and remove temporary or supporting resources after they have been used.Insufficient Cleanup Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Release of Invalid Pointer or Reference - (763) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 404 (Improper Resource Shutdown or Release) > 763 (Release of Invalid Pointer or Reference) The product attempts to return a memory resource to the system, but it calls the wrong release function or calls the appropriate release function incorrectly. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Missing Release of Resource after Effective Lifetime - (772) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 404 (Improper Resource Shutdown or Release) > 772 (Missing Release of Resource after Effective Lifetime) The product does not release a resource after its effective lifetime has ended, i.e., after the resource is no longer needed. Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Inefficient Algorithmic Complexity - (407) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 407 (Inefficient 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.Quadratic Complexity Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Inefficient Regular Expression Complexity - (1333) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 407 (Inefficient Algorithmic Complexity) > 1333 (Inefficient Regular Expression Complexity) The product uses a regular expression with an inefficient, possibly exponential worst-case computational complexity that consumes excessive CPU cycles.ReDoSRegular Expression Denial of ServiceCatastrophic backtracking Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Interpretation Conflict - (436) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 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. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') - (444) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 436 (Interpretation Conflict) > 444 (Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')) The product acts as an intermediary HTTP agent
(such as a proxy or firewall) in the data flow between two
entities such as a client and server, but it does not
interpret malformed HTTP requests or responses in ways that
are consistent with how the messages will be processed by
those entities that are at the ultimate destination.HTTP Request SmugglingHTTP Response SmugglingHTTP Smuggling Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Externally Controlled Reference to a Resource in Another Sphere - (610) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 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. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Restriction of Rendered UI Layers or Frames - (1021) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 610 (Externally Controlled Reference to a Resource in Another Sphere) > 1021 (Improper Restriction of Rendered UI Layers or Frames) The web application does not restrict or incorrectly restricts frame objects or UI layers that belong to another application or domain, which can lead to user confusion about which interface the user is interacting with.ClickjackingUI Redress AttackTapjacking Composite - a Compound Element that consists of two or more distinct weaknesses, in which all weaknesses must be present at the same time in order for a potential vulnerability to arise. Removing any of the weaknesses eliminates or sharply reduces the risk. One weakness, X, can be "broken down" into component weaknesses Y and Z. There can be cases in which one weakness might not be essential to a composite, but changes the nature of the composite when it becomes a vulnerability.Session Fixation - (384) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 610 (Externally Controlled Reference to a Resource in Another Sphere) > 384 (Session Fixation) Authenticating a user, or otherwise establishing a new user session, without invalidating any existing session identifier gives an attacker the opportunity to steal authenticated sessions. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.URL Redirection to Untrusted Site ('Open Redirect') - (601) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 610 (Externally Controlled Reference to a Resource in Another Sphere) > 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 Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Restriction of XML External Entity Reference - (611) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 610 (Externally Controlled Reference to a Resource in Another Sphere) > 611 (Improper Restriction of XML External Entity Reference) The product 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 Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Server-Side Request Forgery (SSRF) - (918) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 610 (Externally Controlled Reference to a Resource in Another Sphere) > 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 Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Improper Synchronization - (662) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 662 (Improper Synchronization) The product utilizes multiple threads or processes to allow temporary access to a shared resource that can only be exclusive to one process at a time, but it does not properly synchronize these actions, which might cause simultaneous accesses of this resource by multiple threads or processes. Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Improper Locking - (667) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 662 (Improper Synchronization) > 667 (Improper Locking) The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors. Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Improper Initialization - (665) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 665 (Improper Initialization) The product does not initialize or incorrectly initializes a resource, which might leave the resource in an unexpected state when it is accessed or used. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Initialization of a Resource with an Insecure Default - (1188) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 665 (Improper Initialization) > 1188 (Initialization of a Resource with an Insecure Default) The product initializes or sets a resource with a default that is intended to be changed by the administrator, but the default is not secure. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Use of Uninitialized Resource - (908) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 665 (Improper Initialization) > 908 (Use of Uninitialized Resource) The product uses or accesses a resource that has not been initialized. Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Missing Initialization of Resource - (909) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 665 (Improper Initialization) > 909 (Missing Initialization of Resource) The product does not initialize a critical resource. Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Exposure of Resource to Wrong Sphere - (668) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 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. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Use of Externally-Controlled Format String - (134) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 668 (Exposure of Resource to Wrong Sphere) > 134 (Use of Externally-Controlled Format String) The product uses a function that accepts a format string as an argument, but the format string originates from an external source. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Untrusted Search Path - (426) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 668 (Exposure of Resource to Wrong Sphere) > 426 (Untrusted Search Path) The product searches for critical resources using an externally-supplied search path that can point to resources that are not under the product's direct control.Untrusted Path Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Uncontrolled Search Path Element - (427) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 668 (Exposure of Resource to Wrong Sphere) > 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 loadingDependency confusion Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Unquoted Search Path or Element - (428) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 668 (Exposure of Resource to Wrong Sphere) > 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. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Files or Directories Accessible to External Parties - (552) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 668 (Exposure of Resource to Wrong Sphere) > 552 (Files or Directories Accessible to External Parties) The product makes files or directories accessible to unauthorized actors, even though they should not be. Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Incorrect Resource Transfer Between Spheres - (669) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 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. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Removal of Sensitive Information Before Storage or Transfer - (212) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 669 (Incorrect Resource Transfer Between Spheres) > 212 (Improper Removal of Sensitive Information Before Storage or Transfer) The product stores, transfers, or shares a resource that contains sensitive information, but it does not properly remove that information before the product makes the resource available to unauthorized actors. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Unrestricted Upload of File with Dangerous Type - (434) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 669 (Incorrect Resource Transfer Between Spheres) > 434 (Unrestricted Upload of File with Dangerous Type) The product allows the upload or transfer of dangerous file types that are automatically processed within its environment.Unrestricted File Upload Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Download of Code Without Integrity Check - (494) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 669 (Incorrect Resource Transfer Between Spheres) > 494 (Download of Code Without Integrity Check) The product downloads source code or an executable from a remote location and executes the code without sufficiently verifying the origin and integrity of the code. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Reliance on Cookies without Validation and Integrity Checking - (565) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 669 (Incorrect Resource Transfer Between Spheres) > 565 (Reliance on Cookies without Validation and Integrity Checking) The product relies on the existence or values of cookies when performing security-critical operations, but it does not properly ensure that the setting is valid for the associated user. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Inclusion of Functionality from Untrusted Control Sphere - (829) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 669 (Incorrect Resource Transfer Between Spheres) > 829 (Inclusion of Functionality from Untrusted Control Sphere) The product imports, requires, or includes executable functionality (such as a library) from a source that is outside of the intended control sphere. Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Always-Incorrect Control Flow Implementation - (670) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 670 (Always-Incorrect Control Flow Implementation) The code contains a control flow path that does not reflect the algorithm that the path is intended to implement, leading to incorrect behavior any time this path is navigated. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Reachable Assertion - (617) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 670 (Always-Incorrect Control Flow Implementation) > 617 (Reachable Assertion) The product contains an assert() or similar statement that can be triggered by an attacker, which leads to an application exit or other behavior that is more severe than necessary.assertion failure Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Operation on a Resource after Expiration or Release - (672) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 672 (Operation on a Resource after Expiration or Release) The product uses, accesses, or otherwise operates on a resource after that resource has been expired, released, or revoked. Variant - a weakness
that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.Double Free - (415) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 672 (Operation on a Resource after Expiration or Release) > 415 (Double Free) The product calls free() twice on the same memory address, potentially leading to modification of unexpected memory locations.Double-free Variant - a weakness
that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.Use After Free - (416) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 672 (Operation on a Resource after Expiration or Release) > 416 (Use After Free) The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.Dangling pointerUAFUse-After-Free Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Insufficient Session Expiration - (613) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 672 (Operation on a Resource after Expiration or Release) > 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." Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Uncontrolled Recursion - (674) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 674 (Uncontrolled Recursion) The product does not properly control the amount of recursion that takes place, consuming excessive resources, such as allocated memory or the program stack.Stack Exhaustion Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion') - (776) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 674 (Uncontrolled Recursion) > 776 (Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion')) The product uses XML documents and allows their structure to be defined with a Document Type Definition (DTD), but it does not properly control the number of recursive definitions of entities.XEEBillion Laughs AttackXML Bomb Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.Incorrect Calculation - (682) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 682 (Incorrect Calculation) The product performs a calculation that generates incorrect or unintended results that are later used in security-critical decisions or resource management. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Incorrect Calculation of Buffer Size - (131) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 682 (Incorrect Calculation) > 131 (Incorrect Calculation of Buffer Size) The product does not correctly calculate the size to be used when allocating a buffer, which could lead to a buffer overflow. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Integer Overflow or Wraparound - (190) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 682 (Incorrect Calculation) > 190 (Integer Overflow or Wraparound) The product 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 occurs when an integer value is
incremented to a value that is too large to store in the
associated representation. When this occurs, the value may
become a very small or negative number.OverflowWraparoundwrap, wrap-around, wrap around Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Integer Underflow (Wrap or Wraparound) - (191) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 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 Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Off-by-one Error - (193) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 682 (Incorrect Calculation) > 193 (Off-by-one Error) A product calculates or uses an incorrect maximum or minimum value that is 1 more, or 1 less, than the correct value.off-by-five Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Divide By Zero - (369) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 682 (Incorrect Calculation) > 369 (Divide By Zero) The product divides a value by zero. Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.Incorrect Comparison - (697) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 697 (Incorrect Comparison) The product compares two entities in a security-relevant context, but the comparison is incorrect, which may lead to resultant weaknesses. Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Incorrect Type Conversion or Cast - (704) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 704 (Incorrect Type Conversion or Cast) The product does not correctly convert an object, resource, or structure from one type to a different type. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Incorrect Conversion between Numeric Types - (681) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 704 (Incorrect Type Conversion or Cast) > 681 (Incorrect Conversion between Numeric Types) When converting from one data type to another, such as long to integer, data can be omitted or translated in a way that produces unexpected values. If the resulting values are used in a sensitive context, then dangerous behaviors may occur. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Access of Resource Using Incompatible Type ('Type Confusion') - (843) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 704 (Incorrect Type Conversion or Cast) > 843 (Access of Resource Using Incompatible Type ('Type Confusion')) The product allocates or initializes a resource such as a pointer, object, or variable using one type, but it later accesses that resource using a type that is incompatible with the original type.Object Type Confusion Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Use of Incorrectly-Resolved Name or Reference - (706) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 706 (Use of Incorrectly-Resolved Name or Reference) The product uses a name or reference to access a resource, but the name/reference resolves to a resource that is outside of the intended control sphere. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Handling of Case Sensitivity - (178) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 706 (Use of Incorrectly-Resolved Name or Reference) > 178 (Improper Handling of Case Sensitivity) The product does not properly account for differences in case sensitivity when accessing or determining the properties of a resource, leading to inconsistent results. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') - (22) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 706 (Use of Incorrectly-Resolved Name or Reference) > 22 (Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')) The product 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 product 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 Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Link Resolution Before File Access ('Link Following') - (59) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 706 (Use of Incorrectly-Resolved Name or Reference) > 59 (Improper Link Resolution Before File Access ('Link Following')) The product 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 fileZip Slip Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Incorrect Permission Assignment for Critical Resource - (732) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 732 (Incorrect Permission Assignment for Critical Resource) The product specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Incorrect Default Permissions - (276) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 732 (Incorrect Permission Assignment for Critical Resource) > 276 (Incorrect Default Permissions) During installation, installed file permissions are set to allow anyone to modify those files. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Preservation of Permissions - (281) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 732 (Incorrect Permission Assignment for Critical Resource) > 281 (Improper Preservation of Permissions) The product does not preserve permissions or incorrectly preserves permissions when copying, restoring, or sharing objects, which can cause them to have less restrictive permissions than intended. Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Improper Check for Unusual or Exceptional Conditions - (754) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 754 (Improper Check for Unusual or Exceptional Conditions) The product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Unchecked Return Value - (252) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 754 (Improper Check for Unusual or Exceptional Conditions) > 252 (Unchecked Return Value) The product does not check the return value from a method or function, which can prevent it from detecting unexpected states and conditions. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Improper Check for Dropped Privileges - (273) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 754 (Improper Check for Unusual or Exceptional Conditions) > 273 (Improper Check for Dropped Privileges) The product attempts to drop privileges but does not check or incorrectly checks to see if the drop succeeded. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.NULL Pointer Dereference - (476) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 754 (Improper Check for Unusual or Exceptional Conditions) > 476 (NULL Pointer Dereference) The product dereferences a pointer that it expects to be valid but is NULL.NPDnull derefNPEnil pointer dereference Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Improper Handling of Exceptional Conditions - (755) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 755 (Improper Handling of Exceptional Conditions) The product does not handle or incorrectly handles an exceptional condition. Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Excessive Iteration - (834) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 834 (Excessive Iteration) The product performs an iteration or loop without sufficiently limiting the number of times that the loop is executed. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Loop with Unreachable Exit Condition ('Infinite Loop') - (835) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 834 (Excessive Iteration) > 835 (Loop with Unreachable Exit Condition ('Infinite Loop')) The product contains an iteration or loop with an exit condition that cannot be reached, i.e., an infinite loop. Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Missing Authorization - (862) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 862 (Missing Authorization) The product does not perform an authorization check when an actor attempts to access a resource or perform an action.AuthZ Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Direct Request ('Forced Browsing') - (425) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 862 (Missing Authorization) > 425 (Direct Request ('Forced Browsing')) The web application does not adequately enforce appropriate authorization on all restricted URLs, scripts, or files.forced browsing Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Incorrect Authorization - (863) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 863 (Incorrect Authorization) The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. This allows attackers to bypass intended access restrictions.AuthZ Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Authorization Bypass Through User-Controlled Key - (639) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 863 (Incorrect Authorization) > 639 (Authorization Bypass Through User-Controlled Key) The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.Insecure Direct Object Reference / IDORBroken Object Level Authorization / BOLAHorizontal Authorization Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Improper Control of Dynamically-Managed Code Resources - (913) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 913 (Improper Control of Dynamically-Managed Code Resources) The product 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. Variant - a weakness
that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution') - (1321) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 913 (Improper Control of Dynamically-Managed Code Resources) > 1321 (Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')) The product receives input from an upstream component that specifies attributes that are to be initialized or updated in an object, but it does not properly control modifications of attributes of the object prototype. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection') - (470) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 913 (Improper Control of Dynamically-Managed Code Resources) > 470 (Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')) The product uses external input with reflection to select which classes or code to use, but it does not sufficiently prevent the input from selecting improper classes or code.Reflection Injection Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Deserialization of Untrusted Data - (502) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 913 (Improper Control of Dynamically-Managed Code Resources) > 502 (Deserialization of Untrusted Data) The product deserializes untrusted data without sufficiently verifying that the resulting data will be valid.Marshaling, UnmarshalingPickling, UnpicklingPHP Object Injection Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Insecure Storage of Sensitive Information - (922) 1003 (Weaknesses for Simplified Mapping of Published Vulnerabilities) > 922 (Insecure Storage of Sensitive Information) The product stores sensitive information without properly limiting read or write access by unauthorized actors.
Maintenance This view may change in any upcoming CWE version based on the experience of NVD analysts, public feedback, and the CWE Team - especially with respect to the CWE Top 25 analysis. Maintenance This view has been modified significantly since its last major revision in 2016 (CWE-635 was used before 2016).
View ComponentsA | 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-843: Access of Resource Using Incompatible Type ('Type Confusion')
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product allocates or initializes a resource such as a pointer, object, or variable using one type, but it later accesses that resource using a type that is incompatible with the original type. When the product accesses the resource using an incompatible type, this could trigger logical errors because the resource does not have expected properties. In languages without memory safety, such as C and C++, type confusion can lead to out-of-bounds memory access. While this weakness is frequently associated with unions when parsing data with many different embedded object types in C, it can be present in any application that can interpret the same variable or memory location in multiple ways. This weakness is not unique to C and C++. For example, errors in PHP applications can be triggered by providing array parameters when scalars are expected, or vice versa. Languages such as Perl, which perform automatic conversion of a variable of one type when it is accessed as if it were another type, can also contain these issues. This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Software Development" (CWE-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages C (Undetermined Prevalence) C++ (Undetermined Prevalence) Example 1 The following code uses a union to support the representation of different types of messages. It formats messages differently, depending on their type. (bad code) Example Language: C #define NAME_TYPE 1
#define ID_TYPE 2 struct MessageBuffer { int msgType; };union { char *name; };int nameID; int main (int argc, char **argv) { struct MessageBuffer buf;
char *defaultMessage = "Hello World"; buf.msgType = NAME_TYPE; buf.name = defaultMessage; printf("Pointer of buf.name is %p\n", buf.name); /* This particular value for nameID is used to make the code architecture-independent. If coming from untrusted input, it could be any value. */ buf.nameID = (int)(defaultMessage + 1); printf("Pointer of buf.name is now %p\n", buf.name); if (buf.msgType == NAME_TYPE) { printf("Message: %s\n", buf.name); }else { printf("Message: Use ID %d\n", buf.nameID); }The code intends to process the message as a NAME_TYPE, and sets the default message to "Hello World." However, since both buf.name and buf.nameID are part of the same union, they can act as aliases for the same memory location, depending on memory layout after compilation. As a result, modification of buf.nameID - an int - can effectively modify the pointer that is stored in buf.name - a string. Execution of the program might generate output such as:
Pointer of name is 10830
Pointer of name is now 10831
Message: ello World
Notice how the pointer for buf.name was changed, even though buf.name was not explicitly modified. In this case, the first "H" character of the message is omitted. However, if an attacker is able to fully control the value of buf.nameID, then buf.name could contain an arbitrary pointer, leading to out-of-bounds reads or writes. Example 2 The following PHP code accepts a value, adds 5, and prints the sum. (bad code) Example Language: PHP $value = $_GET['value'];
$sum = $value + 5; echo "value parameter is '$value'<p>"; echo "SUM is $sum"; When called with the following query string:
value=123
the program calculates the sum and prints out:
SUM is 128
However, the attacker could supply a query string such as:
value[]=123
The "[]" array syntax causes $value to be treated as an array type, which then generates a fatal error when calculating $sum:
Fatal error: Unsupported operand types in program.php on line 2
Example 3 The following Perl code is intended to look up the privileges for user ID's between 0 and 3, by performing an access of the $UserPrivilegeArray reference. It is expected that only userID 3 is an admin (since this is listed in the third element of the array). (bad code) Example Language: Perl my $UserPrivilegeArray = ["user", "user", "admin", "user"];
my $userID = get_current_user_ID(); if ($UserPrivilegeArray eq "user") { print "Regular user!\n"; }else { print "Admin!\n"; }print "\$UserPrivilegeArray = $UserPrivilegeArray\n"; In this case, the programmer intended to use "$UserPrivilegeArray->{$userID}" to access the proper position in the array. But because the subscript was omitted, the "user" string was compared to the scalar representation of the $UserPrivilegeArray reference, which might be of the form "ARRAY(0x229e8)" or similar. Since the logic also "fails open" (CWE-636), the result of this bug is that all users are assigned administrator privileges. While this is a forced example, it demonstrates how type confusion can have security consequences, even in memory-safe languages.
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Applicable Platform This weakness is possible in any type-unsafe programming language. Research Gap Type confusion weaknesses have received some attention by applied researchers and major software vendors for C and C++ code. Some publicly-reported vulnerabilities probably have type confusion as a root-cause weakness, but these may be described as "memory corruption" instead. For other languages, there are very few public reports of type confusion weaknesses. These are probably under-studied. Since many programs rely directly or indirectly on loose typing, a potential "type confusion" behavior might be intentional, possibly requiring more manual analysis.
CWE-824: Access of Uninitialized Pointer
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterIf the pointer contains an uninitialized value, then the value might not point to a valid memory location. This could cause the product 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 product 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. This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Software Development" (CWE-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Relevant to the view "CISQ Quality Measures (2020)" (CWE-1305)
Relevant to the view "CISQ Data Protection Measures" (CWE-1340)
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Terminology 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. Maintenance 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.
CWE-770: Allocation of Resources Without Limits or Throttling
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor. Code frequently has to work with limited resources, so programmers must be careful to ensure that resources are not consumed too quickly, or too easily. Without use of quotas, resource limits, or other protection mechanisms, it can be easy for an attacker to consume many resources by rapidly making many requests, or causing larger resources to be used than is needed. When too many resources are allocated, or if a single resource is too large, then it can prevent the code from working correctly, possibly leading to a denial of service. This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Software Development" (CWE-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Relevant to the view "Architectural Concepts" (CWE-1008)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Not Language-Specific (Often Prevalent) Example 1 This code allocates a socket and forks each time it receives a new connection. (bad code) Example Language: C sock=socket(AF_INET, SOCK_STREAM, 0);
while (1) { newsock=accept(sock, ...); }printf("A connection has been accepted\n"); pid = fork(); The program does not track how many connections have been made, and it does not limit the number of connections. Because forking is a relatively expensive operation, an attacker would be able to cause the system to run out of CPU, processes, or memory by making a large number of connections. Alternatively, an attacker could consume all available connections, preventing others from accessing the system remotely. Example 2 In the following example a server socket connection is used to accept a request to store data on the local file system using a specified filename. The method openSocketConnection establishes a server socket to accept requests from a client. When a client establishes a connection to this service the getNextMessage method is first used to retrieve from the socket the name of the file to store the data, the openFileToWrite method will validate the filename and open a file to write to on the local file system. The getNextMessage is then used within a while loop to continuously read data from the socket and output the data to the file until there is no longer any data from the socket. (bad code) Example Language: C int writeDataFromSocketToFile(char *host, int port)
{ char filename[FILENAME_SIZE]; char buffer[BUFFER_SIZE]; int socket = openSocketConnection(host, port); if (socket < 0) { printf("Unable to open socket connection"); }return(FAIL); if (getNextMessage(socket, filename, FILENAME_SIZE) > 0) { if (openFileToWrite(filename) > 0) {
while (getNextMessage(socket, buffer, BUFFER_SIZE) > 0){
if (!(writeToFile(buffer) > 0)) }break;
closeFile(); closeSocket(socket); This example creates a situation where data can be dumped to a file on the local file system without any limits on the size of the file. This could potentially exhaust file or disk resources and/or limit other clients' ability to access the service. Example 3 In the following example, the processMessage method receives a two dimensional character array containing the message to be processed. The two-dimensional character array contains the length of the message in the first character array and the message body in the second character array. The getMessageLength method retrieves the integer value of the length from the first character array. After validating that the message length is greater than zero, the body character array pointer points to the start of the second character array of the two-dimensional character array and memory is allocated for the new body character array. (bad code) Example Language: C /* process message accepts a two-dimensional character array of the form [length][body] containing the message to be processed */ int processMessage(char **message) { char *body;
int length = getMessageLength(message[0]); if (length > 0) { body = &message[1][0]; }processMessageBody(body); return(SUCCESS); else { printf("Unable to process message; invalid message length"); }return(FAIL); This example creates a situation where the length of the body character array can be very large and will consume excessive memory, exhausting system resources. This can be avoided by restricting the length of the second character array with a maximum length check Also, consider changing the type from 'int' to 'unsigned int', so that you are always guaranteed that the number is positive. This might not be possible if the protocol specifically requires allowing negative values, or if you cannot control the return value from getMessageLength(), but it could simplify the check to ensure the input is positive, and eliminate other errors such as signed-to-unsigned conversion errors (CWE-195) that may occur elsewhere in the code. (good code) Example Language: C unsigned int length = getMessageLength(message[0]);
if ((length > 0) && (length < MAX_LENGTH)) {...} Example 4 In the following example, a server object creates a server socket and accepts client connections to the socket. For every client connection to the socket a separate thread object is generated using the ClientSocketThread class that handles request made by the client through the socket. (bad code) Example Language: Java public void acceptConnections() {
try {
ServerSocket serverSocket = new ServerSocket(SERVER_PORT);
int counter = 0; boolean hasConnections = true; while (hasConnections) { Socket client = serverSocket.accept(); }Thread t = new Thread(new ClientSocketThread(client)); t.setName(client.getInetAddress().getHostName() + ":" + counter++); t.start(); serverSocket.close(); } catch (IOException ex) {...} In this example there is no limit to the number of client connections and client threads that are created. Allowing an unlimited number of client connections and threads could potentially overwhelm the system and system resources. The server should limit the number of client connections and the client threads that are created. This can be easily done by creating a thread pool object that limits the number of threads that are generated. (good code) Example Language: Java public static final int SERVER_PORT = 4444;
public static final int MAX_CONNECTIONS = 10; ... public void acceptConnections() { try {
ServerSocket serverSocket = new ServerSocket(SERVER_PORT);
int counter = 0; boolean hasConnections = true; while (hasConnections) { hasConnections = checkForMoreConnections(); }Socket client = serverSocket.accept(); Thread t = new Thread(new ClientSocketThread(client)); t.setName(client.getInetAddress().getHostName() + ":" + counter++); ExecutorService pool = Executors.newFixedThreadPool(MAX_CONNECTIONS); pool.execute(t); serverSocket.close(); } catch (IOException ex) {...} Example 5 An unnamed web site allowed a user to purchase tickets for an event. A menu option allowed the user to purchase up to 10 tickets, but the back end did not restrict the actual number of tickets that could be purchased.
Example 6 Here the problem is that every time a connection is made, more memory is allocated. So if one just opened up more and more connections, eventually the machine would run out of memory. (bad code) Example Language: C bar connection() {
foo = malloc(1024); }return foo; endConnection(bar foo) { free(foo); }int main() { while(1) { }foo=connection(); }endConnection(foo)
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Relationship This entry is different from uncontrolled resource consumption (CWE-400) in that there are other weaknesses that are related to inability to control resource consumption, such as holding on to a resource too long after use, or not correctly keeping track of active resources so that they can be managed and released when they are finished (CWE-771). Theoretical Vulnerability theory is largely about how behaviors and resources interact. "Resource exhaustion" can be regarded as either a consequence or an attack, depending on the perspective. This entry is an attempt to reflect one of the underlying weaknesses that enable these attacks (or consequences) to take place.
CWE-670: Always-Incorrect Control Flow Implementation
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe code contains a control flow path that does not reflect the algorithm that the path is intended to implement, leading to incorrect behavior any time this path is navigated. This weakness captures cases in which a particular code segment is always incorrect with respect to the algorithm that it is implementing. For example, if a C programmer intends to include multiple statements in a single block but does not include the enclosing braces (CWE-483), then the logic is always incorrect. This issue is in contrast to most weaknesses in which the code usually behaves correctly, except when it is externally manipulated in malicious ways. This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Example 1 This code queries a server and displays its status when a request comes from an authorized IP address. (bad code) Example Language: PHP $requestingIP = $_SERVER['REMOTE_ADDR'];
if(!in_array($requestingIP,$ipAllowList)){ echo "You are not authorized to view this page"; }http_redirect($errorPageURL); $status = getServerStatus(); echo $status; ... This code redirects unauthorized users, but continues to execute code after calling http_redirect(). This means even unauthorized users may be able to access the contents of the page or perform a DoS attack on the server being queried. Also, note that this code is vulnerable to an IP address spoofing attack (CWE-212). Example 2 In this example, the programmer has indented the statements to call Do_X() and Do_Y(), as if the intention is that these functions are only called when the condition is true. However, because there are no braces to signify the block, Do_Y() will always be executed, even if the condition is false. (bad code) Example Language: C if (condition==true)
Do_X();
Do_Y(); This might not be what the programmer intended. When the condition is critical for security, such as in making a security decision or detecting a critical error, this may produce a vulnerability. Example 3 In both of these examples, a message is printed based on the month passed into the function: (bad code) Example Language: Java public void printMessage(int month){
switch (month) {
case 1: print("January"); case 2: print("February"); case 3: print("March"); case 4: print("April"); case 5: print("May"); case 6: print("June"); case 7: print("July"); case 8: print("August"); case 9: print("September"); case 10: print("October"); case 11: print("November"); case 12: print("December"); println(" is a great month"); (bad code) Example Language: C void printMessage(int month){
switch (month) {
case 1: printf("January"); case 2: printf("February"); case 3: printf("March"); case 4: printf("April"); case 5: printff("May"); case 6: printf("June"); case 7: printf("July"); case 8: printf("August"); case 9: printf("September"); case 10: printf("October"); case 11: printf("November"); case 12: printf("December"); printf(" is a great month"); Both examples do not use a break statement after each case, which leads to unintended fall-through behavior. For example, calling "printMessage(10)" will result in the text "OctoberNovemberDecember is a great month" being printed. Example 4 In the excerpt below, an AssertionError (an unchecked exception) is thrown if the user hasn't entered an email address in an HTML form. (bad code) Example Language: Java String email = request.getParameter("email_address");
assert email != null;
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Maintenance This node could possibly be split into lower-level nodes. "Early Return" is for returning control to the caller too soon (e.g., CWE-584). "Excess Return" is when control is returned too far up the call stack (CWE-600, CWE-395). "Improper control limitation" occurs when the product maintains control at a lower level of execution, when control should be returned "further" up the call stack (CWE-455). "Incorrect syntax" covers code that's "just plain wrong" such as CWE-484 and CWE-483. CWE-294: Authentication Bypass by Capture-replay
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterA capture-replay flaw exists when the design of the product makes it possible for a malicious user to sniff network traffic and bypass authentication by replaying it to the server in question to the same effect as the original message (or with minor changes). Capture-replay attacks are common and can be difficult to defeat without cryptography. They are a subset of network injection attacks that rely on observing previously-sent valid commands, then changing them slightly if necessary and resending the same commands to the server. This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Software Development" (CWE-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Relevant to the view "Architectural Concepts" (CWE-1008)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Not Language-Specific (Undetermined Prevalence)
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
CWE-290: Authentication Bypass by Spoofing
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThis attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks. This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Software Development" (CWE-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Relevant to the view "Architectural Concepts" (CWE-1008)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Example 1 The following code authenticates users. (bad code) Example Language: Java String sourceIP = request.getRemoteAddr();
if (sourceIP != null && sourceIP.equals(APPROVED_IP)) { authenticated = true; }The authentication mechanism implemented relies on an IP address for source validation. If an attacker is able to spoof the IP, they may be able to bypass the authentication mechanism. Example 2 Both of these examples check if a request is from a trusted address before responding to the request. (bad code) Example Language: C sd = socket(AF_INET, SOCK_DGRAM, 0);
serv.sin_family = AF_INET; serv.sin_addr.s_addr = htonl(INADDR_ANY); servr.sin_port = htons(1008); bind(sd, (struct sockaddr *) & serv, sizeof(serv)); while (1) { memset(msg, 0x0, MAX_MSG); }clilen = sizeof(cli); if (inet_ntoa(cli.sin_addr)==getTrustedAddress()) { n = recvfrom(sd, msg, MAX_MSG, 0, (struct sockaddr *) & cli, &clilen); }(bad code) Example Language: Java while(true) {
DatagramPacket rp=new DatagramPacket(rData,rData.length);
outSock.receive(rp); String in = new String(p.getData(),0, rp.getLength()); InetAddress clientIPAddress = rp.getAddress(); int port = rp.getPort(); if (isTrustedAddress(clientIPAddress) & secretKey.equals(in)) { out = secret.getBytes(); }DatagramPacket sp =new DatagramPacket(out,out.length, IPAddress, port); outSock.send(sp); The code only verifies the address as stored in the request packet. An attacker can spoof this address, thus impersonating a trusted client. Example 3 The following code samples use a DNS lookup in order to decide whether or not an inbound request is from a trusted host. If an attacker can poison the DNS cache, they can gain trusted status. (bad code) Example Language: C struct hostent *hp;struct in_addr myaddr;
char* tHost = "trustme.example.com"; myaddr.s_addr=inet_addr(ip_addr_string); hp = gethostbyaddr((char *) &myaddr, sizeof(struct in_addr), AF_INET); if (hp && !strncmp(hp->h_name, tHost, sizeof(tHost))) { trusted = true; } else {trusted = false; }(bad code) Example Language: Java String ip = request.getRemoteAddr();
InetAddress addr = InetAddress.getByName(ip); if (addr.getCanonicalHostName().endsWith("trustme.com")) { trusted = true; }(bad code) Example Language: C# IPAddress hostIPAddress = IPAddress.Parse(RemoteIpAddress);
IPHostEntry hostInfo = Dns.GetHostByAddress(hostIPAddress); if (hostInfo.HostName.EndsWith("trustme.com")) { trusted = true; }IP addresses are more reliable than DNS names, but they can also be spoofed. Attackers can easily forge the source IP address of the packets they send, but response packets will return to the forged IP address. To see the response packets, the attacker has to sniff the traffic between the victim machine and the forged IP address. In order to accomplish the required sniffing, attackers typically attempt to locate themselves on the same subnet as the victim machine. Attackers may be able to circumvent this requirement by using source routing, but source routing is disabled across much of the Internet today. In summary, IP address verification can be a useful part of an authentication scheme, but it should not be the single factor required for authentication.
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
CWE-639: Authorization Bypass Through User-Controlled Key
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data. Retrieval of a user record occurs in the system based on some key value that is under user control. The key would typically identify a user-related record stored in the system and would be used to lookup that record for presentation to the user. It is likely that an attacker would have to be an authenticated user in the system. However, the authorization process would not properly check the data access operation to ensure that the authenticated user performing the operation has sufficient entitlements to perform the requested data access, hence bypassing any other authorization checks present in the system. For example, attackers can look at places where user specific data is retrieved (e.g. search screens) and determine whether the key for the item being looked up is controllable externally. The key may be a hidden field in the HTML form field, might be passed as a URL parameter or as an unencrypted cookie variable, then in each of these cases it will be possible to tamper with the key value. One manifestation of this weakness is when a system uses sequential or otherwise easily-guessable session IDs that would allow one user to easily switch to another user's session and read/modify their data.
This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Software Development" (CWE-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Relevant to the view "Architectural Concepts" (CWE-1008)
Relevant to the view "CISQ Data Protection Measures" (CWE-1340)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Not Language-Specific (Undetermined Prevalence) Example 1 The following code uses a parameterized statement, which escapes metacharacters and prevents SQL injection vulnerabilities, to construct and execute a SQL query that searches for an invoice matching the specified identifier [1]. The identifier is selected from a list of all invoices associated with the current authenticated user. (bad code) Example Language: C# ...
conn = new SqlConnection(_ConnectionString); conn.Open(); int16 id = System.Convert.ToInt16(invoiceID.Text); SqlCommand query = new SqlCommand( "SELECT * FROM invoices WHERE id = @id", conn); query.Parameters.AddWithValue("@id", id); SqlDataReader objReader = objCommand.ExecuteReader(); ... The problem is that the developer has not considered all of the possible values of id. Although the interface generates a list of invoice identifiers that belong to the current user, an attacker can bypass this interface to request any desired invoice. Because the code in this example does not check to ensure that the user has permission to access the requested invoice, it will display any invoice, even if it does not belong to the current user.
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product copies an input buffer to an output buffer without verifying that the size of the input buffer is less than the size of the output buffer, leading to a buffer overflow. A buffer overflow condition exists when a product attempts to put more data in a buffer than it can hold, or when it attempts to put data in a memory area outside of the boundaries of a buffer. The simplest type of error, and the most common cause of buffer overflows, is the "classic" case in which the product copies the buffer without restricting how much is copied. Other variants exist, but the existence of a classic overflow strongly suggests that the programmer is not considering even the most basic of security protections.
This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Software Development" (CWE-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Relevant to the view "CISQ Quality Measures (2020)" (CWE-1305)
Relevant to the view "CISQ Data Protection Measures" (CWE-1340)
Relevant to the view "Seven Pernicious Kingdoms" (CWE-700)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages C (Undetermined Prevalence) C++ (Undetermined Prevalence) Class: Assembly (Undetermined Prevalence) Example 1 The following code asks the user to enter their last name and then attempts to store the value entered in the last_name array. (bad code) Example Language: C char last_name[20];
printf ("Enter your last name: "); scanf ("%s", last_name); The problem with the code above is that it does not restrict or limit the size of the name entered by the user. If the user enters "Very_very_long_last_name" which is 24 characters long, then a buffer overflow will occur since the array can only hold 20 characters total. Example 2 The following code attempts to create a local copy of a buffer to perform some manipulations to the data. (bad code) Example Language: C void manipulate_string(char * string){
char buf[24]; }strcpy(buf, string); ... However, the programmer does not ensure that the size of the data pointed to by string will fit in the local buffer and copies the data with the potentially dangerous strcpy() function. This may result in a buffer overflow condition if an attacker can influence the contents of the string parameter. Example 3 The code below calls the gets() function to read in data from the command line. (bad code) Example Language: C char buf[24]; }printf("Please enter your name and press <Enter>\n"); gets(buf); ... However, gets() is inherently unsafe, because it copies all input from STDIN to the buffer without checking size. This allows the user to provide a string that is larger than the buffer size, resulting in an overflow condition. Example 4 In the following example, a server accepts connections from a client and processes the client request. After accepting a client connection, the program will obtain client information using the gethostbyaddr method, copy the hostname of the client that connected to a local variable and output the hostname of the client to a log file. (bad code) Example Language: C ...
struct hostent *clienthp;
char hostname[MAX_LEN]; // create server socket, bind to server address and listen on socket ... // accept client connections and process requests int count = 0; for (count = 0; count < MAX_CONNECTIONS; count++) { int clientlen = sizeof(struct sockaddr_in); int clientsocket = accept(serversocket, (struct sockaddr *)&clientaddr, &clientlen); if (clientsocket >= 0) { clienthp = gethostbyaddr((char*) &clientaddr.sin_addr.s_addr, sizeof(clientaddr.sin_addr.s_addr), AF_INET);
strcpy(hostname, clienthp->h_name); logOutput("Accepted client connection from host ", hostname); // process client request ... close(clientsocket); close(serversocket); ... However, the hostname of the client that connected may be longer than the allocated size for the local hostname variable. This will result in a buffer overflow when copying the client hostname to the local variable using the strcpy method.
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Relationship At the code level, stack-based and heap-based overflows do not differ significantly, so there usually is not a need to distinguish them. From the attacker perspective, they can be quite different, since different techniques are required to exploit them. Terminology Many issues that are now called "buffer overflows" are substantively different than the "classic" overflow, including entirely different bug types that rely on overflow exploit techniques, such as integer signedness errors, integer overflows, and format string bugs. This imprecise terminology can make it difficult to determine which variant is being reported.
CWE-312: Cleartext Storage of Sensitive Information
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product stores sensitive information in cleartext within a resource that might be accessible to another control sphere. Because the information is stored in cleartext (i.e., unencrypted), attackers could potentially read it. Even if the information is encoded in a way that is not human-readable, certain techniques could determine which encoding is being used, then decode the information. When organizations adopt cloud services, it can be easier for attackers to access the data from anywhere on the Internet. In some systems/environments such as cloud, the use of "double encryption" (at both the software and hardware layer) might be required, and the developer might be solely responsible for both layers, instead of shared responsibility with the administrator of the broader system/environment. This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Software Development" (CWE-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Relevant to the view "Architectural Concepts" (CWE-1008)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Not Language-Specific (Undetermined Prevalence) Technologies Class: Cloud Computing (Undetermined Prevalence) Class: ICS/OT (Undetermined Prevalence) Class: Mobile (Undetermined Prevalence) Example 1 The following code excerpt stores a plaintext user account ID in a browser cookie. (bad code) Example Language: Java response.addCookie( new Cookie("userAccountID", acctID);
Because the account ID is in plaintext, the user's account information is exposed if their computer is compromised by an attacker. Example 2 This code writes a user's login information to a cookie so the user does not have to login again later. (bad code) Example Language: PHP function persistLogin($username, $password){
$data = array("username" => $username, "password"=> $password); }setcookie ("userdata", $data); The code stores the user's username and password in plaintext in a cookie on the user's machine. This exposes the user's login information if their computer is compromised by an attacker. Even if the user's machine is not compromised, this weakness combined with cross-site scripting (CWE-79) could allow an attacker to remotely copy the cookie. Also note this example code also exhibits Plaintext Storage in a Cookie (CWE-315). Example 3 The following code attempts to establish a connection, read in a password, then store it to a buffer. (bad code) Example Language: C server.sin_family = AF_INET; hp = gethostbyname(argv[1]);
if (hp==NULL) error("Unknown host"); memcpy( (char *)&server.sin_addr,(char *)hp->h_addr,hp->h_length); if (argc < 3) port = 80; else port = (unsigned short)atoi(argv[3]); server.sin_port = htons(port); if (connect(sock, (struct sockaddr *)&server, sizeof server) < 0) error("Connecting"); ... while ((n=read(sock,buffer,BUFSIZE-1))!=-1) { write(dfd,password_buffer,n); ... While successful, the program does not encrypt the data before writing it to a buffer, possibly exposing it to unauthorized actors. Example 4 The following examples show a portion of properties and configuration files for Java and ASP.NET applications. The files include username and password information but they are stored in cleartext. This Java example shows a properties file with a cleartext username / password pair. (bad code) Example Language: Java # Java Web App ResourceBundle properties file ... webapp.ldap.username=secretUsername webapp.ldap.password=secretPassword ... The following example shows a portion of a configuration file for an ASP.Net application. This configuration file includes username and password information for a connection to a database but the pair is stored in cleartext. (bad code) Example Language: ASP.NET ...
<connectionStrings> <add name="ud_DEV" connectionString="connectDB=uDB; uid=db2admin; pwd=password; dbalias=uDB;" providerName="System.Data.Odbc" /> </connectionStrings>... Username and password information should not be included in a configuration file or a properties file in cleartext as this will allow anyone who can read the file access to the resource. If possible, encrypt this information. Example 5 In 2022, the OT:ICEFALL study examined products by 10 different Operational Technology (OT) vendors. The researchers reported 56 vulnerabilities and said that the products were "insecure by design" [REF-1283]. If exploited, these vulnerabilities often allowed adversaries to change how the products operated, ranging from denial of service to changing the code that the products executed. Since these products were often used in industries such as power, electrical, water, and others, there could even be safety implications. At least one OT product stored a password in plaintext. Example 6 In 2021, a web site operated by PeopleGIS stored data of US municipalities in Amazon Web Service (AWS) Simple Storage Service (S3) buckets. (bad code) Example Language: Other A security researcher found 86 S3 buckets that could be accessed without authentication (CWE-306) and stored data unencrypted (CWE-312). These buckets exposed over 1000 GB of data and 1.6 million files including physical addresses, phone numbers, tax documents, pictures of driver's license IDs, etc. [REF-1296] [REF-1295]
While it was not publicly disclosed how the data was protected after discovery, multiple options could have been considered. (good code) Example Language: Other The sensitive information could have been protected by ensuring that the buckets did not have public read access, e.g., by enabling the s3-account-level-public-access-blocks-periodic rule to Block Public Access. In addition, the data could have been encrypted at rest using the appropriate S3 settings, e.g., by enabling server-side encryption using the s3-bucket-server-side-encryption-enabled setting. Other settings are available to further prevent bucket data from being leaked. [REF-1297]
Example 7 Consider the following PowerShell command examples for encryption scopes of Azure storage objects. In the first example, an encryption scope is set for the storage account. (bad code) Example Language: Shell New-AzStorageEncryptionScope -ResourceGroupName "MyResourceGroup" -AccountName "MyStorageAccount" -EncryptionScopeName testscope -StorageEncryption
The result (edited and formatted for readability) might be: (bad code) Example Language: Other ResourceGroupName: MyResourceGroup, StorageAccountName: MyStorageAccount
However, the empty string under RequireInfrastructureEncryption indicates this service was not enabled at the time of creation, because the -RequireInfrastructureEncryption argument was not specified in the command. Including the -RequireInfrastructureEncryption argument addresses the issue: (good code) Example Language: Shell New-AzStorageEncryptionScope -ResourceGroupName "MyResourceGroup" -AccountName "MyStorageAccount" -EncryptionScopeName testscope -StorageEncryption -RequireInfrastructureEncryption
This produces the report: (result) Example Language: Other ResourceGroupName: MyResourceGroup, StorageAccountName: MyStorageAccount
In a scenario where both software and hardware layer encryption is required ("double encryption"), Azure's infrastructure encryption setting can be enabled via the CLI or Portal. An important note is that infrastructure hardware encryption cannot be enabled or disabled after a blob is created. Furthermore, the default value for infrastructure encryption is disabled in blob creations.
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Terminology Different people use "cleartext" and "plaintext" to mean the same thing: the lack of encryption. However, within cryptography, these have more precise meanings. Plaintext is the information just before it is fed into a cryptographic algorithm, including already-encrypted text. Cleartext is any information that is unencrypted, although it might be in an encoded form that is not easily human-readable (such as base64 encoding).
CWE-319: Cleartext Transmission of Sensitive Information
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors. Many communication channels can be "sniffed" (monitored) by adversaries during data transmission. For example, in networking, packets can traverse many intermediary nodes from the source to the destination, whether across the internet, an internal network, the cloud, etc. Some actors might have privileged access to a network interface or any link along the channel, such as a router, but they might not be authorized to collect the underlying data. As a result, network traffic could be sniffed by adversaries, spilling security-critical data. Applicable communication channels are not limited to software products. Applicable channels include hardware-specific technologies such as internal hardware networks and external debug channels, supporting remote JTAG debugging. When mitigations are not applied to combat adversaries within the product's threat model, this weakness significantly lowers the difficulty of exploitation by such adversaries. When full communications are recorded or logged, such as with a packet dump, an adversary could attempt to obtain the dump long after the transmission has occurred and try to "sniff" the cleartext from the recorded communications in the dump itself. Even if the information is encoded in a way that is not human-readable, certain techniques could determine which encoding is being used, then decode the information. This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Software Development" (CWE-699)
Relevant to the view "Hardware Design" (CWE-1194)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Relevant to the view "Architectural Concepts" (CWE-1008)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Not Language-Specific (Undetermined Prevalence) Technologies Class: Cloud Computing (Undetermined Prevalence) Class: Mobile (Undetermined Prevalence) Class: ICS/OT (Often Prevalent) Class: System on Chip (Undetermined Prevalence) Test/Debug Hardware (Often Prevalent) Example 1 The following code attempts to establish a connection to a site to communicate sensitive information. (bad code) Example Language: Java try {
URL u = new URL("http://www.secret.example.org/"); }HttpURLConnection hu = (HttpURLConnection) u.openConnection(); hu.setRequestMethod("PUT"); hu.connect(); OutputStream os = hu.getOutputStream(); hu.disconnect(); catch (IOException e) {
//...
}Though a connection is successfully made, the connection is unencrypted and it is possible that all sensitive data sent to or received from the server will be read by unintended actors. Example 2 In 2022, the OT:ICEFALL study examined products by 10 different Operational Technology (OT) vendors. The researchers reported 56 vulnerabilities and said that the products were "insecure by design" [REF-1283]. If exploited, these vulnerabilities often allowed adversaries to change how the products operated, ranging from denial of service to changing the code that the products executed. Since these products were often used in industries such as power, electrical, water, and others, there could even be safety implications. Multiple vendors used cleartext transmission of sensitive information in their OT products. Example 3 A TAP accessible register is read/written by a JTAG based tool, for internal use by authorized users. However, an adversary can connect a probing device and collect the values from the unencrypted channel connecting the JTAG interface to the authorized user, if no additional protections are employed. Example 4 The following Azure CLI command lists the properties of a particular storage account: (informative) Example Language: Shell az storage account show -g {ResourceGroupName} -n {StorageAccountName}
The JSON result might be: (bad code) Example Language: JSON
{
"name": "{StorageAccountName}",
}
"enableHttpsTrafficOnly": false, "type": "Microsoft.Storage/storageAccounts" The enableHttpsTrafficOnly value is set to false, because the default setting for Secure transfer is set to Disabled. This allows cloud storage resources to successfully connect and transfer data without the use of encryption (e.g., HTTP, SMB 2.1, SMB 3.0, etc.). Azure's storage accounts can be configured to only accept requests from secure connections made over HTTPS. The secure transfer setting can be enabled using Azure's Portal (GUI) or programmatically by setting the enableHttpsTrafficOnly property to True on the storage account, such as: (good code) Example Language: Shell az storage account update -g {ResourceGroupName} -n {StorageAccountName} --https-only true
The change can be confirmed from the result by verifying that the enableHttpsTrafficOnly value is true: (good code) Example Language: JSON
{
"name": "{StorageAccountName}",
}
"enableHttpsTrafficOnly": true, "type": "Microsoft.Storage/storageAccounts"
Note: to enable secure transfer using Azure's Portal instead of the command line:
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Maintenance The Taxonomy_Mappings to ISA/IEC 62443 were added in CWE 4.10, but they are still under review and might change in future CWE versions. These draft mappings were performed by members of the "Mapping CWE to 62443" subgroup of the CWE-CAPEC ICS/OT Special Interest Group (SIG), and their work is incomplete as of CWE 4.10. The mappings are included to facilitate discussion and review by the broader ICS/OT community, and they are likely to change in future CWE versions.
CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product contains a code sequence that can run concurrently with other code, and the code sequence requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence that is operating concurrently. 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:
A race condition exists when an "interfering code sequence" can still access the shared resource, violating exclusivity. Programmers may assume that certain code sequences execute too quickly to be affected by an interfering code sequence; when they are not, this violates atomicity. For example, the single "x++" statement may appear atomic at the code layer, but it is actually non-atomic at the instruction layer, since it involves a read (the original value of x), followed by a computation (x+1), followed by a write (save the result to x). The interfering code sequence could be "trusted" or "untrusted." A trusted interfering code sequence occurs within the product; it cannot be modified by the attacker, and it can only be invoked indirectly. An untrusted interfering code sequence can be authored directly by the attacker, and typically it is external to the vulnerable product. This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages C (Sometimes Prevalent) C++ (Sometimes Prevalent) Java (Sometimes Prevalent) Technologies Class: Mobile (Undetermined Prevalence) Class: ICS/OT (Undetermined Prevalence) Example 1 This code could be used in an e-commerce application that supports transfers between accounts. It takes the total amount of the transfer, sends it to the new account, and deducts the amount from the original account. (bad code) Example Language: Perl $transfer_amount = GetTransferAmount();
$balance = GetBalanceFromDatabase(); if ($transfer_amount < 0) { FatalError("Bad Transfer Amount"); }$newbalance = $balance - $transfer_amount; if (($balance - $transfer_amount) < 0) { FatalError("Insufficient Funds"); }SendNewBalanceToDatabase($newbalance); NotifyUser("Transfer of $transfer_amount succeeded."); NotifyUser("New balance: $newbalance"); A race condition could occur between the calls to GetBalanceFromDatabase() and SendNewBalanceToDatabase(). Suppose the balance is initially 100.00. An attack could be constructed as follows: (attack code) Example Language: Other In the following pseudocode, the attacker makes two simultaneous calls of the program, CALLER-1 and CALLER-2. Both callers are for the same user account.
CALLER-1 (the attacker) is associated with PROGRAM-1 (the instance that handles CALLER-1). CALLER-2 is associated with PROGRAM-2. CALLER-1 makes a transfer request of 80.00. PROGRAM-1 calls GetBalanceFromDatabase and sets $balance to 100.00 PROGRAM-1 calculates $newbalance as 20.00, then calls SendNewBalanceToDatabase(). Due to high server load, the PROGRAM-1 call to SendNewBalanceToDatabase() encounters a delay. CALLER-2 makes a transfer request of 1.00. PROGRAM-2 calls GetBalanceFromDatabase() and sets $balance to 100.00. This happens because the previous PROGRAM-1 request was not processed yet. PROGRAM-2 determines the new balance as 99.00. After the initial delay, PROGRAM-1 commits its balance to the database, setting it to 20.00. PROGRAM-2 sends a request to update the database, setting the balance to 99.00 At this stage, the attacker should have a balance of 19.00 (due to 81.00 worth of transfers), but the balance is 99.00, as recorded in the database. To prevent this weakness, the programmer has several options, including using a lock to prevent multiple simultaneous requests to the web application, or using a synchronization mechanism that includes all the code between GetBalanceFromDatabase() and SendNewBalanceToDatabase(). Example 2 The following function attempts to acquire a lock in order to perform operations on a shared resource. (bad code) Example Language: C void f(pthread_mutex_t *mutex) {
pthread_mutex_lock(mutex);
/* access shared resource */ pthread_mutex_unlock(mutex); However, the code does not check the value returned by pthread_mutex_lock() for errors. If pthread_mutex_lock() cannot acquire the mutex for any reason, the function may introduce a race condition into the program and result in undefined behavior. In order to avoid data races, correctly written programs must check the result of thread synchronization functions and appropriately handle all errors, either by attempting to recover from them or reporting them to higher levels. (good code) Example Language: C int f(pthread_mutex_t *mutex) {
int result;
result = pthread_mutex_lock(mutex); if (0 != result) return result;
/* access shared resource */ return pthread_mutex_unlock(mutex); Example 3 Suppose a processor's Memory Management Unit (MMU) has 5 other shadow MMUs to distribute its workload for its various cores. Each MMU has the start address and end address of "accessible" memory. Any time this accessible range changes (as per the processor's boot status), the main MMU sends an update message to all the shadow MMUs. Suppose the interconnect fabric does not prioritize such "update" packets over other general traffic packets. This introduces a race condition. If an attacker can flood the target with enough messages so that some of those attack packets reach the target before the new access ranges gets updated, then the attacker can leverage this scenario.
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Research Gap Race conditions in web applications are under-studied and probably under-reported. However, in 2008 there has been growing interest in this area. Research Gap Much of the focus of race condition research has been in Time-of-check Time-of-use (TOCTOU) variants (CWE-367), but many race conditions are related to synchronization problems that do not necessarily require a time-of-check. Research Gap From a classification/taxonomy perspective, the relationships between concurrency and program state need closer investigation and may be useful in organizing related issues. Maintenance The relationship between race conditions and synchronization problems (CWE-662) needs to be further developed. They are not necessarily two perspectives of the same core concept, since synchronization is only one technique for avoiding race conditions, and synchronization can be used for other purposes besides race condition prevention.
CWE-352: Cross-Site Request Forgery (CSRF)
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe 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.
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. This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Relevant to the view "Architectural Concepts" (CWE-1008)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Not Language-Specific (Undetermined Prevalence) Technologies Web Server (Undetermined Prevalence) 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 code) 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.
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Relationship There can be a close relationship between XSS and CSRF (CWE-352). An attacker might use CSRF in order to trick the victim into submitting requests to the server in which the requests contain an XSS payload. A well-known example of this was the Samy worm on MySpace [REF-956]. The worm used XSS to insert malicious HTML sequences into a user's profile and add the attacker as a MySpace friend. MySpace friends of that victim would then execute the payload to modify their own profiles, causing the worm to propagate exponentially. Since the victims did not intentionally insert the malicious script themselves, CSRF was a root cause. Theoretical The CSRF topology is multi-channel:
CWE-502: Deserialization of Untrusted Data
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product deserializes untrusted data without sufficiently verifying that the resulting data will be valid. 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.
This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. Relevant to the view "Research Concepts" (CWE-1000)
Relevant to the view "Software Development" (CWE-699)
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
Relevant to the view "Architectural Concepts" (CWE-1008)
|