OWASP Top 10: Using Components with Known Vulnerabilities (A9:2017)

26th August 2020 ‧ By Simon Bell ‧ Category: Web Application Security

3 min read

This is part of the OWASP Top 10 series covering the top 10 most critical web application security risks. If you've missed any of the previous security risks, check out the intro and overview.

Risk rating

What are components with known vulnerabilities?

Web applications often make use of existing libraries and frameworks. This makes development easier since common functionalities can be re-used to save time.

For example: React is a popular front-end JavaScript framework/library that allows developers to create complex front-end applications more easily than using just vanilla JavaScript.

If an attacker can find a vulnerability in such a library then it can have wide-spread and significant implications - since the library may be used by millions of web applications.

Examples of using components with known vulnerabilities

Let's say Bob runs his web app on a server. He encrypts all HTTP traffic to and from his app via SSL/TLS. Unfortunately, Bob uses an unpatched version of OpenSSL which contains the Heartbleed Bug (CVE-2014-0160). Mallory tests Bob's web app for the Heartbleed Bug using the nmap command:

nmap -sV --script=ssl-heartbleed <bobs-server-IP>

The nmap command returns State: VULNERABLE. Mallory can now carry out an attack on Bob's server and access the server's memory, compromising the secret keys used to encrypt traffic.

In another example, Alice uses WordPress to manage and deliver content on her website. Unfortunately, one of the WordPress plug-ins she uses has a known vulnerability which allows visitors to upload files to her website. Mallory discovers this vulnerability and uploads a PHP script to Alice's website. Mallory can now access hidden files, modify content, alter security settings, etc.

What's the impact of using components with known vulnerabilities?

The impact of using components with known vulnerabilities will vary depending on the severity of the vulnerability and what data the organisation holds. Some vulnerabilities may lead to minor impacts and minimal damage. However, more severe vulnerabilities can lead to a total compromise and data breach.

How to defend against components with known vulnerabilities

As part of the security policy there should be a patch policy implemented. Unused components, dependencies, files, directories, etc should be removed or disabled.

All software components should be regularly checked and updated -- this includes both server-side and client-side libraries and frameworks. As part of the auditing process, sources such as CVE and NVD should be checked to determine if known vulnerabilities have been discovered. Software composition analysis (SCA) tools can be used to help automate this process.

Ensure components are only obtained from reliable sources and either hash digests or signed packages are used to minimise the chances of using components that have been maliciously modified or altered. Using old or outdated components should be minimised since patches may not be released. 

Ensure the security policy for monitoring and applying patches is regularly reviewed and tested. It is not enough to check for updates once, it must be done regularly because new vulnerabilities are discovered every day.

More on OWASP Top 10

• OWASP Top 10: Intro
• OWASP Top 10: Injection (A1:2017)
• OWASP Top 10: Broken Authentication (A2:2017)
• OWASP Top 10: Sensitive Data Exposure (A3:2017)
• OWASP Top 10: XML External Entities (XXE) (A4:2017)
• OWASP Top 10: Broken Access Control (A5:2017)
• OWASP Top 10: Security Misconfiguration (A6:2017)
• OWASP Top 10: Cross-Site Scripting (XSS) (A7:2017)
• OWASP Top 10: Insecure Deserialisation (A8:2017)
• OWASP Top 10: Using Components with Known Vulnerabilities (A9:2017)
• OWASP Top 10: Insufficient Logging and Monitoring (A10: 2017)