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-678: Composites (2.10)  
ID

CWE VIEW: Composites

Mapping-Friendly:
View ID: 678
Structure: Graph
Status: Draft
Presentation Filter:
+ View Data

View Objective

This view (graph) displays only composite weaknesses.

View Filter: .//@Compound_Element_Structure='Composite'

+ Relationships
678 - Composites
+Compound Element: CompositeCompound Element: CompositeCross-Site Request Forgery (CSRF) - (352)
352 (Cross-Site Request Forgery (CSRF))
The web application does not, or can not, sufficiently verify whether a well-formed, valid, consistent request was intentionally provided by the user who submitted the request.Session RidingCross Site Reference ForgeryXSRF
*Weakness ClassWeakness ClassExternal Control of Critical State Data - (642)
352 (Cross-Site Request Forgery (CSRF)) > 642 (External Control of Critical State Data)
The software stores security-critical state information about its users, or the software itself, in a location that is accessible to unauthorized actors.
*Weakness BaseWeakness BaseInsufficient Session Expiration - (613)
352 (Cross-Site Request Forgery (CSRF)) > 613 (Insufficient Session Expiration)
According to WASC, "Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization."
*Weakness BaseWeakness BaseOrigin Validation Error - (346)
352 (Cross-Site Request Forgery (CSRF)) > 346 (Origin Validation Error)
The software does not properly verify that the source of data or communication is valid.
*Weakness ClassWeakness ClassUnintended Proxy or Intermediary ('Confused Deputy') - (441)
352 (Cross-Site Request Forgery (CSRF)) > 441 (Unintended Proxy or Intermediary ('Confused Deputy'))
The software receives a request, message, or directive from an upstream component, but the software does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the software's control sphere. This causes the software to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor.Confused Deputy
+Compound Element: CompositeCompound Element: CompositeSession Fixation - (384)
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)
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)
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)
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
+Compound Element: CompositeCompound Element: CompositeUntrusted Search Path - (426)
426 (Untrusted Search Path)
The application searches for critical resources using an externally-supplied search path that can point to resources that are not under the application's direct control.Untrusted Path
*Weakness ClassWeakness ClassContainment Errors (Container Errors) - (216)
426 (Untrusted Search Path) > 216 (Containment Errors (Container Errors))
This tries to cover various problems in which improper data are included within a "container."
*Weakness BaseWeakness BaseModification of Assumed-Immutable Data (MAID) - (471)
426 (Untrusted Search Path) > 471 (Modification of Assumed-Immutable Data (MAID))
The software does not properly protect an assumed-immutable element from being modified by an attacker.
*CategoryCategoryPermission Issues - (275)
426 (Untrusted Search Path) > 275 (Permission Issues)
Weaknesses in this category are related to improper assignment or handling of permissions.
+Compound Element: CompositeCompound Element: CompositeUNIX Symbolic Link (Symlink) Following - (61)
61 (UNIX Symbolic Link (Symlink) Following)
The software, when opening a file or directory, does not sufficiently account for when the file is a symbolic link that resolves to a target outside of the intended control sphere. This could allow an attacker to cause the software to operate on unauthorized files.Symlink followingsymlink vulnerability
*Weakness ClassWeakness ClassConcurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') - (362)
61 (UNIX Symbolic Link (Symlink) Following) > 362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))
The program contains a code sequence that can run concurrently with other code, and the code sequence requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence that is operating concurrently.
*Weakness ClassWeakness ClassContainment Errors (Container Errors) - (216)
61 (UNIX Symbolic Link (Symlink) Following) > 216 (Containment Errors (Container Errors))
This tries to cover various problems in which improper data are included within a "container."
*CategoryCategoryPermission Issues - (275)
61 (UNIX Symbolic Link (Symlink) Following) > 275 (Permission Issues)
Weaknesses in this category are related to improper assignment or handling of permissions.
*Weakness ClassWeakness ClassPredictability Problems - (340)
61 (UNIX Symbolic Link (Symlink) Following) > 340 (Predictability Problems)
Weaknesses in this category are related to schemes that generate numbers or identifiers that are more predictable than required by the application.
*Weakness BaseWeakness BaseSymbolic Name not Mapping to Correct Object - (386)
61 (UNIX Symbolic Link (Symlink) Following) > 386 (Symbolic Name not Mapping to Correct Object)
A constant symbolic reference to an object is used, even though the reference can resolve to a different object over time.
+Compound Element: CompositeCompound Element: CompositePermission Race Condition During Resource Copy - (689)
689 (Permission Race Condition During Resource Copy)
The product, while copying or cloning a resource, does not set the resource's permissions or access control until the copy is complete, leaving the resource exposed to other spheres while the copy is taking place.
*Weakness ClassWeakness ClassConcurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') - (362)
689 (Permission Race Condition During Resource Copy) > 362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))
The program contains a code sequence that can run concurrently with other code, and the code sequence requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence that is operating concurrently.
*Weakness ClassWeakness ClassIncorrect Permission Assignment for Critical Resource - (732)
689 (Permission Race Condition During Resource Copy) > 732 (Incorrect Permission Assignment for Critical Resource)
The software specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.
+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-09-08CWE Content TeamMITREInternal
updated Description, View_Filter, View_Structure
+ View Metrics
CWEs in this viewTotal CWEs
Total5out of1005
Views0out of33
Categories0out of244
Weaknesses0out of720
Compound_Elements5out 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-352: Cross-Site Request Forgery (CSRF)

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

