Common Weakness Enumeration

CWE Glossary Definition

2009 CWE/SANS Top 25 - Final Draft Changes and Discussion

Summary of Recent Top 25 Discussions

Date: October 29, 2009

• Updated CWE-78 entry to reflect name change from CWE 1.6. No other changes were made.

Date: July 27, 2009

• Updated related attack patterns and names to reflect changes in CWE 1.5. Also note that some individual entries on the CWE web site were modified to include new demonstrative and observed examples.

Date: May 27, 2009

• Updated mitigations, related attack patterns, and names to reflect changes in CWE 1.4. Also note that some individual entries on the CWE web site were modified to include new demonstrative examples.

Date: March 10, 2009

• After the initial publication of the list, we received extensive feedback from many different communities. We will be using this feedback in the coming months to help improve the list itself, along with recommendations for how it could be used within the larger context of the secure software development lifecycle.
• Updated mitigations to reduce duplication and be more consistent - changes also reflected in CWE 1.3. Some new mitigations were added for other phases such as testing and operation.
• Added Documents & Podcasts page

Date: January 11, 2009

• Improved readability and understandability of discussion text
• Added remainder of suggested mitigations to CWE entries
• Made significant updates to CWE entries on the Top 25, focusing on demonstrative examples, mitigations, consequences, references, and extended descriptions.
• Finished additions to the "On the Cusp" list of CWEs that did not make it to the Top 25
• Created a CWE Top 25 view (CWE-750) and generated supporting PDF graphs for visualization
• Collected final supporting quotes
• Wrote process document
• Finalized contributor list
• Reorganized main document

Date: January 8, 2009

• We again received many comments from about a dozen people, so we cannot individually respond to them all. Each draft has had approximately 5 to 8 new reviewers.
• Many of the comments were related to specific mitigations for individual entries. The CWE entries are being updated to reflect these changes.
• Some people provided substantive commentary on the threat model, which was a new addition. Much of the feedback centered around apparent contradictions and other issues with the description. As a result, this was cleaned up a bit in this final draft.
• Many contributors made final requests for entries that they thought were important for inclusion. In some cases, there were conflicting recommendations from different people, especially with respect to prevalence. The same entry would be seen extensively by one person but much less frequently by another person. This made the final decisions more difficult. A separate "On the Cusp" document will be published that will cover the issues that did not make it to the final list.
• Many contributors observed that the list contains entries at different levels of abstraction, such as XSS at one level and input validation at another level. This was effectively unavoidable given the diverse feedback we received, but maybe we will be able to address it next year. See the FAQ for further explanation.
• Some contributors provided great ideas for additional improvements, but it would take too long to implement them and submit to everyone for review. We will remember these suggestions when it is time to renew the list in 2010.

Top 25 Promotions and Demotions

• PROMOTE CWE-330 Randomness
  • chosen over CWE-400 because some voted against CWE-400. Also, CWE-400 is less serious given the threat model, which treats availability as a lower priority than integrity and confidentiality
  • also can partially benefit other areas like session handling
• DEMOTE CWE-252: Unchecked Return Value
  • multiple recommendations for demotion
  • impact often isn't code execution, and where it is, there is some coverage in other CWEs. Consequence is typically "none" (just a bug), or a denial of service.
  • Some advocacy for CWE-248 Uncaught Exception. Ideally, a common parent would be useful. The closest item is CWE-391, which the CWE team has slated for deprecation because it combines multiple issues. A replacement will not be ready before the Top 25 is released, since the CWE team is devising a basic model of error handling to address this entry and similar issues related to CWE-703 Failure to Handle Exceptional Conditions.
• REPLACE CWE-470 (Unsafe Reflection) with its parent CWE-94, Code Injection
  • allows more natural mention of eval injection and others

Other Changes

