CWE (Common Weakness Enumeration) and the CWE Top 25 Explained – Source:www.hackerone.com

Updated September 1, 2023

Are you wondering about CWE? We explain CWE (Common Weakness Enumeration) and why this community-based initiative is essential in cybersecurity.

Common Weakness Enumeration (CWE) is a system to categorize software and hardware security flaws—implementation defects that can lead to vulnerabilities. It is a community project to understand security weaknesses or errors in code and vulnerabilities and create tools to help prevent them.

The MITRE Corporation operates CWE, and the National Cyber Security Division and US-CERT support it. CWE has over 600 categories detailing different types of vulnerabilities and bugs.

CWE strives to stop vulnerabilities and bugs by educating developers on building better products that aren’t susceptible to exploitation. Programmers can use CWE as a resource while writing code to prevent vulnerabilities during the development process. Security Orchestration, Automation, and Response (SOAR) tools use CWEs to build policies and workflows to automate remediation.

In this article:

• What Is the CWE Top 25?
• CWE Examples: Which Are the Most Dangerous CWEs?
  • Invalid Input Validation (CWE-20)
  • Out-of-Bounds Reading (CWE-125)
  • Incorrect Restriction of Operations in the Memory Buffer (CWE-119)
• What Is CWE Compatibility?
• CWE vs. CVE
• What Is CWSS and How Does It Compare to CVSS?
• How HackerOne Can Help

What Is the CWE Top 25?

The CWE Top 25 is a vulnerability list compiled by the MITRE corporation. It lists the common security vulnerabilities with the most severe impact based on the Common Weaknesses and Exposures (CWE) database. It results from ongoing research, including interviews and surveys of security analysts, suppliers, and developers.

The CWE Top 25 maps information from the US government’s National Vulnerability Database (NVD), with severity ratings based on the Common Vulnerability Scoring System (CVSS). The scoring algorithm determines the severity of the vulnerabilities using a data-driven approach to update the list periodically.

The 2022 CWE Top 25 includes:

1. CWE-787 – out-of-bounds writing. Severity score: 64.20
2. CWE-79 – improperly neutralizing input when generating web pages (cross-site scripting). Severity score: 45.97.
3. CWE-89 – improperly neutralizing special elements in SQL commands (SQL injection). Severity score: 22.11
4. CWE-20 – improperly validating input. Severity score: 20.63.
5. CWE-125 – out-of-bounds reading. Severity score: 17.67.
6. CWE-78 – improperly neutralizing special elements in operating system commands (OS command injection). Severity score: 17.53.
7. CWE-416 – using after free. Severity score: 15.50.
8. CWE-22 – improperly limiting pathnames to restricted directories (path traversal). Severity score: 14.08.
9. CWE-352 – cross-site request forgery (CSRF). Severity score: 11.53.
10. CWE-434 – unrestricted uploading of files with dangerous type. Severity score: 9.56.
11. CWE-476 – NULL pointer dereferencing. Severity score: 7.15.
12. CWE-502 – deserializing untrusted data. Severity score: 6.68.
13. CWE-190 – integer overflow or wraparound. Severity score: 6.53.
14. CWE-287 – improper authentication. Severity score: 6.35.
15. CWE-798 – using hard-coded credentials. Severity score: 5.66.
16. CWE-862 – missing authorization. Severity score: 5.53.
17. CWE-77 – improperly neutralizing special elements in commands (command injection). Severity score: 5.42.
18. CWE-306 – missing authentication for critical functions. Severity score: 5.15.
19. CWE-119 – improperly restricting operations in memory buffers. Severity score: 4.85.
20. CWE-276 – incorrect default permissions. Severity score: 4.84
21. CWE-918 – server-side request forgery (SSRF). Severity score: 4.27.
22. CWE-362 – concurrent execution with shared resources and improper synchronization (race condition). Severity score: 3.57.
23. CWE-400 – uncontrolled resource consumption. Severity score: 3.56.
24. CWE-611 – improperly restricting XML external entity references. Severity score: 3.38.
25. CWE-94 – improper control of code generation (code injection). Severity score: 3.32.

CWE Examples: Which Are the Most Dangerous CWEs?

Following are three vulnerabilities from the CWE Top 25 which present a serious security risk.

Invalid Input Validation (CWE-20)

This vulnerability relates to problems in an application’s data flow. If the application doesn’t properly check all data, inputs can end up in unwanted places. This error affects applications that accept extrinsic data, allowing attackers to change data flows or execute arbitrary code. Attackers can inject malicious code into an existing data object to access confidential information.

Out-of-Bounds Reading (CWE-125)

