Once every few years, OWASP releases a Top 10 list, featuring the ten most significant security risks related to developing web applications. OWASP makes this information available to developers around the world, so they can design and deploy safer technologies for everyone. The most current OWASP Top 10 is the version released in 2017, which replaced the list issued in 2013. The OWASP Top 10 #9 vulnerability is Using Components with Known Security Vulnerabilities.
Known Security Vulnerabilities are those gaps in security that have been identified, either by the developer/vendor of the products used, by the user/developer, or by the hacker/intruder. To exploit known security vulnerabilities, hackers identify a weak component in the system by scanning the system using automated tools (more common because these hacking tools are available online) or by analyzing the components manually (less common, because it takes more advanced skills).
Almost all applications have at least some vulnerabilities, due to weaknesses in the components or libraries the application depends on. Sometimes vulnerabilities are deliberate. Vendors have been known to leave “backdoor” vulnerabilities in their systems so that they can access the system remotely once it’s deployed. Most vulnerabilities, however, are unintentional. These are due to security gaps that are inherent in the design of the product.
Most vendors address vulnerabilities as they identify them and address the vulnerabilities either with product updates and patches or by releasing a new version of the product. Keeping the components and libraries updated with the latest patches and upgrading as soon as the newest version becomes available helps significantly reduce the number of known vulnerabilities that put the application at risk, but it’s becoming more common for developers to be unaware of all the components their applications are actually using, making it impossible to address all the vulnerabilities.
It actually should be relatively easy to determine if you’re using any components or libraries with known vulnerabilities, but proprietors and open source communities don’t always specify precisely which versions of their products are vulnerable, at least, not in a format that’s standardized and easy to search. Causing additional difficulties, not every library uses a version numbering system that’s easily understandable. Plus, vulnerability reporting to the vendor isn’t always centralized, meaning it isn’t collected and assembled into an easily searchable resource pool.
In order to assess your vulnerabilities, you have to search all of the various databases related to your components and stay on top of project mailing lists and announcements the company or community issues regularly. When you identify a known vulnerability in one of your components, you’ll need to check to see if your code actually uses the part of the component that’s vulnerable, as well as determining if the flaw actually impacts your application.
Another way to protect your applications against using components with known vulnerabilities is not to use any components except those you write yourself. However, that’s not an option in most production development environments. There’s just not time and money to develop all-new components from scratch for each new application. Usually, component vendors correct known vulnerabilities in new versions instead of releasing patches for older versions of the component. That means upgrading to new versions of all components as quickly as possible is the best way to stay ahead of these known vulnerabilities.
When developing a new web application, you should establish a means to:
The deeper a component is buried in the application, the harder it is for hackers to exploit. So consider how deep the component works within the application when determining how much time and effort to invest in closing the known vulnerabilities.
Unfortunately, hackers gain access to the same public databases and mailing lists that legitimate customers do. Additionally, hackers assemble and share lists of known vulnerabilities online, and use these lists to develop hacking tools that break into components and applications even if the attacker doesn’t have any personal knowledge or savvy with that particular component. So, legitimate developers need to become even more vigilant and savvy about protecting their applications than hackers are at attacking them.
Here are a couple of examples of how hackers use known component security vulnerabilities to cause trouble in your apps:
It also behooves the developer to choose components from proprietors and open source communities that take these vulnerabilities seriously. If your vendors consistently fail to identify and correct known vulnerabilities in their components or libraries, it’s probably time to move on to a vendor that does value the integrity and security of your web applications.
Kiuwan Insights (SCA) can help you identify and remediate security threats from using open-source code.