• Modified threat model to simplify and remove inconsistencies.
• Updated discussions for most entries. Some discussion fields did not do a good job of describing the weakness or why it was important.
• Numerous changes to mitigations
• Creation of "On the Cusp" section to list weaknesses that almost made it onto the Top 25
• Removed all commentary and contributor-only sections. All of the content in this new draft will be publicly available.
• Created new Introduction
• Reorganized sections related to selection criteria and supporting data fields; most were moved into an appendix.
• Added a Frequently Asked Questions section

Date: December 22, 2008

Thank you for participating in this effort. We received a lot of comments for the second draft, many of them from people who had not reviewed the first draft. We've received a lot of positive feedback that suggests we are heading in the right direction.

The third draft is provided in a separate message.

Schedule and Contact

NOTICE: We view this as the most important draft for your feedback. We would like your feedback by December 30th, but preferably as soon as possible. We will release a final draft soon after the 30th, accept last-minute comments, and freeze the document by January 5. The intended publication date for the official list is January 12, 2009.

Feedback can be sent to any of:

Top 25 team (SANS/MITRE)
Steve Christey
Bob Martin

Suggested Activities

You could do one or more of these activities. Whether you spend 5 minutes or 2 hours, your inputs will help improve the list.

• tell us if you agree with the additions (and removals), and our rationale for the changes
• tell us if you think it is important to have the modifications inserted directly into the document (we are considering just using links to the CWE web page)
• review the mitigations for individual entries, and suggest modifications
• review the threat model of the "determined, semi-professional attacker," and the new details for related data fields in the "Organization and Selection of the Top 25" section
• examine the items that are still being considered for promotion to the Top 25. If you want one of these items to be promoted, then suggest a weakness that should be removed from the Top 25.
• examine the items that are being considered for removal from the Top 25. If you agree that they should be removed, then suggest alternates that could be promoted to the Top 25.
• review the related CWEs and suggest additions
• review any of the text of individual entries

Summary of Received Comments for Draft 2

• Like the first draft, we've received comments from a diverse set of about a dozen people, many of whom did not provide feedback in the first round. Some comments were general and some specific, so there is some solid feedback to work with. Every single comment was read and considered, but due to the number of comments, we can't respond to each one individually.
• We have received some great feedback from software vendors who are actively involved in improving their own security. As a result, they are far ahead of the curve with respect to the average developer, and as such, they have typically addressed basic problems and are running into newer weaknesses. This is likely the case with many of the consultants who have provided feedback, too. We are trying to balance the experiences of these cutting-edge vendors with what the everyday developer may encounter.
• Some people strongly recommended a CWE for type conversion and/or other issues related to data parsing. In CVE, we do not have sufficient prevalence information for these issues, since most vendors don't actually list the underlying cause. This type of issue also has some coverage with buffer overflows. Instead, we added calculation errors which, in conjunction with input validation and unchecked return value, should cover many of these data-parsing errors; in addition, numeric errors are well-documented at least in CVE (specifically, integer overflows are a CVE Top 10 item, and Top 3 for OS vendors based on incomplete 2008 data).
• There have been repeated suggestions to provide more detailed mitigations. We will use the mitigations within the CWE entries themselves. This will reduce duplication of effort within the CWE team, but users of the Top 25 will also have up-to-date access to the latest mitigation suggestions. However, in the current public version of CWE, we noticed that many Top 25 entries do not have mitigations listed. The CWE team is actively addressing this, and the current draft contains the up-to-the-minute text for mitigations. However, we plan to remove the mitigations from the final Top 25 list, and point to a CWE URL instead.
• CVE vulnerability trend data for 2007 and 2008 was regenerated using new CVE flaw types that had not been reported in previous trend publications; this includes flaws such as NULL pointer dereferences, cleartext transmission, and exposed methods. While the 2007 and 2008 data is incomplete, it does not appear that any of these new flaw types will make it into CVE's top 10.
• The prioritization based on severity and prevalence continued in this round. However, we did not have sufficient data to establish prevalence, especially for design-related issues. So we avoided trying to apply a specific formula. Instead, we used severity and prevalence estimates to prioritize which weaknesses should be promoted to the Top 25, or removed from it.
• One reviewer noticed some inconsistencies and suggested defining the values being used for fields like prevalence, remediation cost, etc. This was addressed in this round.

