Contrast Labs: Mapping Risk Profiles for Select OWASP Top 10 Vulnerabilities to Understand Their AppSec Risk

At Contrast Security, the Contrast Labs team is charged with numerous things. Part of this charter includes looking at threat intelligence and understanding the true threat landscape. This encompasses risks that different vulnerabilities may pose to an organization.

In my case, having spent nearly 20 years in application security (AppSec), I have an ingrained belief that “all things are bad,” and that developers simply need to fix them. And while that may be a correct understanding for traditional approaches to AppSec, this assumption does not need to be the case today.

Developers Write Volumes of Code

Development teams are moving extremely fast: Developers write an average of 325 to 750 lines of code (LOC) per month. And with over 23.9 million developers worldwide, this amounts to a lot of code. Some large organizations have thousands of applications and technical debt related to security that would make any security professional blush a bit and worry about keeping their jobs. “WE CAN’T POSSIBLY FIX THEM ALL!” becomes our battle cry. Many believe this to be the case and are ok with it, as it seems to be the stark reality.

Through the Lens of the OWASP Top 10 2017 Standards

So, how do we use data and threat intelligence to make sense of all of this? Let’s start by looking at the OWASP Top 10 2017 that is embraced as a security standard across industries and even compliance and regulatory bodies such as the Payment Card Industry Software Security Framework (PCI SSF).

The OWASP Top 10 is a good place to start for an AppSec program. However, do all of the listed vulnerabilities really have the same risk profile? We can begin by breaking a few of these down further by examining public Common Vulnerabilities and Exposures (CVE) data as they relate to Common Weakness Enumeration (CWE). We can then see how they are rated from a risk perspective using the Common Vulnerability Scoring System (CVSS).

Mapping Select OWASP Top 10 to CWEs

Contrast Labs chose the below due to the fact that we can map them to a direct CWE or a few more egregious vulnerabilities. The other OWASP Top 10 categories are much broader and map to many different CWEs.

A1:2017-Injection

Command Injection (CWE-77)/OS Command Injection (CWE-78). Malicious actors use command injection to execute arbitrary commands on an underlying host operating system. These malicious actors can determine where a vulnerable application may take user input and derive a system command from the input. The input can be from any part of an HTTP request, including parameters, headers, cookies, and so forth. The ultimate goal is to execute commands on the underlying operating system that could lead to data exfiltration, privilege escalation, or in some cases, installation of malware.

SQL Injection (CWE-89). A SQL injection occurs when a malicious actor inserts or injects code into a SQL query through an input, typically an HTTP request parameter or header. A malicious actor would do this to perform CRUD actions on a back-end database to pilfer sensitive data, modify data, perform actions of a privileged user, or even delete data or tables. This type of attack could result in full compromise of confidentiality, integrity, and availability with regard to the data and access to the data in a database.

A4:2017-XXE

XML External Entity (CWE-611). XML External Entity (XXE) attacks are used by malicious actors seeking to take advantage of applications that parse XML. These malicious actors exploit XML parsers that allow referencing external entities that then get processed by the underlying XML parser. External entities are defined values loaded from outside of the Document Type Definition (DTD) in which they are declared. These external entities can be derived from a file path or URL. Malicious actors use this type of attack to gain access to sensitive data and perform a distributed denial-of-service (DDoS) attack. In some cases, they perform server side request forgery (SSRF) attacks.

A5:2017-Broken Access Control

Path Traversal (CWE-22). Path traversal, which is also known as a directory traversal attack, is used by malicious actors to gain access to files on the system to which they may not necessarily have access through normal usage of the application. This is accomplished through manipulation of parts of an HTTP request, be it parameters, headers, and so forth, by adding the famous dot-dot-slash (../) over and over and over. Some, OWASP included, classify path traversal as an access control issue—and it is partially such—though it could also be classified as an injection issue due to the manipulation of HTTP input with the dot-dot-slash.

A7:2017-XSS

Cross-Site Scripting (CWE-79). Malicious actors use Cross-Site Scripting (XSS) attacks to inject malicious scripts into websites. Successful XSS-initiated exploitation attacks result in a bad actor creating malicious code, typically in the form of JavaScript, that is used to prompt another user to interact with the code typically through a link or by storing the code in the website to be later viewed by an unsuspecting victim. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.co

A8:2017-Insecure Deserialization

Insecure Deserialization (CWE-502). Insecure deserialization (aka untrusted deserialization) is a web application vulnerability that enables users to pass arbitrary objects or code to a deserializer. In this kind of attack, untrusted data abuses the logic of an application to inflict a DDoS attack, achieve authentication bypass, enable remote code execution, and even execute arbitrary code as it is being deserialized.

Examination of the Risk of CVEs

Contrast Labs chose the above vulnerabilities, as they can be quickly mapped to CWEs. We also can ascertain the risk of each known CVE based on their CVSS score. We did so by investigating the percentage of each CVE as mapped to a specific CWE based on its base CVSS score:

• 1–3.9: Low Risk
• 4.0–6.9: Medium Risk
• 7.0–8.9: High Risk
• 9.0–10.0: Critical Risk