Description Summary

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

Extended Description

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

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

Languages

Language-independent

Technology Classes

Web-Server

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

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

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

+ Likelihood of Exploit

Medium to High

+ Detection Methods

Manual Analysis

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

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

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

Effectiveness: High

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

Automated Static Analysis

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

Effectiveness: Limited

Automated Static Analysis - Binary / Bytecode

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

Cost effective for partial coverage:

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

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

Effectiveness: SOAR Partial

Manual Static Analysis - Binary / Bytecode

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

Cost effective for partial coverage:

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

Effectiveness: SOAR Partial

Dynamic Analysis with automated results interpretation

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

Highly cost effective:

  • Web Application Scanner

Effectiveness: SOAR High

Dynamic Analysis with manual results interpretation

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

Highly cost effective:

  • Fuzz Tester

  • Framework-based Fuzzer

Effectiveness: SOAR High

Manual Static Analysis - Source Code

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

Cost effective for partial coverage:

  • Focused Manual Spotcheck - Focused manual analysis of source

  • Manual Source Code Review (not inspections)

Effectiveness: SOAR Partial

Automated Static Analysis - Source Code

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

Cost effective for partial coverage:

  • Source code Weakness Analyzer

  • Context-configured Source Code Weakness Analyzer

Effectiveness: SOAR Partial

Architecture / Design Review

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

Cost effective for partial coverage:

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

  • Formal Methods / Correct-By-Construction

Effectiveness: SOAR Partial

+ Demonstrative Examples

Example 1

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

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

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

profile.php contains the following code.

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

session_start();

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

if (! session_is_registered("username")) {

echo "invalid session detected!";

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

exit;
}

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

update_profile();

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

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

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

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

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

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

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

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

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

Phase: Architecture and Design

Strategy: Libraries or Frameworks

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

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

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

Phase: Implementation

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

Phase: Architecture and Design

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

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

Phase: Architecture and Design

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

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

Phase: Architecture and Design

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

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

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

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

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

Phase: Architecture and Design

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

Phase: Implementation

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

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

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

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

+ Research Gaps

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

+ Theoretical Notes

The CSRF topology is multi-channel:

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

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

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

CWE-689: Permission Race Condition During Resource Copy

Compound Element ID: 689
Abstraction: Base
Structure: Composite
Status: Draft
Presentation Filter:
+ Description