Changes from second draft to third draft

MITIGATIONS

This draft contains many new mitigations for each entry. We do not have the resources to provide extremely detailed descriptions of each mitigation, however.

Note that we will re-use CWE's mitigations instead of creating new ones. This means that we will be modifying each individual CWE's Potential_Mitigations field. In general, we will be making further enhancements to the CWE's that will be on the list. This is already occurring.

We plan to remove the mitigations from the final document, instead replacing them with links to the CWE entry with an anchor that directs the user directly to the mitigations portion of the CWE. Please tell us if you think there are good reasons for including the mitigations in the document itself.

CONSIDER FOR PROMOTION

These CWE entries are not on the Top 25 list, but they could be considered for addition if other CWEs are removed.

• CWE-330: Use of Insufficiently Random Values
• CWE-400: Uncontrolled Resource Consumption

CONSIDER FOR REMOVAL

These CWEs are currently in the Top 25, but they have not had any strong advocates. They could potentially be removed in favor of other weaknesses.

• CWE-252: Unchecked Return Value
• CWE-470: Unsafe Reflection
  • could merge with eval injection and others into Code Injection (CWE-94)

REMOVAL OF ITEMS WITH FEW ADVOCATES

Many entries were on the "Under Consideration" list for a few drafts, but had few active advocates and were never promoted to the Top 25. Many of these were moved to a bottom section and should be considered as permanently removed from consideration. These are in the "Weaknesses That Were Never Added to the Top 25" section.

ADDED ENTRIES

• CWE-116: Insufficient Encoding or Escaping of Output
  • important: see "special note" below
  • actively promoted by multiple contributors; a core aspect of many injection-related issues.
• CWE-682: Incorrect Calculation
  • rationale: see comments summary bullet on type conversion
  • this explicitly lists CWE-681 (Incorrect Conversion between Numeric Types) as a related CWE
• CWE-319: Cleartext Transmission of Sensitive Information
  • rationale: promoted due to prevalence/severity after other entries were removed
• CWE-642: External Control of Critical User State Data
  • rationale: replaces the more-specific CWE-565
• CWE-209: Information leak in an error message
  • rationale: promoted due to prevalence/severity after other entries were removed; actively endorsed by some contributors

REMOVED ENTRIES

These are now in the "Weaknesses That Were Demoted from the Top 25" section.

• CWE-184: Incomplete Blacklist
  • rationale: not actively endorsed
  • now a "related CWE" in input validation (CWE-20)
• CWE-180: Validating before Canonicalizing
  • rationale: not actively endorsed
  • now a "related CWE" in input validation (CWE-20)
• CWE-98: Remote File Inclusion
  • now a "related CWE" in external filename control (CWE-73)
• CWE-565: Use of Cookies in Security Decision
  • now a "related CWE" as a child of External Control of Critical User State Data (CWE-642)
• CWE-749: Insecure Exposed Methods
  • merged into the more general CWE-285 (access control)
  • these were suspected to be in Top 10 for CVE in 2008, but that does not appear to be the case

General Modifications

• Listed a threat model of the "determined, semi-professional attacker".
• Provided definitions of the values being used in fields like weakness prevalence, remediation cost, ease of detection, etc.
• Reordered Consequences and Weakness Prevalence to the top, since these were the primary considerations for inclusion in the Top 25.
• Removed some categories.
• Clarified CWE-494 to apply to any code that is downloaded and executed, not just "mobile code."

Special note on CWE-116 (Insufficient Encoding or Escaping of Output)