We looked at each CWE and broke the CVE percentages down by looking at the percentages greater than or equal to nine, greater than or equal to eight, all the way down to four. Anything below four was not included, as many organizations deem low-risk items as less important.

A1:2017-Injection. A1:2017-Injection and CWE-77, CWE-78, and CWE-89 vulnerability classes are commonly regarded as egregious and dangerous, and most organizations would classify them as high risk. The numbers do not lie either:

Figure 1: Three injection vulnerabilities with the majority having CVSS scores of 6.0 or higher.

What we gather from these numbers, as expected, is that these injection types are very risky for an organization. All three of them are above 90% for a CVSS score of six or above—equating to a high medium, high, or critical risk. An organization would be right in making these vulnerability classes top of mind when developing an AppSec program to ensure the right protections are in place to protect their applications from them.

A4:2017-XXE. Let’s take a look at A4:2017-XXE—namely, CWE-611—next. XXE is still prominent among web applications, as modern technology stacks still allow for the processing of XML data. The numbers don’t lie and look very similar to an A1:2017-Injection:

Figure 2: XXE vulnerabilities with the majority having CVSS scores of 6.0 or higher. 

A5:2017-Broken Access Control. Next in our queue is A5:2017-Broken Access Control—namely, CWE-22. Path traversal has been around forever, and web and application servers now have built-in protections with regard to accessing certain files. However, path traversal remains a problem, and the CVSS numbers tell a similar story.

Figure 3: Path traversal vulnerabilities with the majority having CVSS scores of 5.0 or higher. 

Now, if we look a little further here, we can determine that CWE-22 and CWE-611 do not pose as much risk overall as injection vulnerability types. Both path traversal and XXE have the majority of their CVSS base scores at five and up, whereas the injection vulnerabilities tip the scales at a CVSS base score of seven and up. As a result, we can conclude that most XXE and path traversal vulnerabilities are medium risk and injections are higher or critical risks.

A7:2017-XSS. XSS is prevalent in web applications and has been forever talked about as something that poses high risk. One of the most widely known XSS attacks was against MySpace back in 2005. Dubbed as the “Samy worm,” Samy Kamkar took down MySpace by using a stored XSS exploit that propagated from user to user until it overwhelmed the back-end database.

Sounds terrible, right? At the time it was. However, since this attack occurred, we have not witnessed a comparable attack at that magnitude. Let’s look at the CVSS scores and see if they tell a different story.

Figure 4: XSS vulnerabilities with the majority having CVSS scores of 4.0 or higher.

Whoa! These results are surprising—the overwhelming majority of XSS CVEs are rated in the CVSS base score in the four to five range, which is on the low end of a medium risk. Further investigation reveals more findings of interest: Another 22% of the XSS CVEs have between a three and four CVSS base score. When this data is aggregated, it equates to 97% of XSS CVEs      falling into a CVSS score range of three to five—a low to medium risk.

So why is so much effort placed on fixing XSS over and above all else? To begin, the vast majority of CVEs come from third-party or open-source libraries that could definitely have an impact on the calculated CVSS base scores. Also, most libraries don’t really have the web front end that is typically required for a successful XSS exploit. Either way, the data is interesting and worth heeding.

A8:2017-Insecure Deserialization. For the most part, insecure or untrusted deserialization leads to some sort of remote code execution or DDoS attack—which should result in a high-risk categorization. Indeed, the well-known breach at Equifax was due to an untrusted deserialization issue in the Apache Struts 2 Java framework (CVE-201-5638). All this aside, what do the CVE and CVSS numbers tell us?

Figure 5: Untrusted deserialization vulnerabilities with the majority having CVSS scores of 7.0 or higher.

Not unexpectedly, the majority of the untrusted deserialization CVEs are rated at a seven CVSS base score or above—an indication that they are at high risk.

Putting All the Data Pieces Together

Now that we have looked at each issue on their own, let’s put them together for a broader view of the OWASP Top 10.

Figure  6: Data showing XSS risk is much lower on average than others.

Risk decisions should not be made based on a single data point such as this one. However, for developers and security teams struggling to prioritize fixes or wondering which vulnerability classes have the most impact (which is really what the CVSS base score helps determine), a good starting point is to look at the data that is freely available such as CVEs and how they have been rated.                         

This is by no means an attack on the validity of XSS as a vulnerability class. However, over time, XSS has slowly moved down on the OWASP Top 10. It remains on the list as it still is very important to many security analysts—it is used in attack kill chains and is still prevalent across the web. Indeed, for that matter, none of the other CWEs mentioned in this post even have half of the number of CVEs that XSS claims; the next closest is SQL injection at 48%.

All of this data alone does not mean XSS—or the other CWEs mentioned in this post—should or shouldn’t be in your top 10 vulnerabilities. However, as a bug hunter on many bug county platforms, I have noticed decreasing bounty values for XSS submissions due to their sheer prevalence and overall risk. In sum, should we fix XSS? YES, we definitely should do so, but maybe there are other riskier issues on which we should focus first due to their overall risk.

For more information on the latest application vulnerabilities and attacks, make sure to check out our latest “Bimonthly Application Security Intelligence Report.”