The common software vulnerabilities on our top 10 software vulnerability list for 2019 are easy to find and fix with the right AppSec tools and guidance.
In a perfect world, all software would be without flaws or weaknesses. Or at least software vulnerabilities would be definitively ranked in terms of frequency; ease, likelihood, and business and technical impact of exploitation; and tools and resources needed to detect and remediate. That way, developers would know exactly what to focus their resources on and when to consider the job done.
In this world, there isn’t such a list. But the high-risk and common software vulnerabilities described by OWASP (including the OWASP Top 10 2017 and the OWASP Top 10 Mobile) and MITRE (CWE/SANS Top 25), among others, are a good start. These lists cover a range of software environments, including web apps and mobile apps, which account for the majority of enterprise applications. Vulnerabilities are chosen based on many criteria, such as how common the threats are, how easy they are to detect and remediate, and their potential technical and business impacts.
We can’t tell you which software flaws will pose the most threat to your business in 2019. And we can’t tell you which ones are most likely to cause the next data breach. Instead, we’ve chosen 10 common software vulnerabilities whose remediation offers a high rate of return for your remediation efforts. These application risks are widespread among web apps or mobile apps and are easy to exploit. But many can be detected using automated tools such as static analysis, without the need for extensive manual code review. And with the right guidance, they can be cheap to remediate. In other words, these common software vulnerabilities are low-hanging fruit not only for attackers but also for developers—even those with limited application security resources.
In no particular order, here’s our top 10 software vulnerability list for 2019.
Buffer overflows are among the most well-known common software vulnerabilities. When you try to put something that’s too big into memory that’s too small, of course unpredictable things happen. The most popular web app languages (e.g., Java) protect against this type of vulnerability. But many mobile apps are written in C/C++, a language family that’s famously vulnerable to buffer overflows. See buffer overflow and incorrect buffer size calculation.
Also known as “path traversal,” this type of vulnerability allows attackers to gain access to files and directories that aren’t part of your website. The attacker simply sends a file or directory request with the character sequence “../” (hence the alternative name “dot dot slash attack”), which points to the parent directory. This vulnerability is especially treacherous when combined with others, such as the insecure storage of sensitive data. See path traversal.
Loss of connectivity threatens customers temporarily. But loss of sensitive data threatens customers for the rest of their lives—and can have severe consequences for your business. Admittedly, protecting data in transit is hard. But at least you can use strong encryption on all data at rest (i.e., stored data). See insecure data storage, insufficient cryptography, sensitive data exposure, missing encryption, and broken or risky cryptography.
No one writes code from complete scratch these days. All modern code contains some existing code, whether in the form of self-contained modules or snippets “borrowed” from other codebases. But the convenience of code reuse comes with threats: New vulnerabilities are discovered all the time. Malicious actors can take over trusted components. And if you don’t know what’s in your codebase, you can’t track it or fix it. See using components with known vulnerabilities.
While the use of web services and APIs is exploding, API security hasn’t kept up with this growth. Threat actors can sometimes access sensitive data directly via unsecure services and APIs. But organizations must also be sure to implement web service and API calls securely in their own mobile apps. Otherwise, those applications become another interface by which an attacker can access their systems. See improper platform usage.
If you control access to your log files (e.g., the ones on your web server), thorough logging is a plus. Doing so can help you detect an attack and determine its scope and potential damage after the fact. But sometimes you don’t control access to the log files (e.g., the ones on your users’ devices). In that case, the “more is more” paradigm doesn’t necessarily apply. All the information that helps you trace vulnerabilities can help an attacker do it too—especially if it’s unencrypted. See insufficient logging and extraneous functionality.
Cross-site scripting refers to a family of attacks where attackers execute their own code in the browsers of your website visitors. XSS attacks can also occur in your mobile apps if they display webpages, such as FAQs and Help pages. It’s the second most prevalent issue on the OWASP Top 10 2017, and the CWE/SANS Top 25 says it’s “one of the most prevalent, obstinate, and dangerous vulnerabilities in web applications.”
Authentication refers to ensuring that users are—and continue to be—who they say they are. Initial authentication usually takes place at log-in. Continued authentication occurs through session management. Some types of authentication vulnerabilities take more effort to detect than others (e.g., weak password requirements vs. session timeouts). See missing authentication, excessive authentication attempts, broken authentication, and insecure authentication.
Authorization refers to creating policies for users, their roles, and the actions they may perform. And access control is how a system ensures that users cannot perform unauthorized actions. As with authentication issues, some access control issues are easier to find than others (e.g., missing authorization vs. poorly defined access lists). See broken access control, insecure authorization, missing authorization, and incorrect authorization.
In SQL injection, an attacker submits code as input (e.g., in a text box) in such a way that it executes against the database. SQLi is one of the most well-known and common software vulnerabilities, in part because it’s so easy to understand and exploit. Researchers and hackers have been writing about it for over two decades, yet it’s still extremely common. Other types of code injection have also proven to be persistent issues. See SQL injection and injection.
Most of these common software vulnerabilities threaten most web or mobile development to some degree. But not all software issues are problematic for all organizations, or even all developers on a team. So why not create a customized list of the top 10 vulnerabilities for your organization or yourself?
A good starting point is your application security testing tools. Many AppSec tools can show you trends in the frequency and types of the vulnerabilities they find. The datasheets for OWASP Top 10 coverage and CWE/SANS Top 25 coverage for Coverity static analysis will give you an idea of what types of vulnerabilities an automated static analysis tool can detect.
Another source of vulnerability information is your application security team. Ask them what kinds of complex vulnerabilities they tend to see, especially the ones automated tools can’t detect. Then, with your customized list of top 10 software threats in hand, you’ll be able to build a stronger case to equip yourself and the rest of your team with targeted training and better tools. Our free eBook Who Needs OWASP? has more information.