The addition of CWE-116 might be a surprise to people who think of SQL injection, XSS, and other injection-style issues as primarily input validation problems (CWE-20, Insufficient Input Validation). This reflects a growing belief in the importance of output encoding by the web application security community and others such as the editor of this document. While injection-style attacks might be mitigated using input validation, but the solution ultimately lies with output encoding, since sometimes dangerous characters must be part of the output.

CWE-116 and CWE-20 have a close association because, depending on the nature of the structured message, proper input validation can indirectly prevent special characters from changing the meaning of a structured message. For example, by validating that a numeric ID field should only contain the 0-9 characters, the programmer effectively prevents injection attacks. However, input validation is not always sufficient, especially when less stringent data types must be supported. Consider a SQL injection scenario in which a last name is inserted into a query. The name "O'Reilly" would likely pass the validation step since it is a common last name in the English language. However, it cannot be directly inserted into the database because it contains the "'" character, which would need to be escaped or otherwise handled. In this case, stripping the "'" might reduce the risk of SQL injection, but it would produce incorrect behavior because the wrong name would be recorded.

Remaining Issues

The following items are the newest, and therefore need the most feedback.

• Mitigations review and comment
• "Determined semi-pro attacker" threat model
• suggested values for prevalence, ease of exploitation, and other fields

Date: December 8, 2008

Thank you for participating in this effort. We received a lot of comments for the first draft.

The second draft is provided in a separate message. We would like to receive feedback on this, or related questions, by December 17th. We will have one or teo more rounds for review, with early January as a target release date.

For this round, you could consider any of these activities.

• see if you agree with the changes
• review and comment on the outstanding questions
• review entries that were recommended for addition, but not yet added
• review entries that were recommended for removal, but not yet removed
• review entries with minimal comment - candidates for removal?
• review any of the text of individual entries

Whether you spend 5 minutes or 2 hours, your opinions matter to us. We received a single-sentence response from one participant that helped boost our confidence that we are headed in the right direction, so every bit helps.

Feedback can be sent to any of:

Top 25 team (SANS/MITRE)
Steve Christey
Bob Martin

Summary of Received Comments for Draft 1

• We've received comments from a diverse set of about a dozen people. Some comments were general and some specific, so there is some solid feedback to work with. Every single comment was read and considered, but due to the number of comments, we can't respond to each one individually.
• While the CWE Top 25 has tried to focus on underlying weaknesses, feedback has often suggested vulnerability concepts and some people have recommended removing the more weakness-focused CWEs. This is a difficulty with the industry in general, combined with available trend analyses that are generally weakness-focused.
• Overall, there seemed to be agreement that the informal tone was good, because it sounds less "preachy" to developers and thus is more likely to be accepted.
• Several people recommended specifying the selection criteria more precisely, and following those criteria. For this draft, we used an informal combination of severity and prevalence.
• Some individual entries were missing discussion or mitigation fields. Discussion fields were added to this draft; other fields, especially mitigation, will be filled over the next couple of weeks. Our initial focus was primarily on which CWE's should be covered.
• Some people asked for more representation for web applications, but other participants don't deal with web apps at all. Striking a balance might be difficult.
• A couple recommendations were based on CVE vulnerability trend data, which dates from 2006. There have been some changes, though 2008 data is incomplete. We'll look at the rough data for 2008 to see if there's anything noticeable.
• Some people recommended CWE entries that are the "category" type. Unlike "weakness" type CWE entries, categories are often loose collections of multiple unrelated weaknesses. We tried to avoid these because we wanted to be more specific about the relevant weaknesses. However, some areas of CWE do not have sufficient depth and cohesion that is weakness-focused, so category nodes might be the best option.

Changes from first draft to second draft

This is a summary of the most notable changes that were made between the first and second drafts.

Changed "public knowledge" to "attacker awareness". The awareness level assumes an attacker skill level that is somewhere between script kiddie and nation-state: an intent to do harm, capability to perform some research of known flaw types, but not to follow cutting-edge trends.

Changed "Child CWEs" to "Related CWEs"

