CWE VIEW: Weaknesses in OWASP Top Ten (2004)
CWE entries in this view (graph) are associated with the OWASP Top Ten, as released in 2004, and as required for compliance with PCI DSS version 1.1. This view is considered obsolete as a newer version of the OWASP Top Ten is available.
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:
711 - Weaknesses in OWASP Top Ten (2004)
Category - a CWE entry that contains a set of other entries that share a common characteristic.OWASP Top Ten 2004 Category A1 - Unvalidated Input - (722) 711 (Weaknesses in OWASP Top Ten (2004)) > 722 (OWASP Top Ten 2004 Category A1 - Unvalidated Input) Weaknesses in this category are related to the A1 category in the OWASP Top Ten 2004. 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.Struts: Duplicate Validation Forms - (102) 711 (Weaknesses in OWASP Top Ten (2004)) > 722 (OWASP Top Ten 2004 Category A1 - Unvalidated Input) > 102 (Struts: Duplicate Validation Forms) The product uses multiple validation forms with the same name, which might cause the Struts Validator to validate a form that the programmer does not expect. 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.Struts: Incomplete validate() Method Definition - (103) 711 (Weaknesses in OWASP Top Ten (2004)) > 722 (OWASP Top Ten 2004 Category A1 - Unvalidated Input) > 103 (Struts: Incomplete validate() Method Definition) The product has a validator form that either does not define a validate() method, or defines a validate() method but does not call super.validate(). 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.Struts: Form Bean Does Not Extend Validation Class - (104) 711 (Weaknesses in OWASP Top Ten (2004)) > 722 (OWASP Top Ten 2004 Category A1 - Unvalidated Input) > 104 (Struts: Form Bean Does Not Extend Validation Class) If a form bean does not extend an ActionForm subclass of the Validator framework, it can expose the application to other weaknesses related to insufficient input validation. 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.Struts: Plug-in Framework not in Use - (106) 711 (Weaknesses in OWASP Top Ten (2004)) > 722 (OWASP Top Ten 2004 Category A1 - Unvalidated Input) > 106 (Struts: Plug-in Framework not in Use) When an application does not use an input validation framework such as the Struts Validator, there is a greater risk of introducing weaknesses related to insufficient input validation. 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.Struts: Validator Turned Off - (109) 711 (Weaknesses in OWASP Top Ten (2004)) > 722 (OWASP Top Ten 2004 Category A1 - Unvalidated Input) > 109 (Struts: Validator Turned Off) Automatic filtering via a Struts bean has been turned off, which disables the Struts Validator and custom validation logic. This exposes the application to other weaknesses related to insufficient input validation. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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) 711 (Weaknesses in OWASP Top Ten (2004)) > 722 (OWASP Top Ten 2004 Category A1 - Unvalidated Input) > 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.Improper Handling of Missing Special Element - (166) 711 (Weaknesses in OWASP Top Ten (2004)) > 722 (OWASP Top Ten 2004 Category A1 - Unvalidated Input) > 166 (Improper Handling of Missing Special Element) The product receives input from an upstream component, but it does not handle or incorrectly handles when an expected special element is missing. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 Additional Special Element - (167) 711 (Weaknesses in OWASP Top Ten (2004)) > 722 (OWASP Top Ten 2004 Category A1 - Unvalidated Input) > 167 (Improper Handling of Additional Special Element) The product receives input from an upstream component, but it does not handle or incorrectly handles when an additional unexpected special element is provided. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 Behavior Order: Early Validation - (179) 711 (Weaknesses in OWASP Top Ten (2004)) > 722 (OWASP Top Ten 2004 Category A1 - Unvalidated Input) > 179 (Incorrect Behavior Order: Early Validation) The product validates input before applying protection mechanisms that modify the input, which could allow an attacker to bypass the validation via dangerous inputs that only arise after the modification. 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.Incorrect Behavior Order: Validate Before Canonicalize - (180) 711 (Weaknesses in OWASP Top Ten (2004)) > 722 (OWASP Top Ten 2004 Category A1 - Unvalidated Input) > 180 (Incorrect Behavior Order: Validate Before Canonicalize) The product validates input before it is canonicalized, which prevents the product from detecting data that becomes invalid after the canonicalization step. 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.Incorrect Behavior Order: Validate Before Filter - (181) 711 (Weaknesses in OWASP Top Ten (2004)) > 722 (OWASP Top Ten 2004 Category A1 - Unvalidated Input) > 181 (Incorrect Behavior Order: Validate Before Filter) The product validates data before it has been filtered, which prevents the product from detecting data that becomes invalid after the filtering step.Validate-before-cleanse Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Collapse of Data into Unsafe Value - (182) 711 (Weaknesses in OWASP Top Ten (2004)) > 722 (OWASP Top Ten 2004 Category A1 - Unvalidated Input) > 182 (Collapse of Data into Unsafe Value) The product filters data in a way that causes it to be reduced or "collapsed" into an unsafe value that violates an expected security property. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Permissive List of Allowed Inputs - (183) 711 (Weaknesses in OWASP Top Ten (2004)) > 722 (OWASP Top Ten 2004 Category A1 - Unvalidated Input) > 183 (Permissive List of Allowed Inputs) The product implements a protection mechanism that relies on a list of inputs (or properties of inputs) that are explicitly allowed by policy because the inputs are assumed to be safe, but the list is too permissive - that is, it allows an input that is unsafe, leading to resultant weaknesses.Allowlist / Allow ListSafelist / Safe ListWhitelist / White List 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) 711 (Weaknesses in OWASP Top Ten (2004)) > 722 (OWASP Top Ten 2004 Category A1 - Unvalidated Input) > 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.Direct Request ('Forced Browsing') - (425) 711 (Weaknesses in OWASP Top Ten (2004)) > 722 (OWASP Top Ten 2004 Category A1 - Unvalidated Input) > 425 (Direct Request ('Forced Browsing')) The web application does not adequately enforce appropriate authorization on all restricted URLs, scripts, or files.forced browsing Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.External Control of Assumed-Immutable Web Parameter - (472) 711 (Weaknesses in OWASP Top Ten (2004)) > 722 (OWASP Top Ten 2004 Category A1 - Unvalidated Input) > 472 (External Control of Assumed-Immutable Web Parameter) The web application does not sufficiently verify inputs that are assumed to be immutable but are actually externally controllable, such as hidden form fields.Assumed-Immutable Parameter Tampering Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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) 711 (Weaknesses in OWASP Top Ten (2004)) > 722 (OWASP Top Ten 2004 Category A1 - Unvalidated Input) > 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 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.Client-Side Enforcement of Server-Side Security - (602) 711 (Weaknesses in OWASP Top Ten (2004)) > 722 (OWASP Top Ten 2004 Category A1 - Unvalidated Input) > 602 (Client-Side Enforcement of Server-Side Security) The product is composed of a server that relies on the client to implement a mechanism that is intended to protect the server. 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) 711 (Weaknesses in OWASP Top Ten (2004)) > 722 (OWASP Top Ten 2004 Category A1 - Unvalidated Input) > 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 Input During Web Page Generation ('Cross-site Scripting') - (79) 711 (Weaknesses in OWASP Top Ten (2004)) > 722 (OWASP Top Ten 2004 Category A1 - Unvalidated Input) > 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 Special Elements used in an SQL Command ('SQL Injection') - (89) 711 (Weaknesses in OWASP Top Ten (2004)) > 722 (OWASP Top Ten 2004 Category A1 - Unvalidated Input) > 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 Category - a CWE entry that contains a set of other entries that share a common characteristic.OWASP Top Ten 2004 Category A2 - Broken Access Control - (723) 711 (Weaknesses in OWASP Top Ten (2004)) > 723 (OWASP Top Ten 2004 Category A2 - Broken Access Control) Weaknesses in this category are related to the A2 category in the OWASP Top Ten 2004. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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) 711 (Weaknesses in OWASP Top Ten (2004)) > 723 (OWASP Top Ten 2004 Category A2 - Broken Access Control) > 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.Incorrect Privilege Assignment - (266) 711 (Weaknesses in OWASP Top Ten (2004)) > 723 (OWASP Top Ten 2004 Category A2 - Broken Access Control) > 266 (Incorrect Privilege Assignment) A product incorrectly assigns a privilege to a particular actor, creating an unintended sphere of control for that actor. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Privilege Chaining - (268) 711 (Weaknesses in OWASP Top Ten (2004)) > 723 (OWASP Top Ten 2004 Category A2 - Broken Access Control) > 268 (Privilege Chaining) Two distinct privileges, roles, capabilities, or rights can be combined in a way that allows an entity to perform unsafe actions that would not be allowed without that combination. Category - a CWE entry that contains a set of other entries that share a common characteristic.Permission Issues - (275) 711 (Weaknesses in OWASP Top Ten (2004)) > 723 (OWASP Top Ten 2004 Category A2 - Broken Access Control) > 275 (Permission Issues) Weaknesses in this category are related to improper assignment or handling of permissions. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Unverified Ownership - (283) 711 (Weaknesses in OWASP Top Ten (2004)) > 723 (OWASP Top Ten 2004 Category A2 - Broken Access Control) > 283 (Unverified Ownership) The product does not properly verify that a critical resource is owned by the proper entity. Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.Improper Access Control - (284) 711 (Weaknesses in OWASP Top Ten (2004)) > 723 (OWASP Top Ten 2004 Category A2 - Broken Access Control) > 284 (Improper Access Control) The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.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 Authorization - (285) 711 (Weaknesses in OWASP Top Ten (2004)) > 723 (OWASP Top Ten 2004 Category A2 - Broken Access Control) > 285 (Improper Authorization) The product does not perform or incorrectly performs 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.Use of Insufficiently Random Values - (330) 711 (Weaknesses in OWASP Top Ten (2004)) > 723 (OWASP Top Ten 2004 Category A2 - Broken Access Control) > 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.Improper Resolution of Path Equivalence - (41) 711 (Weaknesses in OWASP Top Ten (2004)) > 723 (OWASP Top Ten 2004 Category A2 - Broken Access Control) > 41 (Improper Resolution of Path Equivalence) The product is vulnerable to file system contents disclosure through path equivalence. Path equivalence involves the use of special characters in file and directory names. The associated manipulations are intended to generate multiple names for the same object. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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) 711 (Weaknesses in OWASP Top Ten (2004)) > 723 (OWASP Top Ten 2004 Category A2 - Broken Access Control) > 425 (Direct Request ('Forced Browsing')) The web application does not adequately enforce appropriate authorization on all restricted URLs, scripts, or files.forced browsing 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 Web Browser Cache Containing Sensitive Information - (525) 711 (Weaknesses in OWASP Top Ten (2004)) > 723 (OWASP Top Ten 2004 Category A2 - Broken Access Control) > 525 (Use of Web Browser Cache Containing Sensitive Information) The web application does not use an appropriate caching policy that specifies the extent to which each web page and associated form fields should be cached. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 Behavior Order: Authorization Before Parsing and Canonicalization - (551) 711 (Weaknesses in OWASP Top Ten (2004)) > 723 (OWASP Top Ten 2004 Category A2 - Broken Access Control) > 551 (Incorrect Behavior Order: Authorization Before Parsing and Canonicalization) If a web server does not fully parse requested URLs before it examines them for authorization, it may be possible for an attacker to bypass authorization protection. 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.ASP.NET Misconfiguration: Use of Identity Impersonation - (556) 711 (Weaknesses in OWASP Top Ten (2004)) > 723 (OWASP Top Ten 2004 Category A2 - Broken Access Control) > 556 (ASP.NET Misconfiguration: Use of Identity Impersonation) Configuring an ASP.NET application to run with impersonated credentials may give the application unnecessary privileges. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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) 711 (Weaknesses in OWASP Top Ten (2004)) > 723 (OWASP Top Ten 2004 Category A2 - Broken Access Control) > 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 Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 Ownership Assignment - (708) 711 (Weaknesses in OWASP Top Ten (2004)) > 723 (OWASP Top Ten 2004 Category A2 - Broken Access Control) > 708 (Incorrect Ownership Assignment) The product assigns an owner to a resource, but the owner 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.External Control of File Name or Path - (73) 711 (Weaknesses in OWASP Top Ten (2004)) > 723 (OWASP Top Ten 2004 Category A2 - Broken Access Control) > 73 (External Control of File Name or Path) The product allows user input to control or influence paths or file names that are used in filesystem operations. 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.J2EE Misconfiguration: Weak Access Permissions for EJB Methods - (9) 711 (Weaknesses in OWASP Top Ten (2004)) > 723 (OWASP Top Ten 2004 Category A2 - Broken Access Control) > 9 (J2EE Misconfiguration: Weak Access Permissions for EJB Methods) If elevated access rights are assigned to EJB methods, then an attacker can take advantage of the permissions to exploit the product. Category - a CWE entry that contains a set of other entries that share a common characteristic.OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management - (724) 711 (Weaknesses in OWASP Top Ten (2004)) > 724 (OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management) Weaknesses in this category are related to the A3 category in the OWASP Top Ten 2004. Category - a CWE entry that contains a set of other entries that share a common characteristic.Credentials Management Errors - (255) 711 (Weaknesses in OWASP Top Ten (2004)) > 724 (OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management) > 255 (Credentials Management Errors) Weaknesses in this category are related to the management of credentials. 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 Hard-coded Password - (259) 711 (Weaknesses in OWASP Top Ten (2004)) > 724 (OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management) > 259 (Use of Hard-coded Password) The product contains a hard-coded password, which it uses for its own inbound authentication or for outbound communication to external components. 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) 711 (Weaknesses in OWASP Top Ten (2004)) > 724 (OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management) > 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.Improper Following of a Certificate's Chain of Trust - (296) 711 (Weaknesses in OWASP Top Ten (2004)) > 724 (OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management) > 296 (Improper Following of a Certificate's Chain of Trust) The product does not follow, or incorrectly follows, the chain of trust for a certificate back to a trusted root certificate, resulting in incorrect trust of any resource that is associated with that certificate. 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 Certificate Expiration - (298) 711 (Weaknesses in OWASP Top Ten (2004)) > 724 (OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management) > 298 (Improper Validation of Certificate Expiration) A certificate expiration is not validated or is incorrectly validated, so trust may be assigned to certificates that have been abandoned due to age. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 Assumed-Immutable Data - (302) 711 (Weaknesses in OWASP Top Ten (2004)) > 724 (OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management) > 302 (Authentication Bypass by Assumed-Immutable Data) The authentication scheme or implementation uses key data elements that are assumed to be immutable, but can be controlled or modified by the attacker. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 Critical Step in Authentication - (304) 711 (Weaknesses in OWASP Top Ten (2004)) > 724 (OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management) > 304 (Missing Critical Step in Authentication) The product implements an authentication technique, but it skips a step that weakens the technique. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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) 711 (Weaknesses in OWASP Top Ten (2004)) > 724 (OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management) > 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.Use of Password System for Primary Authentication - (309) 711 (Weaknesses in OWASP Top Ten (2004)) > 724 (OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management) > 309 (Use of Password System for Primary Authentication) The use of password systems as the primary means of authentication may be subject to several flaws or shortcomings, each reducing the effectiveness of the 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.Insufficient Verification of Data Authenticity - (345) 711 (Weaknesses in OWASP Top Ten (2004)) > 724 (OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management) > 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. 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) 711 (Weaknesses in OWASP Top Ten (2004)) > 724 (OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management) > 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.Weak Password Requirements - (521) 711 (Weaknesses in OWASP Top Ten (2004)) > 724 (OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management) > 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) 711 (Weaknesses in OWASP Top Ten (2004)) > 724 (OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management) > 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. 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 Web Browser Cache Containing Sensitive Information - (525) 711 (Weaknesses in OWASP Top Ten (2004)) > 724 (OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management) > 525 (Use of Web Browser Cache Containing Sensitive Information) The web application does not use an appropriate caching policy that specifies the extent to which each web page and associated form fields should be cached. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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) 711 (Weaknesses in OWASP Top Ten (2004)) > 724 (OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management) > 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." Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Unverified Password Change - (620) 711 (Weaknesses in OWASP Top Ten (2004)) > 724 (OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management) > 620 (Unverified Password Change) When setting a new password for a user, the product does not require knowledge of the original password, or using another form of authentication. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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) 711 (Weaknesses in OWASP Top Ten (2004)) > 724 (OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management) > 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) 711 (Weaknesses in OWASP Top Ten (2004)) > 724 (OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management) > 798 (Use of Hard-coded Credentials) The product contains hard-coded credentials, such as a password or cryptographic key. Category - a CWE entry that contains a set of other entries that share a common characteristic.OWASP Top Ten 2004 Category A4 - Cross-Site Scripting (XSS) Flaws - (725) 711 (Weaknesses in OWASP Top Ten (2004)) > 725 (OWASP Top Ten 2004 Category A4 - Cross-Site Scripting (XSS) Flaws) Weaknesses in this category are related to the A4 category in the OWASP Top Ten 2004. 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 Neutralization of HTTP Headers for Scripting Syntax - (644) 711 (Weaknesses in OWASP Top Ten (2004)) > 725 (OWASP Top Ten 2004 Category A4 - Cross-Site Scripting (XSS) Flaws) > 644 (Improper Neutralization of HTTP Headers for Scripting Syntax) The product does not neutralize or incorrectly neutralizes web scripting syntax in HTTP headers that can be used by web browser components that can process raw headers, such as Flash. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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) 711 (Weaknesses in OWASP Top Ten (2004)) > 725 (OWASP Top Ten 2004 Category A4 - Cross-Site Scripting (XSS) Flaws) > 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 Category - a CWE entry that contains a set of other entries that share a common characteristic.OWASP Top Ten 2004 Category A5 - Buffer Overflows - (726) 711 (Weaknesses in OWASP Top Ten (2004)) > 726 (OWASP Top Ten 2004 Category A5 - Buffer Overflows) Weaknesses in this category are related to the A5 category in the OWASP Top Ten 2004. 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) 711 (Weaknesses in OWASP Top Ten (2004)) > 726 (OWASP Top Ten 2004 Category A5 - Buffer Overflows) > 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) 711 (Weaknesses in OWASP Top Ten (2004)) > 726 (OWASP Top Ten 2004 Category A5 - Buffer Overflows) > 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.Use of Externally-Controlled Format String - (134) 711 (Weaknesses in OWASP Top Ten (2004)) > 726 (OWASP Top Ten 2004 Category A5 - Buffer Overflows) > 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. Category - a CWE entry that contains a set of other entries that share a common characteristic.OWASP Top Ten 2004 Category A6 - Injection Flaws - (727) 711 (Weaknesses in OWASP Top Ten (2004)) > 727 (OWASP Top Ten 2004 Category A6 - Injection Flaws) Weaknesses in this category are related to the A6 category in the OWASP Top Ten 2004. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 Output Neutralization for Logs - (117) 711 (Weaknesses in OWASP Top Ten (2004)) > 727 (OWASP Top Ten 2004 Category A6 - Injection Flaws) > 117 (Improper Output Neutralization for Logs) The product does not neutralize or incorrectly neutralizes output that is written to logs. 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) 711 (Weaknesses in OWASP Top Ten (2004)) > 727 (OWASP Top Ten 2004 Category A6 - Injection Flaws) > 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. 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) 711 (Weaknesses in OWASP Top Ten (2004)) > 727 (OWASP Top Ten 2004 Category A6 - Injection Flaws) > 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) 711 (Weaknesses in OWASP Top Ten (2004)) > 727 (OWASP Top Ten 2004 Category A6 - Injection Flaws) > 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 Special Elements used in an SQL Command ('SQL Injection') - (89) 711 (Weaknesses in OWASP Top Ten (2004)) > 727 (OWASP Top Ten 2004 Category A6 - Injection Flaws) > 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) 711 (Weaknesses in OWASP Top Ten (2004)) > 727 (OWASP Top Ten 2004 Category A6 - Injection Flaws) > 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. 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 Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection') - (95) 711 (Weaknesses in OWASP Top Ten (2004)) > 727 (OWASP Top Ten 2004 Category A6 - Injection Flaws) > 95 (Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')) The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes code syntax before using the input in a dynamic evaluation call (e.g. "eval"). 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 Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion') - (98) 711 (Weaknesses in OWASP Top Ten (2004)) > 727 (OWASP Top Ten 2004 Category A6 - Injection Flaws) > 98 (Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')) The PHP application receives input from an upstream component, but it does not restrict or incorrectly restricts the input before its usage in "require," "include," or similar functions.Remote file includeRFILocal file inclusion Category - a CWE entry that contains a set of other entries that share a common characteristic.OWASP Top Ten 2004 Category A7 - Improper Error Handling - (728) 711 (Weaknesses in OWASP Top Ten (2004)) > 728 (OWASP Top Ten 2004 Category A7 - Improper Error Handling) Weaknesses in this category are related to the A7 category in the OWASP Top Ten 2004. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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) 711 (Weaknesses in OWASP Top Ten (2004)) > 728 (OWASP Top Ten 2004 Category A7 - Improper Error Handling) > 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) 711 (Weaknesses in OWASP Top Ten (2004)) > 728 (OWASP Top Ten 2004 Category A7 - Improper Error Handling) > 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. 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 Syntactically Invalid Structure - (228) 711 (Weaknesses in OWASP Top Ten (2004)) > 728 (OWASP Top Ten 2004 Category A7 - Improper Error Handling) > 228 (Improper Handling of Syntactically Invalid Structure) The product does not handle or incorrectly handles input that is not syntactically well-formed with respect to the associated specification. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Unchecked Return Value - (252) 711 (Weaknesses in OWASP Top Ten (2004)) > 728 (OWASP Top Ten 2004 Category A7 - Improper Error Handling) > 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. Category - a CWE entry that contains a set of other entries that share a common characteristic.Error Conditions, Return Values, Status Codes - (389) 711 (Weaknesses in OWASP Top Ten (2004)) > 728 (OWASP Top Ten 2004 Category A7 - Improper Error Handling) > 389 (Error Conditions, Return Values, Status Codes) This category includes weaknesses that occur if a function does not generate the correct return/status code, or if the application does not handle all possible return/status codes that could be generated by a function. This type of problem is most often found in conditions that are rarely encountered during the normal operation of the product. Presumably, most bugs related to common conditions are found and eliminated during development and testing. In some cases, the attacker can directly control or influence the environment to trigger the rare 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.Detection of Error Condition Without Action - (390) 711 (Weaknesses in OWASP Top Ten (2004)) > 728 (OWASP Top Ten 2004 Category A7 - Improper Error Handling) > 390 (Detection of Error Condition Without Action) The product detects a specific error, but takes no actions to handle the error. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 Error Condition - (391) 711 (Weaknesses in OWASP Top Ten (2004)) > 728 (OWASP Top Ten 2004 Category A7 - Improper Error Handling) > 391 (Unchecked Error Condition) [PLANNED FOR DEPRECATION. SEE MAINTENANCE NOTES AND CONSIDER CWE-252, CWE-248, OR CWE-1069.] Ignoring exceptions and other error conditions may allow an attacker to induce unexpected behavior unnoticed. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Unexpected Status Code or Return Value - (394) 711 (Weaknesses in OWASP Top Ten (2004)) > 728 (OWASP Top Ten 2004 Category A7 - Improper Error Handling) > 394 (Unexpected Status Code or Return Value) The product does not properly check when a function or operation returns a value that is legitimate for the function, but is not expected by the product. Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.Not Failing Securely ('Failing Open') - (636) 711 (Weaknesses in OWASP Top Ten (2004)) > 728 (OWASP Top Ten 2004 Category A7 - Improper Error Handling) > 636 (Not Failing Securely ('Failing Open')) When the product encounters an error condition or failure, its design requires it to fall back to a state that is less secure than other options that are available, such as selecting the weakest encryption algorithm or using the most permissive access control restrictions.Failing Open 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.J2EE Misconfiguration: Missing Custom Error Page - (7) 711 (Weaknesses in OWASP Top Ten (2004)) > 728 (OWASP Top Ten 2004 Category A7 - Improper Error Handling) > 7 (J2EE Misconfiguration: Missing Custom Error Page) The default error page of a web application should not display sensitive information about the product. Category - a CWE entry that contains a set of other entries that share a common characteristic.OWASP Top Ten 2004 Category A8 - Insecure Storage - (729) 711 (Weaknesses in OWASP Top Ten (2004)) > 729 (OWASP Top Ten 2004 Category A8 - Insecure Storage) Weaknesses in this category are related to the A8 category in the OWASP Top Ten 2004. 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.Compiler Removal of Code to Clear Buffers - (14) 711 (Weaknesses in OWASP Top Ten (2004)) > 729 (OWASP Top Ten 2004 Category A8 - Insecure Storage) > 14 (Compiler Removal of Code to Clear Buffers) Sensitive memory is cleared according to the source code, but compiler optimizations leave the memory untouched when it is not read from again, aka "dead store removal." Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Sensitive Information in Resource Not Removed Before Reuse - (226) 711 (Weaknesses in OWASP Top Ten (2004)) > 729 (OWASP Top Ten 2004 Category A8 - Insecure Storage) > 226 (Sensitive Information in Resource Not Removed Before Reuse) The product releases a resource such as memory or a file so that it can be made available for reuse, but it does not clear or "zeroize" the information contained in the resource before the product performs a critical state transition or makes the resource available for reuse by other entities. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 Encoding for Password - (261) 711 (Weaknesses in OWASP Top Ten (2004)) > 729 (OWASP Top Ten 2004 Category A8 - Insecure Storage) > 261 (Weak Encoding for Password) Obscuring a password with a trivial encoding does not protect the password. 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) 711 (Weaknesses in OWASP Top Ten (2004)) > 729 (OWASP Top Ten 2004 Category A8 - Insecure Storage) > 311 (Missing Encryption of Sensitive Data) The product does not encrypt sensitive or critical information before storage or transmission. 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 Hard-coded Cryptographic Key - (321) 711 (Weaknesses in OWASP Top Ten (2004)) > 729 (OWASP Top Ten 2004 Category A8 - Insecure Storage) > 321 (Use of Hard-coded Cryptographic Key) The use of a hard-coded cryptographic key significantly increases the possibility that encrypted data may be recovered. 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) 711 (Weaknesses in OWASP Top Ten (2004)) > 729 (OWASP Top Ten 2004 Category A8 - Insecure Storage) > 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) 711 (Weaknesses in OWASP Top Ten (2004)) > 729 (OWASP Top Ten 2004 Category A8 - Insecure Storage) > 327 (Use of a Broken or Risky Cryptographic Algorithm) The product uses a broken or risky cryptographic algorithm or protocol. 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 Persistent Cookies Containing Sensitive Information - (539) 711 (Weaknesses in OWASP Top Ten (2004)) > 729 (OWASP Top Ten 2004 Category A8 - Insecure Storage) > 539 (Use of Persistent Cookies Containing Sensitive Information) The web application uses persistent cookies, but the cookies contain sensitive information. 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.Sensitive Data Storage in Improperly Locked Memory - (591) 711 (Weaknesses in OWASP Top Ten (2004)) > 729 (OWASP Top Ten 2004 Category A8 - Insecure Storage) > 591 (Sensitive Data Storage in Improperly Locked Memory) The product stores sensitive data in memory that is not locked, or that has been incorrectly locked, which might cause the memory to be written to swap files on disk by the virtual memory manager. This can make the data more accessible to external 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 GET Request Method With Sensitive Query Strings - (598) 711 (Weaknesses in OWASP Top Ten (2004)) > 729 (OWASP Top Ten 2004 Category A8 - Insecure Storage) > 598 (Use of GET Request Method With Sensitive Query Strings) The web application uses the HTTP GET method to process a request and includes sensitive information in the query string of that request. Category - a CWE entry that contains a set of other entries that share a common characteristic.OWASP Top Ten 2004 Category A9 - Denial of Service - (730) 711 (Weaknesses in OWASP Top Ten (2004)) > 730 (OWASP Top Ten 2004 Category A9 - Denial of Service) Weaknesses in this category are related to the A9 category in the OWASP Top Ten 2004. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 Null Termination - (170) 711 (Weaknesses in OWASP Top Ten (2004)) > 730 (OWASP Top Ten 2004 Category A9 - Denial of Service) > 170 (Improper Null Termination) The product does not terminate or incorrectly terminates a string or array with a null character or equivalent terminator. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.Uncaught Exception - (248) 711 (Weaknesses in OWASP Top Ten (2004)) > 730 (OWASP Top Ten 2004 Category A9 - Denial of Service) > 248 (Uncaught Exception) An exception is thrown from a function, but it is not caught. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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) 711 (Weaknesses in OWASP Top Ten (2004)) > 730 (OWASP Top Ten 2004 Category A9 - Denial of Service) > 369 (Divide By Zero) The product divides a value by zero. 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.J2EE Bad Practices: Use of System.exit() - (382) 711 (Weaknesses in OWASP Top Ten (2004)) > 730 (OWASP Top Ten 2004 Category A9 - Denial of Service) > 382 (J2EE Bad Practices: Use of System.exit()) A J2EE application uses System.exit(), which also shuts down its container. 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) 711 (Weaknesses in OWASP Top Ten (2004)) > 730 (OWASP Top Ten 2004 Category A9 - Denial of Service) > 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 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) 711 (Weaknesses in OWASP Top Ten (2004)) > 730 (OWASP Top Ten 2004 Category A9 - Denial of Service) > 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 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) 711 (Weaknesses in OWASP Top Ten (2004)) > 730 (OWASP Top Ten 2004 Category A9 - Denial of Service) > 404 (Improper Resource Shutdown or Release) The product does not release or incorrectly releases a resource before it is made available for re-use. 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.Asymmetric Resource Consumption (Amplification) - (405) 711 (Weaknesses in OWASP Top Ten (2004)) > 730 (OWASP Top Ten 2004 Category A9 - Denial of Service) > 405 (Asymmetric Resource Consumption (Amplification)) The product does not properly control situations in which an adversary can cause the product to consume or produce excessive resources without requiring the adversary to invest equivalent work or otherwise prove authorization, i.e., the adversary's influence is "asymmetric." Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 Resource Pool - (410) 711 (Weaknesses in OWASP Top Ten (2004)) > 730 (OWASP Top Ten 2004 Category A9 - Denial of Service) > 410 (Insufficient Resource Pool) The product's resource pool is not large enough to handle peak demand, which allows an attacker to prevent others from accessing the resource by using a (relatively) large number of requests for 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.Unrestricted Externally Accessible Lock - (412) 711 (Weaknesses in OWASP Top Ten (2004)) > 730 (OWASP Top Ten 2004 Category A9 - Denial of Service) > 412 (Unrestricted Externally Accessible Lock) The product properly checks for the existence of a lock, but the lock can be externally controlled or influenced by an actor that is outside of the intended sphere of control. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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) 711 (Weaknesses in OWASP Top Ten (2004)) > 730 (OWASP Top Ten 2004 Category A9 - Denial of Service) > 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.Uncontrolled Recursion - (674) 711 (Weaknesses in OWASP Top Ten (2004)) > 730 (OWASP Top Ten 2004 Category A9 - Denial of Service) > 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 Category - a CWE entry that contains a set of other entries that share a common characteristic.OWASP Top Ten 2004 Category A10 - Insecure Configuration Management - (731) 711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) Weaknesses in this category are related to the A10 category in the OWASP Top Ten 2004. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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) 711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 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 Debugging Code - (215) 711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 215 (Insertion of Sensitive Information Into Debugging Code) The product inserts sensitive information into debugging code, which could expose this information if the debugging code is not disabled in production. 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.Storage of File with Sensitive Data Under Web Root - (219) 711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 219 (Storage of File with Sensitive Data Under Web Root) The product stores sensitive data under the web document root with insufficient access control, which might make it accessible to untrusted parties. Category - a CWE entry that contains a set of other entries that share a common characteristic.Permission Issues - (275) 711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 275 (Permission Issues) Weaknesses in this category are related to improper assignment or handling of permissions. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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) 711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 295 (Improper Certificate Validation) The product does not validate, or incorrectly validates, a certificate. 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.J2EE Misconfiguration: Data Transmission Without Encryption - (5) 711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 5 (J2EE Misconfiguration: Data Transmission Without Encryption) Information sent over a network can be compromised while in transit. An attacker may be able to read or modify the contents if the data are sent in plaintext or are weakly encrypted. 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.J2EE Misconfiguration: Plaintext Password in Configuration File - (555) 711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 555 (J2EE Misconfiguration: Plaintext Password in Configuration File) The J2EE application stores a plaintext password in a configuration file. 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.J2EE Misconfiguration: Insufficient Session-ID Length - (6) 711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 6 (J2EE Misconfiguration: Insufficient Session-ID Length) The J2EE application is configured to use an insufficient session ID length. 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.J2EE Misconfiguration: Missing Custom Error Page - (7) 711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 7 (J2EE Misconfiguration: Missing Custom Error Page) The default error page of a web application should not display sensitive information about the product. 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.J2EE Misconfiguration: Entity Bean Declared Remote - (8) 711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 8 (J2EE Misconfiguration: Entity Bean Declared Remote) When an application exposes a remote interface for an entity bean, it might also expose methods that get or set the bean's data. These methods could be leveraged to read sensitive information, or to change data in ways that violate the application's expectations, potentially leading to other vulnerabilities. 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.J2EE Misconfiguration: Weak Access Permissions for EJB Methods - (9) 711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 9 (J2EE Misconfiguration: Weak Access Permissions for EJB Methods) If elevated access rights are assigned to EJB methods, then an attacker can take advantage of the permissions to exploit 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.Incomplete Cleanup - (459) 711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 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.Active Debug Code - (489) 711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 489 (Active Debug Code) The product is deployed to unauthorized actors with debugging code still enabled or active, which can create unintended entry points or expose sensitive information.Leftover debug code 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.ASP.NET Misconfiguration: Creating Debug Binary - (11) 711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 11 (ASP.NET Misconfiguration: Creating Debug Binary) Debugging messages help attackers learn about the system and plan a form of attack. 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.ASP.NET Misconfiguration: Missing Custom Error Page - (12) 711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 12 (ASP.NET Misconfiguration: Missing Custom Error Page) An ASP .NET application must enable custom error pages in order to prevent attackers from mining information from the framework's built-in responses. 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.ASP.NET Misconfiguration: Password in Configuration File - (13) 711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 13 (ASP.NET Misconfiguration: Password in Configuration File) Storing a plaintext password in a configuration file allows anyone who can read the file access to the password-protected resource making them an easy target for attackers. 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..NET Misconfiguration: Use of Impersonation - (520) 711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 520 (.NET Misconfiguration: Use of Impersonation) Allowing a .NET application to run at potentially escalated levels of access to the underlying operating and file systems can be dangerous and result in various forms of attacks. 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.ASP.NET Misconfiguration: Not Using Input Validation Framework - (554) 711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 554 (ASP.NET Misconfiguration: Not Using Input Validation Framework) The ASP.NET application does not use an input validation framework. 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.ASP.NET Misconfiguration: Use of Identity Impersonation - (556) 711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 556 (ASP.NET Misconfiguration: Use of Identity Impersonation) Configuring an ASP.NET application to run with impersonated credentials may give the application unnecessary privileges. 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.Cleartext Storage of Sensitive Information in an Environment Variable - (526) 711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 526 (Cleartext Storage of Sensitive Information in an Environment Variable) The product uses an environment variable to store unencrypted sensitive information. 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.Exposure of Version-Control Repository to an Unauthorized Control Sphere - (527) 711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 527 (Exposure of Version-Control Repository to an Unauthorized Control Sphere) The product stores a CVS, git, or other repository in a directory, archive, or other resource that is stored, transferred, or otherwise made accessible to unauthorized 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.Exposure of Core Dump File to an Unauthorized Control Sphere - (528) 711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 528 (Exposure of Core Dump File to an Unauthorized Control Sphere) The product generates a core dump file in a directory, archive, or other resource that is stored, transferred, or otherwise made accessible to unauthorized 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.Exposure of Access Control List Files to an Unauthorized Control Sphere - (529) 711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 529 (Exposure of Access Control List Files to an Unauthorized Control Sphere) The product stores access control list files in a directory or other container that is accessible to actors outside of the intended control sphere. 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.Exposure of Backup File to an Unauthorized Control Sphere - (530) 711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 530 (Exposure of Backup File to an Unauthorized Control Sphere) A backup file is stored in a directory or archive that is made accessible to unauthorized 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.Inclusion of Sensitive Information in Test Code - (531) 711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 531 (Inclusion of Sensitive Information in Test Code) Accessible test applications can pose a variety of security risks. Since developers or administrators rarely consider that someone besides themselves would even know about the existence of these applications, it is common for them to contain sensitive information or functions. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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) 711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 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. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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 Sensitive Information in Source Code - (540) 711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 540 (Inclusion of Sensitive Information in Source Code) Source code on a web server or repository often contains sensitive information and should generally not be accessible to users. 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.Inclusion of Sensitive Information in an Include File - (541) 711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 541 (Inclusion of Sensitive Information in an Include File) If an include file source is accessible, the file can contain usernames and passwords, as well as sensitive information pertaining to the application and system. 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.Exposure of Information Through Directory Listing - (548) 711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 548 (Exposure of Information Through Directory Listing) A directory listing is inappropriately exposed, yielding potentially sensitive information to attackers. Base - a weakness
that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection 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) 711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 552 (Files or Directories Accessible to External Parties) The product makes files or directories accessible to unauthorized actors, even though they should not be.
Relationship CWE relationships for this view were obtained by examining the OWASP document and mapping to any items that were specifically mentioned within the text of a category. As a result, this mapping is not complete with respect to all of CWE. In addition, some concepts were mentioned in multiple Top Ten items, which caused them to be mapped to multiple CWE categories. For example, SQL injection is mentioned in both A1 (CWE-722) and A6 (CWE-727) categories. Relationship As of 2008, some parts of CWE were not fully clarified out in terms of weaknesses. When these areas were mentioned in the OWASP Top Ten, category entries were mapped, although general mapping practice would usually favor mapping only to weaknesses.
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-489: Active Debug Code
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 is deployed to unauthorized actors with debugging code still enabled or active, which can create unintended entry points or expose sensitive information. A common development practice is to add "back door" code specifically designed for debugging or testing purposes that is not intended to be shipped or deployed with the product. These back door entry points create security risks because they are not considered during design or testing and fall outside of the expected operating conditions of the 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 "Software Development" (CWE-699)
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: Not Technology-Specific (Undetermined Prevalence) Class: ICS/OT (Undetermined Prevalence) Example 1 Debug code can be used to bypass authentication. For example, suppose an application has a login script that receives a username and a password. Assume also that a third, optional, parameter, called "debug", is interpreted by the script as requesting a switch to debug mode, and that when this parameter is given the username and password are not checked. In such a case, it is very simple to bypass the authentication process if the special behavior of the application regarding the debug parameter is known. In a case where the form is: (bad code) Example Language: HTML <FORM ACTION="/authenticate_login.cgi">
<INPUT TYPE=TEXT name=username> </FORM><INPUT TYPE=PASSWORD name=password> <INPUT TYPE=SUBMIT> Then a conforming link will look like: (informative) http://TARGET/authenticate_login.cgi?username=...&password=...
An attacker can change this to: (attack code) http://TARGET/authenticate_login.cgi?username=&password=&debug=1
Which will grant the attacker access to the site, bypassing the authentication process.
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.
Other In J2EE a main method may be a good indicator that debug code has been left in the application, although there may not be any direct security impact.
CWE-11: ASP.NET Misconfiguration: Creating Debug Binary
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 FilterASP .NET applications can be configured to produce debug binaries. These binaries give detailed debugging messages and should not be used in production environments. Debug binaries are meant to be used in a development or testing environment and can pose a security risk if they are deployed to production. 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)
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 ASP.NET (Undetermined Prevalence) Example 1 The file web.config contains the debug mode setting. Setting debug to "true" will let the browser display debugging information. (bad code) Example Language: XML <?xml version="1.0" encoding="utf-8" ?>
<configuration> <system.web> </configuration><compilation </system.web>defaultLanguage="c#" debug="true" /> ... Change the debug mode to false when the application is deployed into production.
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-12: ASP.NET Misconfiguration: Missing Custom Error Page
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 FilterAn ASP .NET application must enable custom error pages in order to prevent attackers from mining information from the framework's built-in responses. 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)
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 ASP.NET (Undetermined Prevalence) Example 1 The mode attribute of the <customErrors> tag in the Web.config file defines whether custom or default error pages are used. In the following insecure ASP.NET application setting, custom error message mode is turned off. An ASP.NET error message with detailed stack trace and platform versions will be returned. (bad code) Example Language: ASP.NET <customErrors mode="Off" />
A more secure setting is to set the custom error message mode for remote users only. No defaultRedirect error page is specified. The local user on the web server will see a detailed stack trace. For remote users, an ASP.NET error message with the server customError configuration setting and the platform version will be returned. (good code) Example Language: ASP.NET <customErrors mode="RemoteOnly" />
Another secure option is to set the mode attribute of the <customErrors> tag to use a custom page as follows: (good code) Example Language: ASP.NET <customErrors mode="On" defaultRedirect="YourErrorPage.htm" />
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-554: ASP.NET Misconfiguration: Not Using Input Validation Framework
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 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)
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 ASP.NET (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-13: ASP.NET Misconfiguration: Password in Configuration File
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 FilterStoring a plaintext password in a configuration file allows anyone who can read the file access to the password-protected resource making them an easy target for attackers. 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)
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 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 plaintext. (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 plaintext as this will allow anyone who can read the file access to the resource. If possible, encrypt this information. 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-556: ASP.NET Misconfiguration: Use of Identity Impersonation
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 FilterConfiguring an ASP.NET application to run with impersonated credentials may give the application unnecessary privileges. The use of impersonated credentials allows an ASP.NET application to run with either the privileges of the client on whose behalf it is executing or with arbitrary privileges granted in its configuration. 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)
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 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-405: Asymmetric Resource Consumption (Amplification)
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 does not properly control situations in which an adversary can cause the product to consume or produce excessive resources without requiring the adversary to invest equivalent work or otherwise prove authorization, i.e., the adversary's influence is "asymmetric." This can lead to poor performance due to "amplification" of resource consumption, typically in a non-linear fashion. This situation is worsened if the product allows malicious users or attackers to consume more resources than their access level permits. 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)
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) Operating Systems Class: Not OS-Specific (Undetermined Prevalence) Architectures Class: Not Architecture-Specific (Undetermined Prevalence) Technologies Class: Not Technology-Specific (Undetermined Prevalence) Class: Client Server (Undetermined Prevalence) Example 1 This code listens on a port for DNS requests and sends the result to the requesting address. (bad code) Example Language: Python sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind( (UDP_IP,UDP_PORT) ) while true: data = sock.recvfrom(1024)
if not data: break
(requestIP, nameToResolve) = parseUDPpacket(data) record = resolveName(nameToResolve) sendResponse(requestIP,record) This code sends a DNS record to a requesting IP address. UDP allows the source IP address to be easily changed ('spoofed'), thus allowing an attacker to redirect responses to a target, which may be then be overwhelmed by the network traffic. Example 2 This function prints the contents of a specified file requested by a user. (bad code) Example Language: PHP function printFile($username,$filename){
//read file into string $file = file_get_contents($filename); if ($file && isOwnerOf($username,$filename)){ echo $file; }return true; else{ echo 'You are not authorized to view this file'; }return false; This code first reads a specified file into memory, then prints the file if the user is authorized to see its contents. The read of the file into memory may be resource intensive and is unnecessary if the user is not allowed to see the file anyway. Example 3 The DTD and the very brief XML below illustrate what is meant by an XML bomb. The ZERO entity contains one character, the letter A. The choice of entity name ZERO is being used to indicate length equivalent to that exponent on two, that is, the length of ZERO is 2^0. Similarly, ONE refers to ZERO twice, therefore the XML parser will expand ONE to a length of 2, or 2^1. Ultimately, we reach entity THIRTYTWO, which will expand to 2^32 characters in length, or 4 GB, probably consuming far more data than expected. (attack code) Example Language: XML <?xml version="1.0"?>
<!DOCTYPE MaliciousDTD [ <!ENTITY ZERO "A"> <!ENTITY ONE "&ZERO;&ZERO;"> <!ENTITY TWO "&ONE;&ONE;"> ... <!ENTITY THIRTYTWO "&THIRTYONE;&THIRTYONE;"> ]> <data>&THIRTYTWO;</data> Example 4 This example attempts to check if an input string is a "sentence" [REF-1164]. (bad code) Example Language: JavaScript
var test_string = "Bad characters: $@#"; var bad_pattern = /^(\w+\s?)*$/i; var result = test_string.search(bad_pattern); The regular expression has a vulnerable backtracking clause inside (\w+\s?)*$ which can be triggered to cause a Denial of Service by processing particular phrases. To fix the backtracking problem, backtracking is removed with the ?= portion of the expression which changes it to a lookahead and the \2 which prevents the backtracking. The modified example is: (good code) Example Language: JavaScript
var test_string = "Bad characters: $@#"; var good_pattern = /^((?=(\w+))\2\s?)*$/i; var result = test_string.search(good_pattern); Note that [REF-1164] has a more thorough (and lengthy) explanation of everything going on within the RegEx. Example 5 An adversary can cause significant resource consumption on a server by filtering the cryptographic algorithms offered by the client to the ones that are the most resource-intensive on the server side. After discovering which cryptographic algorithms are supported by the server, a malicious client can send the initial cryptographic handshake messages that contains only the resource-intensive algorithms. For some cryptographic protocols, these messages can be completely prefabricated, as the resource-intensive part of the handshake happens on the server-side first (such as TLS), rather than on the client side. In the case of cryptographic protocols where the resource-intensive part should happen on the client-side first (such as SSH), a malicious client can send a forged/precalculated computation result, which seems correct to the server, so the resource-intensive part of the handshake is going to happen on the server side. A malicious client is required to send only the initial messages of a cryptographic handshake to initiate the resource-consuming part of the cryptographic handshake. These messages are usually small, and generating them requires minimal computational effort, enabling a denial-of-service attack. An additional risk is the fact that higher key size increases the effectiveness of the attack. Cryptographic protocols where the clients have influence over the size of the used key (such as TLS 1.3 or SSH) are most at risk, as the client can enforce the highest key size supported by the server.
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-302: Authentication Bypass by Assumed-Immutable 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 authentication scheme or implementation uses key data elements that are assumed to be immutable, but can be controlled or modified by the attacker. 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 "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) Example 1 In the following example, an "authenticated" cookie is used to determine whether or not a user should be granted access to a system. (bad code) Example Language: Java boolean authenticated = new Boolean(getCookieValue("authenticated")).booleanValue();
if (authenticated) { ... }Modifying the value of a cookie on the client-side is trivial, but many developers assume that cookies are essentially immutable.
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-526: Cleartext Storage of Sensitive Information in an Environment Variable
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 FilterInformation stored in an environment variable can be accessible by other processes with the execution context, including child processes that dependencies are executed in, or serverless functions in cloud environments. An environment variable's contents can also be inserted into messages, headers, log files, or other outputs. Often these other dependencies have no need to use the environment variable in question. A weakness that discloses environment variables could expose this 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)
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 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-602: Client-Side Enforcement of Server-Side Security
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 is composed of a server that relies on the client to implement a mechanism that is intended to protect the server. When the server relies on protection mechanisms placed on the client side, an attacker can modify the client-side behavior to bypass the protection mechanisms, resulting in potentially unexpected interactions between the client and server. The consequences will vary, depending on what the mechanisms are trying to protect. 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 "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: ICS/OT (Undetermined Prevalence) Class: Mobile (Undetermined Prevalence) Example 1 This example contains client-side code that checks if the user authenticated successfully before sending a command. The server-side code performs the authentication in one step, and executes the command in a separate step. CLIENT-SIDE (client.pl) (good code) Example Language: Perl $server = "server.example.com";
$username = AskForUserName(); $password = AskForPassword(); $address = AskForAddress(); $sock = OpenSocket($server, 1234); writeSocket($sock, "AUTH $username $password\n"); $resp = readSocket($sock); if ($resp eq "success") { # username/pass is valid, go ahead and update the info! writeSocket($sock, "CHANGE-ADDRESS $username $address\n"; else { print "ERROR: Invalid Authentication!\n"; }SERVER-SIDE (server.pl): (bad code) $sock = acceptSocket(1234);
($cmd, $args) = ParseClientRequest($sock); if ($cmd eq "AUTH") { ($username, $pass) = split(/\s+/, $args, 2);
$result = AuthenticateUser($username, $pass); writeSocket($sock, "$result\n"); # does not close the socket on failure; assumes the # user will try again elsif ($cmd eq "CHANGE-ADDRESS") { if (validateAddress($args)) { }$res = UpdateDatabaseRecord($username, "address", $args); }writeSocket($sock, "SUCCESS\n"); else { writeSocket($sock, "FAILURE -- address is malformed\n"); }The server accepts 2 commands, "AUTH" which authenticates the user, and "CHANGE-ADDRESS" which updates the address field for the username. The client performs the authentication and only sends a CHANGE-ADDRESS for that user if the authentication succeeds. Because the client has already performed the authentication, the server assumes that the username in the CHANGE-ADDRESS is the same as the authenticated user. An attacker could modify the client by removing the code that sends the "AUTH" command and simply executing the CHANGE-ADDRESS. Example 2 In 2022, the OT:ICEFALL study examined products by 10 different Operational Technology (OT) vendors. The researchers reported 56 vulnerabilities and said that the products were "insecure by design" [REF-1283]. If exploited, these vulnerabilities often allowed adversaries to change how the products operated, ranging from denial of service to changing the code that the products executed. Since these products were often used in industries such as power, electrical, water, and others, there could even be safety implications. Multiple vendors used client-side authentication in their OT products.
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-182: Collapse of Data into Unsafe 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 filters data in a way that causes it to be reduced or "collapsed" into an unsafe value that violates an expected security property. 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)
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.
Relationship Overlaps regular expressions, although an implementation might not necessarily use regexp's.
CWE-14: Compiler Removal of Code to Clear Buffers
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 FilterSensitive memory is cleared according to the source code, but compiler optimizations leave the memory untouched when it is not read from again, aka "dead store removal." This compiler optimization error occurs when:
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)
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 reads a password from the user, uses the password to connect to a back-end mainframe and then attempts to scrub the password from memory using memset(). (bad code) Example Language: C void GetData(char *MFAddr) {
char pwd[64];
if (GetPasswordFromUser(pwd, sizeof(pwd))) { if (ConnectToMainframe(MFAddr, pwd)) { // Interaction with mainframe memset(pwd, 0, sizeof(pwd)); The code in the example will behave correctly if it is executed verbatim, but if the code is compiled using an optimizing compiler, such as Microsoft Visual C++ .NET or GCC 3.x, then the call to memset() will be removed as a dead store because the buffer pwd is not used after its value is overwritten [18]. Because the buffer pwd contains a sensitive value, the application may be vulnerable to attack if the data are left memory resident. If attackers are able to access the correct region of memory, they may use the recovered password to gain control of the system. It is common practice to overwrite sensitive data manipulated in memory, such as passwords or cryptographic keys, in order to prevent attackers from learning system secrets. However, with the advent of optimizing compilers, programs do not always behave as their source code alone would suggest. In the example, the compiler interprets the call to memset() as dead code because the memory being written to is not subsequently used, despite the fact that there is clearly a security motivation for the operation to occur. The problem here is that many compilers, and in fact many programming languages, do not take this and other security concerns into consideration in their efforts to improve efficiency. Attackers typically exploit this type of vulnerability by using a core dump or runtime mechanism to access the memory used by a particular application and recover the secret information. Once an attacker has access to the secret information, it is relatively straightforward to further exploit the system and possibly compromise other resources with which the application interacts.
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 CATEGORY: Credentials Management Errors
CWE-390: Detection of Error Condition Without Action
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 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 "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) Example 1 The following example attempts to allocate memory for a character. After the call to malloc, an if statement is used to check whether the malloc function failed. (bad code) Example Language: C foo=malloc(sizeof(char)); //the next line checks to see if malloc failed
if (foo==NULL) { //We do nothing so we just ignore the error. }The conditional successfully detects a NULL return value from malloc indicating a failure, however it does not do anything to handle the problem. Unhandled errors may have unexpected results and may cause the program to crash or terminate. Instead, the if block should contain statements that either attempt to fix the problem or notify the user that an error has occurred and continue processing or perform some cleanup and gracefully terminate the program. The following example notifies the user that the malloc function did not allocate the required memory resources and returns an error code. (good code) Example Language: C foo=malloc(sizeof(char)); //the next line checks to see if malloc failed
if (foo==NULL) { printf("Malloc failed to allocate memory resources"); }return -1; Example 2 In the following C++ example the method readFile() will read the file whose name is provided in the input parameter and will return the contents of the file in char string. The method calls open() and read() may result in errors if the file does not exist or does not contain any data to read. These errors will be thrown when the is_open() method and good() method indicate errors opening or reading the file. However, these errors are not handled within the catch statement. Catch statements that do not perform any processing will have unexpected results. In this case an empty char string will be returned, and the file will not be properly closed. (bad code) Example Language: C++ char* readfile (char *filename) {
try {
// open input file
ifstream infile; infile.open(filename); if (!infile.is_open()) { throw "Unable to open file " + filename; }// get length of file infile.seekg (0, ios::end); int length = infile.tellg(); infile.seekg (0, ios::beg); // allocate memory char *buffer = new char [length]; // read data from file infile.read (buffer,length); if (!infile.good()) { throw "Unable to read from file " + filename; }infile.close(); return buffer; catch (...) { /* bug: insert code to handle this later */ }The catch statement should contain statements that either attempt to fix the problem or notify the user that an error has occurred and continue processing or perform some cleanup and gracefully terminate the program. The following C++ example contains two catch statements. The first of these will catch a specific error thrown within the try block, and the second catch statement will catch all other errors from within the catch block. Both catch statements will notify the user that an error has occurred, close the file, and rethrow to the block that called the readFile() method for further handling or possible termination of the program. (good code) Example Language: C++ char* readFile (char *filename) {
try {
// open input file
ifstream infile; infile.open(filename); if (!infile.is_open()) { throw "Unable to open file " + filename; }// get length of file infile.seekg (0, ios::end); int length = infile.tellg(); infile.seekg (0, ios::beg); // allocate memory char *buffer = new char [length]; // read data from file infile.read (buffer,length); if (!infile.good()) { throw "Unable to read from file " + filename; }infile.close(); return buffer; catch (char *str) { printf("Error: %s \n", str); }infile.close(); throw str; catch (...) { printf("Error occurred trying to read from file \n"); }infile.close(); throw; Example 3 In the following Java example the method readFile will read the file whose name is provided in the input parameter and will return the contents of the file in a String object. The constructor of the FileReader object and the read method call may throw exceptions and therefore must be within a try/catch block. While the catch statement in this example will catch thrown exceptions in order for the method to compile, no processing is performed to handle the thrown exceptions. Catch statements that do not perform any processing will have unexpected results. In this case, this will result in the return of a null String. (bad code) Example Language: Java public String readFile(String filename) {
String retString = null;
try { // initialize File and FileReader objects
File file = new File(filename); FileReader fr = new FileReader(file); // initialize character buffer long fLen = file.length(); char[] cBuf = new char[(int) fLen]; // read data from file int iRead = fr.read(cBuf, 0, (int) fLen); // close file fr.close(); retString = new String(cBuf); /* do nothing, but catch so it'll compile... */ }return retString; The catch statement should contain statements that either attempt to fix the problem, notify the user that an exception has been raised and continue processing, or perform some cleanup and gracefully terminate the program. The following Java example contains three catch statements. The first of these will catch the FileNotFoundException that may be thrown by the FileReader constructor called within the try/catch block. The second catch statement will catch the IOException that may be thrown by the read method called within the try/catch block. The third catch statement will catch all other exceptions thrown within the try block. For all catch statements the user is notified that the exception has been thrown and the exception is rethrown to the block that called the readFile() method for further processing or possible termination of the program. Note that with Java it is usually good practice to use the getMessage() method of the exception class to provide more information to the user about the exception raised. (good code) Example Language: Java public String readFile(String filename) throws FileNotFoundException, IOException, Exception {
String retString = null;
try { // initialize File and FileReader objects
File file = new File(filename); FileReader fr = new FileReader(file); // initialize character buffer long fLen = file.length(); char [] cBuf = new char[(int) fLen]; // read data from file int iRead = fr.read(cBuf, 0, (int) fLen); // close file fr.close(); retString = new String(cBuf); System.err.println ("Error: FileNotFoundException opening the input file: " + filename ); } catch (IOException ex) {System.err.println ("" + ex.getMessage() ); throw new FileNotFoundException(ex.getMessage()); System.err.println("Error: IOException reading the input file.\n" + ex.getMessage() ); } catch (Exception ex) {throw new IOException(ex); System.err.println("Error: Exception reading the input file.\n" + ex.getMessage() ); }throw new Exception(ex); return retString;
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-425: Direct Request ('Forced Browsing')
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 adequately enforce appropriate authorization on all restricted URLs, scripts, or files. Web applications susceptible to direct request attacks often make the false assumption that such resources can only be reached through a given navigation path and so only apply authorization at certain points in the path.
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: Web Based (Undetermined Prevalence) Example 1 If forced browsing is possible, an attacker may be able to directly access a sensitive page by entering a URL similar to the following. (attack code) Example Language: JSP http://somesite.com/someapplication/admin.jsp
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 Overlaps Modification of Assumed-Immutable Data (MAID), authorization errors, container errors; often primary to other weaknesses such as XSS and SQL injection. Theoretical "Forced browsing" is a step-based manipulation involving the omission of one or more steps, whose order is assumed to be immutable. The application does not verify that the first step was performed successfully before the second step. The consequence is typically "authentication bypass" or "path disclosure," although it can be primary to all kinds of weaknesses, especially in languages such as PHP, which allow external modification of assumed-immutable variables.
CWE-369: Divide By Zero
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 weakness typically occurs when an unexpected value is provided to the product, or if an error occurs that is not properly detected. It frequently occurs in calculations involving physical dimensions such as size, length, width, and height. 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)
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 Java example contains a function to compute an average but does not validate that the input value used as the denominator is not zero. This will create an exception for attempting to divide by zero. If this error is not handled by Java exception handling, unexpected results can occur. (bad code) Example Language: Java public int computeAverageResponseTime (int totalTime, int numRequests) {
return totalTime / numRequests; }By validating the input value used as the denominator the following code will ensure that a divide by zero error will not cause unexpected results. The following Java code example will validate the input value, output an error message, and throw an exception. (good code) public int computeAverageResponseTime (int totalTime, int numRequests) throws ArithmeticException {
if (numRequests == 0) { }System.out.println("Division by zero attempted!"); }throw ArithmeticException; return totalTime / numRequests; Example 2 The following C/C++ example contains a function that divides two numeric values without verifying that the input value used as the denominator is not zero. This will create an error for attempting to divide by zero, if this error is not caught by the error handling capabilities of the language, unexpected results can occur. (bad code) Example Language: C double divide(double x, double y){
return x/y; }By validating the input value used as the denominator the following code will ensure that a divide by zero error will not cause unexpected results. If the method is called and a zero is passed as the second argument a DivideByZero error will be thrown and should be caught by the calling block with an output message indicating the error. (good code) const int DivideByZero = 10;
double divide(double x, double y){ if ( 0 == y ){ }throw DivideByZero; }return x/y; ... try{ divide(10, 0); }catch( int i ){ if(i==DivideByZero) { }cerr<<"Divide by zero error"; }
Example 3 The following C# example contains a function that divides two numeric values without verifying that the input value used as the denominator is not zero. This will create an error for attempting to divide by zero, if this error is not caught by the error handling capabilities of the language, unexpected results can occur. (bad code) Example Language: C# int Division(int x, int y){
return (x / y); }The method can be modified to raise, catch and handle the DivideByZeroException if the input value used as the denominator is zero. (good code) int SafeDivision(int x, int y){
try{ }return (x / y); }catch (System.DivideByZeroException dbz){ System.Console.WriteLine("Division by zero attempted!"); }return 0;
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.
|