Description Summary

The product, while copying or cloning a resource, does not set the resource's permissions or access control until the copy is complete, leaving the resource exposed to other spheres while the copy is taking place.
+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

C

Perl

+ Modes of Introduction

Common examples occur in file archive extraction, in which the product begins the extraction with insecure default permissions, then only sets the final permissions (as specified in the archive) once the copy is complete. The larger the archive, the larger the timing window for the race condition.

This weakness has also occurred in some operating system utilities that perform copies of deeply nested directories containing a large number of files.

This weakness can occur in any type of functionality that involves copying objects or resources in a multi-user environment, including at the application level. For example, a document management system might allow a user to copy a private document, but if it does not set the new copy to be private as soon as the copy begins, then other users might be able to view the document while the copy is still taking place.

+ Common Consequences
ScopeEffect
Confidentiality
Integrity

Technical Impact: Read application data; Modify application data

+ Observed Examples
ReferenceDescription
Archive extractor decompresses files with world-readable permissions, then later sets permissions to what the archive specified.
Product inserts a new object into database before setting the object's permissions, introducing a race condition.
Error file has weak permissions before a chmod is performed.
Archive permissions issue using hard link.
Database product creates files world-writable before initializing the setuid bits, leading to modification of executables.
+ Weakness Ordinalities
OrdinalityDescription
Primary
(where the weakness exists independent of other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
RequiresWeakness ClassWeakness Class362Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Research Concepts1000
RequiresWeakness ClassWeakness Class732Incorrect Permission Assignment for Critical Resource
Research Concepts1000
ChildOfCategoryCategory275Permission Issues
Development Concepts (primary)699
ChildOfWeakness ClassWeakness Class732Incorrect Permission Assignment for Critical Resource
Research Concepts (primary)1000
+ Research Gaps

Under-studied. It seems likely that this weakness could occur in any situation in which a complex or large copy operation occurs, when the resource can be made available to other spheres as soon as it is created, but before its initialization is complete.

+ References
[REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 9, "Permission Races", Page 533.. 1st Edition. Addison Wesley. 2006.
+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-09-08CWE Content TeamMITREInternal
updated Applicable_Platforms, Relationships, Other_Notes, Weakness_Ordinalities
2009-03-10CWE Content TeamMITREInternal
updated Related_Attack_Patterns
2010-09-27CWE Content TeamMITREInternal
updated Relationships
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated References
2014-06-23CWE Content TeamMITREInternal
updated Modes_of_Introduction, Other_Notes

CWE-384: Session Fixation

Compound Element ID: 384
Abstraction: Base
Structure: Composite
Status: Incomplete
Presentation Filter:
+ Description

Description Summary

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.

Extended Description

Such a scenario is commonly observed when:

1. A web application authenticates a user without first invalidating the existing session, thereby continuing to use the session already associated with the user.

2. An attacker is able to force a known session identifier on a user so that, once the user authenticates, the attacker has access to the authenticated session.

3. The application or container uses predictable session identifiers. In the generic exploit of session fixation vulnerabilities, an attacker creates a new session on a web application and records the associated session identifier. The attacker then causes the victim to associate, and possibly authenticate, against the server using that session identifier, giving the attacker access to the user's account through the active session.

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

Languages

All

+ Common Consequences
ScopeEffect
Access Control

Technical Impact: Gain privileges / assume identity

+ Demonstrative Examples

Example 1

The following example shows a snippet of code from a J2EE web application where the application authenticates users with LoginContext.login() without first calling HttpSession.invalidate().

(Bad Code)
Example Language: Java 
private void auth(LoginContext lc, HttpSession session) throws LoginException {
...
lc.login();
...
}

In order to exploit the code above, an attacker could first create a session (perhaps by logging into the application) from a public terminal, record the session identifier assigned by the application, and reset the browser to the login page. Next, a victim sits down at the same public terminal, notices the browser open to the login page of the site, and enters credentials to authenticate against the application. The code responsible for authenticating the victim continues to use the pre-existing session identifier, now the attacker simply uses the session identifier recorded earlier to access the victim's active session, providing nearly unrestricted access to the victim's account for the lifetime of the session. Even given a vulnerable application, the success of the specific attack described here is dependent on several factors working in the favor of the attacker: access to an unmonitored public terminal, the ability to keep the compromised session active and a victim interested in logging into the vulnerable application on the public terminal.

In most circumstances, the first two challenges are surmountable given a sufficient investment of time. Finding a victim who is both using a public terminal and interested in logging into the vulnerable application is possible as well, so long as the site is reasonably popular. The less well known the site is, the lower the odds of an interested victim using the public terminal and the lower the chance of success for the attack vector described above. The biggest challenge an attacker faces in exploiting session fixation vulnerabilities is inducing victims to authenticate against the vulnerable application using a session identifier known to the attacker.

In the example above, the attacker did this through a direct method that is not subtle and does not scale suitably for attacks involving less well-known web sites. However, do not be lulled into complacency; attackers have many tools in their belts that help bypass the limitations of this attack vector. The most common technique employed by attackers involves taking advantage of cross-site scripting or HTTP response splitting vulnerabilities in the target site [12]. By tricking the victim into submitting a malicious request to a vulnerable application that reflects JavaScript or other code back to the victim's browser, an attacker can create a cookie that will cause the victim to reuse a session identifier controlled by the attacker. It is worth noting that cookies are often tied to the top level domain associated with a given URL. If multiple applications reside on the same top level domain, such as bank.example.com and recipes.example.com, a vulnerability in one application can allow an attacker to set a cookie with a fixed session identifier that will be used in all interactions with any application on the domain example.com [29].

Example 2

The following example shows a snippet of code from a J2EE web application where the application authenticates users with a direct post to the <code>j_security_check</code>, which typically does not invalidate the existing session before processing the login request.

(Bad Code)
Example Language: HTML 
<form method="POST" action="j_security_check">
<input type="text" name="j_username">
<input type="text" name="j_password">
</form>
+ Potential Mitigations

Phase: Architecture and Design

Invalidate any existing session identifiers prior to authorizing a new user session.

Phase: Architecture and Design

For platforms such as ASP that do not generate new values for sessionid cookies, utilize a secondary cookie. In this approach, set a secondary cookie on the user's browser to a random value and set a session variable to the same value. If the session variable and the cookie value ever don't match, invalidate the session, and force the user to log on again.

+ Other Notes

Other attack vectors include DNS poisoning and related network based attacks where an attacker causes the user to visit a malicious site by redirecting a request for a valid site. Network based attacks typically involve a physical presence on the victim's network or control of a compromised machine on the network, which makes them harder to exploit remotely, but their significance should not be overlooked. Less secure session management mechanisms, such as the default implementation in Apache Tomcat, allow session identifiers normally expected in a cookie to be specified on the URL as well, which enables an attacker to cause a victim to use a fixed session identifier simply by emailing a malicious URL.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
RequiresWeakness BaseWeakness Base346Origin Validation Error
Research Concepts1000
RequiresWeakness ClassWeakness Class441Unintended Proxy or Intermediary ('Confused Deputy')
Research Concepts1000
RequiresWeakness BaseWeakness Base472External Control of Assumed-Immutable Web Parameter
Research Concepts1000
ChildOfWeakness ClassWeakness Class287Improper Authentication
Development Concepts699
Research Concepts (primary)1000
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfCategoryCategory361Time and State
Development Concepts (primary)699
Seven Pernicious Kingdoms (primary)700
ChildOfCategoryCategory724OWASP Top Ten 2004 Category A3 - Broken Authentication and Session Management
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory930OWASP Top Ten 2013 Category A2 - Broken Authentication and Session Management
Weaknesses in OWASP Top Ten (2013) (primary)928
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
7 Pernicious KingdomsSession Fixation
OWASP Top Ten 2004A3CWE More SpecificBroken Authentication and Session Management
WASC37Session Fixation
+ 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 Description, Relationships, Other_Notes, Taxonomy_Mappings
2009-07-27CWE Content TeamMITREInternal
updated Demonstrative_Examples, Related_Attack_Patterns
2010-02-16CWE Content TeamMITREInternal
updated Taxonomy_Mappings
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2013-07-17CWE Content TeamMITREInternal
updated Relationships
2015-12-07CWE Content TeamMITREInternal
updated Relationships

CWE-61: UNIX Symbolic Link (Symlink) Following

Compound Element ID: 61
Abstraction: Variant
Structure: Composite
Status: Incomplete
Presentation Filter:
+ Description

Description Summary

The software, when opening a file or directory, does not sufficiently account for when the file is a symbolic link that resolves to a target outside of the intended control sphere. This could allow an attacker to cause the software to operate on unauthorized files.

Extended Description

A software system that allows UNIX symbolic links (symlink) as part of paths whether in internal code or through user input can allow an attacker to spoof the symbolic link and traverse the file system to unintended locations or access arbitrary files. The symbolic link can permit an attacker to read/write/corrupt a file that they originally did not have permissions to access.

+ Alternate Terms
Symlink following
symlink vulnerability
+ Time of Introduction
  • Implementation
+ Applicable Platforms

Languages

All

+ Modes of Introduction

These are typically reported for temporary files or privileged programs.

+ Common Consequences
ScopeEffect
Confidentiality
Integrity

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

+ Likelihood of Exploit

High to Very High

+ Observed Examples
ReferenceDescription
Some versions of Perl follows symbolic links when running with the -e option, which allows local users to overwrite arbitrary files via a symlink attack.
Text editor follows symbolic links when creating a rescue copy during an abnormal exit, which allows local users to overwrite the files of other users.
Antivirus update allows local users to create or append to arbitrary files via a symlink attack on a logfile.
Symlink attack allows local users to overwrite files.
Possible interesting example
Second-order symlink vulnerabilities
Second-order symlink vulnerabilities
Symlink in Python program
Setuid product allows file reading by replacing a file being edited with a symlink to the targeted file, leaking the result in error messages when parsing fails.
Signal causes a dump that follows symlinks.
+ Potential Mitigations

Phase: Implementation

Symbolic link attacks often occur when a program creates a tmp directory that stores files/links. Access to the directory should be restricted to the program as to prevent attackers from manipulating the files.

Phase: Architecture and Design

Strategy: Separation of Privilege

Follow the principle of least privilege when assigning access rights to entities in a software system.

Denying access to a file can prevent an attacker from replacing that file with a link to a sensitive file. Ensure good compartmentalization in the system to provide protected areas that can be trusted.

+ Weakness Ordinalities
OrdinalityDescription
Resultant
(where the weakness is typically related to the presence of some other weaknesses)
+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
RequiresWeakness ClassWeakness Class216Containment Errors (Container Errors)
Research Concepts1000
RequiresCategoryCategory275Permission Issues
Research Concepts1000
RequiresWeakness ClassWeakness Class340Predictability Problems
Research Concepts1000
RequiresWeakness ClassWeakness Class362Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Research Concepts1000
RequiresWeakness BaseWeakness Base386Symbolic Name not Mapping to Correct Object
Research Concepts1000
ChildOfWeakness BaseWeakness Base59Improper Link Resolution Before File Access ('Link Following')
Research Concepts (primary)1000
ChildOfCategoryCategory60UNIX Path Link Problems
Resource-specific Weaknesses (primary)631
Development Concepts (primary)699
+ Research Gaps

Symlink vulnerabilities are regularly found in C and shell programs, but all programming languages can have this problem. Even shell programs are probably under-reported.

"Second-order symlink vulnerabilities" may exist in programs that invoke other programs that follow symlinks. They are rarely reported but are likely to be fairly common when process invocation is used. Reference: [Christey2005]

+ Causal Nature

Explicit

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERUNIX symbolic link following
+ References
Steve Christey. "Second-Order Symlink Vulnerabilities". Bugtraq. 2005-06-07. <http://www.securityfocus.com/archive/1/401682>.
Shaun Colley. "Crafting Symlinks for Fun and Profit". Infosec Writers Text Library. 2004-04-12. <http://www.infosecwriters.com/texts.php?op=display&id=159>.
[REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 9, "Symbolic Link Attacks", Page 518.. 1st Edition. Addison Wesley. 2006.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Relationships, Observed_Example, Other_Notes, Research_Gaps, Taxonomy_Mappings, Weakness_Ordinalities
2008-10-14CWE Content TeamMITREInternal
updated Description
2009-07-27CWE Content TeamMITREInternal
updated Observed_Examples
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2012-05-11CWE Content TeamMITREInternal
updated Observed_Examples, References
2012-10-30CWE Content TeamMITREInternal
updated Potential_Mitigations
2014-06-23CWE Content TeamMITREInternal
updated Modes_of_Introduction, Other_Notes

CWE-426: Untrusted Search Path

Compound Element ID: 426
Abstraction: Base
Structure: Composite
Status: Draft
Presentation Filter:
+ Description

Description Summary

The application searches for critical resources using an externally-supplied search path that can point to resources that are not under the application's direct control.

Extended Description

This might allow attackers to execute their own programs, access unauthorized data files, or modify configuration in unexpected ways. If the application uses a search path to locate critical resources such as programs, then an attacker could modify that search path to point to a malicious program, which the targeted application would then execute. The problem extends to any type of critical resource that the application trusts.

Some of the most common variants of untrusted search path are:

  • In various UNIX and Linux-based systems, the PATH environment variable may be consulted to locate executable programs, and LD_PRELOAD may be used to locate a separate library.

  • In various Microsoft-based systems, the PATH environment variable is consulted to locate a DLL, if the DLL is not found in other paths that appear earlier in the search order.

+ Alternate Terms
Untrusted Path
+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms

Languages

Language-independent

Operating Systems

OS-independent

+ Common Consequences
ScopeEffect
Integrity
Confidentiality
Availability
Access Control

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

There is the potential for arbitrary code execution with privileges of the vulnerable program.

Availability

Technical Impact: DoS: crash / exit / restart

The program could be redirected to the wrong files, potentially triggering a crash or hang when the targeted file is too large or does not have the expected format.

Confidentiality

Technical Impact: Read files or directories

The program could send the output of unauthorized files to the attacker.

+ Likelihood of Exploit

High

+ Detection Methods

Black Box

Use monitoring tools that examine the software's process as it interacts with the operating system and the network. This technique is useful in cases when source code is unavailable, if the software was not developed by you, or if you want to verify that the build phase did not introduce any new weaknesses. Examples include debuggers that directly attach to the running process; system-call tracing utilities such as truss (Solaris) and strace (Linux); system activity monitors such as FileMon, RegMon, Process Monitor, and other Sysinternals utilities (Windows); and sniffers and protocol analyzers that monitor network traffic.

Attach the monitor to the process and look for library functions and system calls that suggest when a search path is being used. One pattern is when the program performs multiple accesses of the same file but in different directories, with repeated failures until the proper filename is found. Library calls such as getenv() or their equivalent can be checked to see if any path-related variables are being accessed.

Automated Static Analysis

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.

Manual Analysis

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.

+ Demonstrative Examples

Example 1

This program is intended to execute a command that lists the contents of a restricted directory, then performs other actions. Assume that it runs with setuid privileges in order to bypass the permissions check by the operating system.

(Bad Code)
Example Language:
#define DIR "/restricted/directory"

char cmd[500];
sprintf(cmd, "ls -l %480s", DIR);
/* Raise privileges to those needed for accessing DIR. */
RaisePrivileges(...);
system(cmd);
DropPrivileges(...);
...

This code may look harmless at first, since both the directory and the command are set to fixed values that the attacker can't control. The attacker can only see the contents for DIR, which is the intended program behavior. Finally, the programmer is also careful to limit the code that executes with raised privileges.

However, because the program does not modify the PATH environment variable, the following attack would work:

The user sets the PATH to reference a directory under that user's control, such as "/my/dir/".

The user creates a malicious program called "ls", and puts that program in /my/dir

The user executes the program.

When system() is executed, the shell consults the PATH to find the ls program

The program finds the malicious program, "/my/dir/ls". It doesn't find "/bin/ls" because PATH does not contain "/bin/".

The program executes the malicious program with the raised privileges.

Example 2

This code prints all of the running processes belonging to the current user.

(Bad Code)
Example Language: PHP 
//assume getCurrentUser() returns a username that is guaranteed to be alphanumeric (CWE-78)
$userName = getCurrentUser();
$command = 'ps aux | grep ' . $userName;
system($command);

This program is also vulnerable to a PATH based attack, as an attacker may be able to create malicious versions of the ps or grep commands. While the program does not explicitly raise privileges to run the system commands, the PHP interpreter may by default be running with higher privileges than users.

Example 3

The following code is from a web application that allows users access to an interface through which they can update their password on the system. In this environment, user passwords can be managed using the Network Information System (NIS), which is commonly used on UNIX systems. When performing NIS updates, part of the process for updating passwords is to run a make command in the /var/yp directory. Performing NIS updates requires extra privileges.

(Bad Code)
Example Language: Java 
...
System.Runtime.getRuntime().exec("make");
...

The problem here is that the program does not specify an absolute path for make and does not clean its environment prior to executing the call to Runtime.exec(). If an attacker can modify the $PATH variable to point to a malicious binary called make and cause the program to be executed in their environment, then the malicious binary will be loaded instead of the one intended. Because of the nature of the application, it runs with the privileges necessary to perform system operations, which means the attacker's make will now be run with these privileges, possibly giving the attacker complete control of the system.

+ Observed Examples
ReferenceDescription
Application relies on its PATH environment variable to find and execute program.
Database application relies on its PATH environment variable to find and execute program.
Chain: untrusted search path enabling resultant format string by loading malicious internationalization messages.
Untrusted search path using malicious .EXE in Windows environment.
setuid program allows compromise using path that finds and loads a malicious library.
Server allows client to specify the search path, which can be modified to point to a program that the client has uploaded.
+ Potential Mitigations

Phases: Architecture and Design; Implementation

Strategy: Identify and Reduce Attack Surface

Hard-code the search path to a set of known-safe values (such as system directories), or only allow them to be specified by the administrator in a configuration file. Do not allow these settings to be modified by an external party. Be careful to avoid related weaknesses such as CWE-426 and CWE-428.

Phase: Implementation

When invoking other programs, specify those programs using fully-qualified pathnames. While this is an effective approach, code that uses fully-qualified pathnames might not be portable to other systems that do not use the same pathnames. The portability can be improved by locating the full-qualified paths in a centralized, easily-modifiable location within the source code, and having the code refer to these paths.

Phase: Implementation

Remove or restrict all environment settings before invoking other programs. This includes the PATH environment variable, LD_LIBRARY_PATH, and other settings that identify the location of code libraries, and any application-specific search paths.

Phase: Implementation

Check your search path before use and remove any elements that are likely to be unsafe, such as the current working directory or a temporary files directory.

Phase: Implementation

Use other functions that require explicit paths. Making use of any of the other readily available functions that require explicit paths is a safe way to avoid this problem. For example, system() in C does not require a full path since the shell can take care of it, while execl() and execv() require a full path.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
RequiresWeakness ClassWeakness Class216Containment Errors (Container Errors)
Research Concepts1000
RequiresCategoryCategory275Permission Issues
Research Concepts1000
RequiresWeakness BaseWeakness Base471Modification of Assumed-Immutable Data (MAID)
Research Concepts1000
ChildOfCategoryCategory417Channel and Path Errors
Development Concepts (primary)699
Weaknesses for Simplified Mapping of Published Vulnerabilities (primary)1003
ChildOfCategoryCategory634Weaknesses that Affect System Processes
Resource-specific Weaknesses (primary)631
ChildOfWeakness ClassWeakness Class642External Control of Critical State Data
Research Concepts (primary)1000
ChildOfWeakness ClassWeakness Class673External Influence of Sphere Definition
Research Concepts1000
ChildOfCategoryCategory744CERT C Secure Coding Section 10 - Environment (ENV)
Weaknesses Addressed by the CERT C Secure Coding Standard (primary)734
ChildOfCategoryCategory7522009 Top 25 - Risky Resource Management
Weaknesses in the 2009 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)750
ChildOfCategoryCategory8082010 Top 25 - Weaknesses On the Cusp
Weaknesses in the 2010 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)800
ChildOfCategoryCategory878CERT C++ Secure Coding Section 10 - Environment (ENV)
Weaknesses Addressed by the CERT C++ Secure Coding Standard (primary)868
PeerOfWeakness BaseWeakness Base427Uncontrolled Search Path Element
Research Concepts1000
CanAlsoBeWeakness BaseWeakness Base98Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')
Research Concepts1000
+ Research Gaps

Search path issues on Windows are under-studied and possibly under-reported.

+ Affected Resources
  • System Process
+ Functional Areas
  • Program invocation
  • Code libraries
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERUntrusted Search Path
CLASPRelative path library search
CERT C Secure CodingENV03-CSanitize the environment when invoking external programs
CERT C++ Secure CodingENV03-CPPSanitize the environment when invoking external programs
+ References
[REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 10, Process Attributes, page 603. 1st Edition. Addison Wesley. 2006.
[REF-8] M. Howard and D. LeBlanc. "Writing Secure Code". Chapter 8, "Canonical Representation Issues." Page 229.. 1st Edition. Microsoft. 2002.
[REF-9] John Viega and Gary McGraw. "Building Secure Software: How to Avoid Security Problems the Right Way". Chapter 12, "Trust Management and Input Validation." Pages 317-320.. 1st Edition. Addison-Wesley. 2002.
[REF-11] M. Howard and D. LeBlanc. "Writing Secure Code". Chapter 11, "Don't Trust the PATH - Use Full Path Names" Page 385. 2nd Edition. Microsoft. 2002.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time_of_Introduction
2008-09-08CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2008-11-24CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2009-01-12CWE Content TeamMITREInternal
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Observed_Examples, Potential_Mitigations, Relationships, Time_of_Introduction
2009-03-10CWE Content TeamMITREInternal
updated Demonstrative_Examples, Potential_Mitigations
2009-12-28CWE Content TeamMITREInternal
updated References
2010-02-16CWE Content TeamMITREInternal
updated References, Relationships
2010-04-05CWE Content TeamMITREInternal
updated Applicable_Platforms
2010-06-21CWE Content TeamMITREInternal
updated Detection_Factors, Potential_Mitigations
2010-09-27CWE Content TeamMITREInternal
updated Description, Relationships
2011-03-29CWE Content TeamMITREInternal
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences
2011-09-13CWE Content TeamMITREInternal
updated Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Demonstrative_Examples, References
2014-02-18CWE Content TeamMITREInternal
updated Demonstrative_Examples, Detection_Factors, Potential_Mitigations
2015-12-07CWE Content TeamMITREInternal
updated Relationships

More information is available — Please select a different filter.
Page Last Updated: January 11, 2017