Added discussion items to each entry. (Mitigations will be finalized in a later draft).

Added new entries:

• CWE-79 (XSS)
• CWE-89 (SQL injection)
• CWE-352 (CSRF)
• CWE-119 (general out-of-bounds buffer error)

Removed entries:

• CWE-134 (format strings)
• CWE-120, CWE-129, CWE-131 - removed in favor of more general CWE-119

Miscellaneous edits:

• added missing discussion points
• added missing data fields
• added/updated related CWEs for some entries

Selection Criteria:

There has been some direct and indirect advocacy for selecting CWE's based on some combination of prevalence and severity. An example of indirect advocacy came from Mark Cox, who used NVD's CWE-based categorization to look at critical/important Red Hat issues. Chris Wysopal from Veracode suggested a formula of:

(Severity * Severity) * Prevalence

where Severity was on a scale of 1 to 5.

We are seriously considering using this metric, or some other metric based on severity and prevalence, to help us to prioritize elements on the Top 25. The entries that were added to Draft 2 were prioritized based on an informal combination of severity and prevalence. (Severity is implied by the "consequences" field).

Outstanding Questions for Existing Entries

The following top 25 entries had conflicting opinions, or other issues that require some closer review.

CWE-20 (Input validation) - some people think it's extremely important. Others think it's too high-level, or it has too much of a relationship with other issues on the list. In my own opinion, even with the overlap, I think it should be the #1 message we get out to developers. It won't fix everything, but it will eliminate much of the low-hanging fruit. This can be referenced in mitigations for some other top 25 entries, to further reinforce the importance of input validation.

CWE-184 (Incomplete blacklist) - one suggestion was for inclusion based on prevalence (with a rephrasing to focus on the badness of relying solely on blacklists at all). Another suggestion was for exclusion since (paraphrasing poorly) they already reflect an attempt to protect the software. This will always have lesser prevalence than the weakness it's trying to protect against.

CWE-259 (hard-coded password) - inclusion was not debated, but there is a need for clarification. Recently, the CWE team realized that CWE-259 can be interpreted by people in two different ways, and we're seeing it in the Top 25 feedback, too. The two interpretations are: (1) an application's authentication routine compares an incoming password against a hard-coded password and grants access accordingly; (2) an application connects to another process/component, and it contains hard-coded credentials for authenticating to that component. With respect to the Top 25 list and CWE 1.1, the original intention was item (1); but should this be expanded to include both meanings? Also, there was a suggestion to broaden it to include default passwords.

CWE-749 (insecure exposed methods) - Some people didn't think it was that important. 2008-era CVE data suggests a significant increase in the past 2 years, so prevalence may be high. Severity is usually high, e.g. many ActiveX exposed method vulnerabilities allow arbitrary code execution.

CWE-362 (race condition) - low prevalence based on CVE data; but some people argued that it's a big issue. Probably reflects CVE bias towards researchers who publicize results (which omits most consultants for security-sensitive industries like finance).

CWE-73 (External Control of File Name or Path) was the topic of some discussion. There was some advocacy for something more general that deals with external control of inputs, such as parameter tampering (CWE-472) - especially by web application people. CWE-472 is important to many CWE's like XSS and SQL injection, but CWE-73 is currently the only tie to path traversal and symlink following (which have moderate prevalence based on CVE data, so aren't in the top 25).

CWE-250 (Operating with Unnecessary Privileges) did not receive much direct commentary, but several people wanted to capture issues related to privilege management. One difficulty is that the privilege/permissions area of CWE is not sufficiently mature, although we can partially address this with new CWE entries if necessary.

Suggested Minor Modifications

These are some of the more notable suggestions for modifications to the top 25 list.

Comments on Entries that were Added to Draft 2

The following entries were added to the Top 25 list in Draft 2. These additions were prioritized using an informal combination of prevalence and severity.

