Home > CWE List > VIEW SLICE: CWE-900: Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors (4.16) |
|
CWE VIEW: Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors
CWE entries in this view (graph) are listed in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors.
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:
900 - Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors
Category - a CWE entry that contains a set of other entries that share a common characteristic.
2011 Top 25 - Weaknesses On the Cusp
- (867)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
867
(2011 Top 25 - Weaknesses On the Cusp)
Weaknesses in this category are not part of the general Top 25, but they were part of the original nominee list from which the Top 25 was drawn.
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)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
867
(2011 Top 25 - Weaknesses On the Cusp) >
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 index
index-out-of-range
array index 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.
Generation of Error Message Containing Sensitive Information
- (209)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
867
(2011 Top 25 - Weaknesses On the Cusp) >
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.
Improper Removal of Sensitive Information Before Storage or Transfer
- (212)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
867
(2011 Top 25 - Weaknesses On the Cusp) >
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.
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)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
867
(2011 Top 25 - Weaknesses On the Cusp) >
330
(Use of Insufficiently Random Values)
The product uses insufficiently random numbers or values in a security context that depends on unpredictable numbers.
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)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
867
(2011 Top 25 - Weaknesses On the Cusp) >
362
(Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))
The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.
Race Condition
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 Initialization of a Variable
- (456)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
867
(2011 Top 25 - Weaknesses On the Cusp) >
456
(Missing Initialization of a Variable)
The product does not initialize critical variables, which causes the execution environment to use unexpected values.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
867
(2011 Top 25 - Weaknesses On the Cusp) >
476
(NULL Pointer Dereference)
The product dereferences a pointer that it expects to be valid but is NULL.
NPD
null deref
NPE
nil pointer dereference
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
867
(2011 Top 25 - Weaknesses On the Cusp) >
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.
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)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
867
(2011 Top 25 - Weaknesses On the Cusp) >
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.
Allocation of Resources Without Limits or Throttling
- (770)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
867
(2011 Top 25 - Weaknesses On the Cusp) >
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.
Missing Release of Resource after Effective Lifetime
- (772)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
867
(2011 Top 25 - Weaknesses On the Cusp) >
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.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 Access with Incorrect Length Value
- (805)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
867
(2011 Top 25 - Weaknesses On the Cusp) >
805
(Buffer Access with Incorrect Length Value)
The product uses a sequential operation to read or write a buffer, but it uses an incorrect length value that causes it to access memory that is outside of the bounds of the buffer.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 Pointer Dereference
- (822)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
867
(2011 Top 25 - Weaknesses On the Cusp) >
822
(Untrusted Pointer Dereference)
The product obtains a value from an untrusted source, converts this value to a pointer, and dereferences the resulting pointer.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Expired Pointer Dereference
- (825)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
867
(2011 Top 25 - Weaknesses On the Cusp) >
825
(Expired Pointer Dereference)
The product dereferences a pointer that contains a location for memory that was previously valid, but is no longer valid.
Dangling pointer
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
867
(2011 Top 25 - Weaknesses On the Cusp) >
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.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 Behavioral Workflow
- (841)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
867
(2011 Top 25 - Weaknesses On the Cusp) >
841
(Improper Enforcement of Behavioral Workflow)
The product supports a session in which more than one behavior must be performed by an actor, but it does not properly ensure that the actor performs the behaviors in the required sequence.
Category - a CWE entry that contains a set of other entries that share a common characteristic.
2011 Top 25 - Porous Defenses
- (866)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
866
(2011 Top 25 - Porous Defenses)
Weaknesses in this category are listed in the "Porous Defenses" section of the 2011 CWE/SANS Top 25 Most Dangerous Software Errors.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Execution with Unnecessary Privileges
- (250)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
866
(2011 Top 25 - Porous Defenses) >
250
(Execution with Unnecessary Privileges)
The product performs an operation at a privilege level that is higher than the minimum level required, which creates new weaknesses or amplifies the consequences of other weaknesses.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
866
(2011 Top 25 - Porous Defenses) >
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)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
866
(2011 Top 25 - Porous Defenses) >
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.
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)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
866
(2011 Top 25 - Porous Defenses) >
311
(Missing Encryption of Sensitive Data)
The product does not encrypt sensitive or critical information before storage or 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.
Use of a Broken or Risky Cryptographic Algorithm
- (327)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
866
(2011 Top 25 - Porous Defenses) >
327
(Use of a Broken or Risky Cryptographic Algorithm)
The product uses a broken or risky cryptographic algorithm or protocol.
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)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
866
(2011 Top 25 - Porous Defenses) >
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.
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 of a One-Way Hash without a Salt
- (759)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
866
(2011 Top 25 - Porous Defenses) >
759
(Use of a One-Way Hash without a Salt)
The product uses a one-way cryptographic hash against an input that should not be reversible, such as a password, but the product does not also use a salt as part of the input.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
866
(2011 Top 25 - Porous Defenses) >
798
(Use of Hard-coded Credentials)
The product contains hard-coded credentials, such as a password or cryptographic key.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Reliance on Untrusted Inputs in a Security Decision
- (807)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
866
(2011 Top 25 - Porous Defenses) >
807
(Reliance on Untrusted Inputs in a Security Decision)
The product uses a protection mechanism that relies on the existence or values of an input, but the input can be modified by an untrusted actor in a way that bypasses the protection mechanism.
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)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
866
(2011 Top 25 - Porous Defenses) >
862
(Missing Authorization)
The product does not perform an authorization check when an actor attempts to access a resource or perform an action.
AuthZ
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)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
866
(2011 Top 25 - Porous Defenses) >
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.
AuthZ
Category - a CWE entry that contains a set of other entries that share a common characteristic.
2011 Top 25 - Risky Resource Management
- (865)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
865
(2011 Top 25 - Risky Resource Management)
Weaknesses in this category are listed in the "Risky Resource Management" section of the 2011 CWE/SANS Top 25 Most Dangerous Software Errors.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
865
(2011 Top 25 - Risky Resource Management) >
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 Overflow
Unbounded 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.
Incorrect Calculation of Buffer Size
- (131)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
865
(2011 Top 25 - Risky Resource Management) >
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.
Use of Externally-Controlled Format String
- (134)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
865
(2011 Top 25 - Risky Resource Management) >
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.
Integer Overflow or Wraparound
- (190)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
865
(2011 Top 25 - Risky Resource Management) >
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.
Overflow
Wraparound
wrap, 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.
Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
- (22)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
865
(2011 Top 25 - Risky Resource Management) >
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 traversal
Path 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.
Download of Code Without Integrity Check
- (494)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
865
(2011 Top 25 - Risky Resource Management) >
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.
Use of Potentially Dangerous Function
- (676)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
865
(2011 Top 25 - Risky Resource Management) >
676
(Use of Potentially Dangerous Function)
The product invokes a potentially dangerous function that could introduce a vulnerability if it is used incorrectly, but the function can also be used safely.
Category - a CWE entry that contains a set of other entries that share a common characteristic.
2011 Top 25 - Insecure Interaction Between Components
- (864)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
864
(2011 Top 25 - Insecure Interaction Between Components)
Weaknesses in this category are listed in the "Insecure Interaction Between Components" section of the 2011 CWE/SANS Top 25 Most Dangerous Software Errors.
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)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
864
(2011 Top 25 - Insecure Interaction Between Components) >
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 Riding
Cross Site Reference Forgery
XSRF
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
864
(2011 Top 25 - Insecure Interaction Between Components) >
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.
URL Redirection to Untrusted Site ('Open Redirect')
- (601)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
864
(2011 Top 25 - Insecure Interaction Between Components) >
601
(URL Redirection to Untrusted Site ('Open Redirect'))
The web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a redirect.
Open Redirect
Cross-site Redirect
Cross-domain Redirect
Unvalidated Redirect
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
864
(2011 Top 25 - Insecure Interaction Between Components) >
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 injection
Shell metacharacters
OS 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)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
864
(2011 Top 25 - Insecure Interaction Between Components) >
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.
XSS
HTML Injection
CSS
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
864
(2011 Top 25 - Insecure Interaction Between Components) >
829
(Inclusion of Functionality from Untrusted Control Sphere)
The product imports, requires, or includes executable functionality (such as a library) from a source that is outside of the intended control sphere.
Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.
Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
- (89)
900
(Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors) >
864
(2011 Top 25 - Insecure Interaction Between Components) >
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 injection
SQLi
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-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-805: Buffer Access with Incorrect Length Value
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 uses a sequential operation to read or write a buffer, but it uses an incorrect length value that causes it to access memory that is outside of the bounds of the buffer.
When the length value exceeds the size of the destination, a buffer overflow could occur.
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 "CISQ Quality Measures (2020)" (CWE-1305)
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 C (Often Prevalent) C++ (Often Prevalent) Class: Assembly (Undetermined Prevalence) Example 1 This example takes an IP address from a user, verifies that it is well formed and then looks up the hostname and copies it into a buffer. (bad code)
Example Language: C
void host_lookup(char *user_supplied_addr){
struct hostent *hp;
in_addr_t *addr; char hostname[64]; in_addr_t inet_addr(const char *cp); /*routine that ensures user_supplied_addr is in the right format for conversion */ validate_addr_form(user_supplied_addr); addr = inet_addr(user_supplied_addr); hp = gethostbyaddr( addr, sizeof(struct in_addr), AF_INET); strcpy(hostname, hp->h_name); This function allocates a buffer of 64 bytes to store the hostname under the assumption that the maximum length value of hostname is 64 bytes, however there is no guarantee that the hostname will not be larger than 64 bytes. If an attacker specifies an address which resolves to a very large hostname, then the function may overwrite sensitive data or even relinquish control flow to the attacker. Note that this example also contains an unchecked return value (CWE-252) that can lead to a NULL pointer dereference (CWE-476). Example 2 In the following example, it is possible to request that memcpy move a much larger segment of memory than assumed: (bad code)
Example Language: C
int returnChunkSize(void *) {
/* if chunk info is valid, return the size of usable memory, * else, return -1 to indicate an error */ ... int main() { ... }memcpy(destBuf, srcBuf, (returnChunkSize(destBuf)-1)); ... If returnChunkSize() happens to encounter an error it will return -1. Notice that the return value is not checked before the memcpy operation (CWE-252), so -1 can be passed as the size argument to memcpy() (CWE-805). Because memcpy() assumes that the value is unsigned, it will be interpreted as MAXINT-1 (CWE-195), and therefore will copy far more memory than is likely available to the destination buffer (CWE-787, CWE-788). Example 3 In the following example, the source character string is copied to the dest character string using the method strncpy. (bad code)
Example Language: C
...
char source[21] = "the character string"; char dest[12]; strncpy(dest, source, sizeof(source)-1); ... However, in the call to strncpy the source character string is used within the sizeof call to determine the number of characters to copy. This will create a buffer overflow as the size of the source character string is greater than the dest character string. The dest character string should be used within the sizeof call to ensure that the correct number of characters are copied, as shown below. (good code)
Example Language: C
...
char source[21] = "the character string"; char dest[12]; strncpy(dest, source, sizeof(dest)-1); ... Example 4 In this example, the method outputFilenameToLog outputs a filename to a log file. The method arguments include a pointer to a character string containing the file name and an integer for the number of characters in the string. The filename is copied to a buffer where the buffer size is set to a maximum size for inputs to the log file. The method then calls another method to save the contents of the buffer to the log file. (bad code)
Example Language: C
#define LOG_INPUT_SIZE 40
// saves the file name to a log file int outputFilenameToLog(char *filename, int length) { int success;
// buffer with size set to maximum size for input to log file char buf[LOG_INPUT_SIZE]; // copy filename to buffer strncpy(buf, filename, length); // save to log file success = saveToLogFile(buf); return success; However, in this case the string copy method, strncpy, mistakenly uses the length method argument to determine the number of characters to copy rather than using the size of the local character string, buf. This can lead to a buffer overflow if the number of characters contained in character string pointed to by filename is larger then the number of characters allowed for the local character string. The string copy method should use the buf character string within a sizeof call to ensure that only characters up to the size of the buf array are copied to avoid a buffer overflow, as shown below. (good code)
Example Language: C
...
// copy filename to buffer strncpy(buf, filename, sizeof(buf)-1); ... Example 5 Windows provides the MultiByteToWideChar(), WideCharToMultiByte(), UnicodeToBytes(), and BytesToUnicode() functions to convert between arbitrary multibyte (usually ANSI) character strings and Unicode (wide character) strings. The size arguments to these functions are specified in different units, (one in bytes, the other in characters) making their use prone to error. In a multibyte character string, each character occupies a varying number of bytes, and therefore the size of such strings is most easily specified as a total number of bytes. In Unicode, however, characters are always a fixed size, and string lengths are typically given by the number of characters they contain. Mistakenly specifying the wrong units in a size argument can lead to a buffer overflow. The following function takes a username specified as a multibyte string and a pointer to a structure for user information and populates the structure with information about the specified user. Since Windows authentication uses Unicode for usernames, the username argument is first converted from a multibyte string to a Unicode string. (bad code)
Example Language: C
void getUserInfo(char *username, struct _USER_INFO_2 info){
WCHAR unicodeUser[UNLEN+1]; }MultiByteToWideChar(CP_ACP, 0, username, -1, unicodeUser, sizeof(unicodeUser)); NetUserGetInfo(NULL, unicodeUser, 2, (LPBYTE *)&info); This function incorrectly passes the size of unicodeUser in bytes instead of characters. The call to MultiByteToWideChar() can therefore write up to (UNLEN+1)*sizeof(WCHAR) wide characters, or (UNLEN+1)*sizeof(WCHAR)*sizeof(WCHAR) bytes, to the unicodeUser array, which has only (UNLEN+1)*sizeof(WCHAR) bytes allocated. If the username string contains more than UNLEN characters, the call to MultiByteToWideChar() will overflow the buffer unicodeUser.
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-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 FilterA race condition occurs within concurrent environments, and it is effectively a property of a code sequence. Depending on the context, a code sequence may be in the form of a function call, a small number of instructions, a series of program invocations, etc. A race condition violates these properties, which are closely related:
A race condition exists when an "interfering code sequence" can still access the shared resource, violating exclusivity. The interfering code sequence could be "trusted" or "untrusted." A trusted interfering code sequence occurs within the product; it cannot be modified by the attacker, and it can only be invoked indirectly. An untrusted interfering code sequence can be authored directly by the attacker, and typically it is external to the vulnerable product. 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.
|