This vulnerability is ubiquitous across many applications. It occurs when a system’s buffer cannot control the amount of data consumed by the software. This error allows attackers to read sensitive data like virtual addresses and exploit memory locations. It may also cause the system to crash.

Many hackers use segmentation faults and buffer overflows to exploit out-of-bounds reading vulnerabilities. Developers must use input validation methods to mitigate the risk, especially in C or C++ code.

Incorrect Restriction of Operations in the Memory Buffer (CWE-119)

This vulnerability allows the software to read over a memory buffer’s specified boundary. It lets attackers introduce malicious code by replacing 64 memory bits. They can damage the application’s memory and compromise critical security data.

Memory buffer vulnerabilities enable hackers to retrieve sensitive data, change control flows, execute malicious code, and crash the target device. The programming language, platform, and chip architecture influence the impact of this issue. Managing memory helps reduce the risk.

What Is CWE-Compatible Software?

The CWE compatibility program registers products or services as either CWE-Compatible or CWE-Effective. Compatible products assist organizations in assessing their applications for known weaknesses and flaws. For CWE compatibility qualification, the service product must meet the first four of the six requirements, while CWE-Effective products and services must meet all six.

1. CWE Searchable – users may search elements using CWE identifiers.
2. CWE Output – elements presented to users include, or are obtained associated CWE identifiers.
3. Mapping Accuracy – security elements accurately link to the appropriate CWE identifiers.
4. CWE Documentation – capability’s documentation describes CWE, CWE compatibility, and CWE-related functionality.
5. CWE Coverage – capability’s documentation explicitly lists the CWE-IDs that the capability claims coverage and effectiveness against.
6. CWE Test Results – for CWE-Effectiveness, the capability’s test results must show an assessment of software for CWEs, and the test results must appear on the CWE website.

CWE vs. CVE

The primary difference between CWE and CVE is that CWEs highlight the vulnerabilities, not the specific instance of one within a product.

For example, a CVE might detail a particular vulnerability within an operating system that allows attackers to execute code remotely. This CVE entry only details this vulnerability for a single product.

A CWE outlines the vulnerability independent from any product. CWE has become a common language for discussing eliminating or mitigating software security weaknesses. Because developers have access to data regarding weaknesses early in product lifecycles, they can build products without vulnerabilities eliminating subsequent security issues. This allows developers to keep pace with rapid development lifecycles, build better products, release them faster to customers, minimize attack surfaces, and prevent more cyberattacks.

A few examples of a CWE are below:

• Out-of-bounds Write
• Cross-site Scripting
• Improper Input Validation
• Missing Authentication for Critical Function

What Is CWSS and How Does It Compare to CVSS?

The key difference between CWSS and CVSS is that while CVSS is reactive, CWSS is a proactive approach to cybersecurity.

CVSS stands for Common Vulnerability Scoring System, numerically scoring vulnerabilities based on risk. Vulnerabilities are security flaws that attackers can exploit to gain access to a system.

Common Weakness Scoring System (CWSS) is a framework that documents software weaknesses so developers can minimize the number of bugs and vulnerabilities they introduce in a live system.

The biggest difference between scoring systems is that the CWSS is proactive, whereas the CVSS is reactive. Both scoring systems can prevent vulnerabilities and prioritize the remediation of existing flaws when security teams use them together.

CWSS uses three criteria to help developers prioritize software-based weaknesses:

• Attack Surface – the availability of the weakness
• Base – the risk of weakness, degree of accuracy, and effectiveness of controls
• Environmental – the parts of the weakness that are environmentally specific scoring for CWSS ranges between zero and 100.

CVSS uses similar metrics when calculating scores but works on a range of zero to ten using the following criteria:

• Base – the characteristics of the security flaw
• Temporal – a metric that changes with time due to external factors
• Environmental – a metric that measures the impact of the vulnerability in your organization

While remediation teams can use both systems, their scores are not compatible. Even if the scores were normalized, their numbers would reflect differently across each system.

How HackerOne Can Help

HackerOne brings specialized skills and domain expertise to help security teams scale testing across attack surfaces. With the perspective of skilled experts, varied approaches, experience, and knowledge, ethical hackers submit vulnerabilities that traditional scanning tools miss. HackerOne’s vulnerability taxonomy includes a more complete weakness database based on the industry-standard CWE. Customers can rely on HackerOne data to deliver otherwise unavailable vulnerability intelligence and use that data to improve security strategies. Vulnerability reports are labeled with a weakness, either by the hacker at report submission or later by our Triage team. This allows organizations to first address the most critical vulnerabilities, mitigating cyber risk and providing greater protection for their attack surfaces. Contact us to learn more.