• CWE-79 (XSS) or CWE-80 (Basic XSS)

  ACTION: Added to Top 25

  • this is mentioned in the item for Input Validation (CWE-20), but some people advocated for promotion to an individual slot on the Top 25. Based on prevalence, this probably should be on the list.
• CWE-89 (SQL injection)

  ACTION: Added to Top 25

  • this is mentioned in the item for Input Validation (CWE-20), but some people advocated for promotion. Based on prevalence and severity (CVE and independent data sources), this should be near the top of the list.
• CWE-352 (CSRF)

  ACTION: Added to Top 25

  • using prevalence (based on 2008 CVE stats) and general severity, there are probably good reasons for including it

Comments on Entries that were Removed from Top 25

• CWE-134 - format strings.

  ACTION: Removed from Top 25

  • Multiple comments that it's not prevalent. However, severity is high.

Entries that were Recommended, but not Added (Yet?)

The following entries were recommended for addition to the Top 25, but they were not added due to issues of space or prioritization.

If you strongly believe that one of these entries should be added to the top 25, then please give your reasons for doing so, and suggest which of the current entries should be replaced.

• CWE-319 (Plaintext Transmission of Sensitive Information)

  ACTION: Added to Top 25

  • this was only mentioned by one person but is an entire category in the OWASP Top Ten, and applies to much more than web apps. Prevalence is unknown but probably high. Severity is usually medium to high.

• CWE-190 (Integer Overflow)

  ACTION: Still not added to Top 25

  • this was advocated by multiple people, and it is very prevalent for OS vendors, based on CVE data. Severity can be high, but only in context with other weaknesses related to buffer overflows (DoS is possible by creating infinite/large loops). Since there is already a CWE for buffer overflows, maybe CWE-190 should not be included.

• CWE-209 (Error message information leak)

  ACTION: Still not added to Top 25

  • very high prevalence, severity often low but sometimes high.

• CWE-117 (Output Sanitization)

  ACTION: Still not added to Top 25

  • advocated by some; a good partner to input validation, but if SQL injection and XSS get their own slots on the list, is it overkill?

• CWE-476 (NULL pointer dereference)

  ACTION: Still not added to Top 25

  • in terms of prevalence, it's probably in the top 15 based on CVE 2008 data. Severity is usually DoS (for C programs) or minor infoleak (for Java programs).

• CWE-385 (Session Fixation)

  ACTION: Still not added to Top 25

  • mentioned by a couple people. Prevalence is uncertain, minimal in CVE data. Attack complexity is moderate, but severity can be high.

Entries that were Recommended for Removal, but not Removed from Top 25

These entries were recommended for removal by some parties, but they were not removed from the Top 25 due to prevalence, severity, or inconsistent feedback.

• CWE-426 - untrusted search path.

  ACTION: Kept in Top 25

  • Exclude based on limited prevalence. However, severity is usually high.

• CWE-665 - incorrect/incomplete initialization.

  ACTION: Kept in Top 25

  • One argument was that this was not an issue with modern languages. However, it's prevalent and often severe for PHP applications (though less important as register_globals usage declines), and uninitialized variable issues in C have moderate severity with unknown prevalence.

• CWE-184 - Incomplete Blacklist.

  ACTION: Kept in Top 25

  • Nobody seemed to argue too strongly for them, not much data on prevalence. Lesser prevalence than the weakness it's trying to protect against; at least the programmer is trying, which shows some awareness/diligence for security.

Entries without much comment (pro or con)

The following entries did not receive much commentary, whether pro or con. These could be considered for removal to make room for others that are deemed more important - or are they very important?

• CWE-180 (Validating before Canonicalizing)
• CWE-470 (Unsafe Reflection)
• CWE-565 (Use of Cookies in Security Decision)
• CWE-252 (Unchecked return value)
• CWE-494 (Download of Untrusted Mobile Code Without Integrity Check)

Other Suggested Changes

Some more clarification on the contrast to the OWASP Top Ten might be useful.

Consider "Ease of Exploitation"