OWASP Top Ten - Using Components with Known Vulnerabilities
Components are used in practically every codebase. Unfortunately, this also means known vulnerabilities exist in many of those components. These vulnerabilities put the entire application/API at risk.
That’s why OWASP identified “Using Components with Known Vulnerabilities” as one of their Top Ten Web Application Security Risks.
All examples of potential attacks in this article are for demonstration and educational purposes only. They should never be used outside of a lab environment or to harm other computers, users, etc.
Using Components with Known Vulnerabilities
This vulnerability is a pretty common sense one.
We all probably use other people’s code (components) in our application or API, but most of us probably don’t know:
- all the different components, and their dependencies, in use
- if they need to be updated
- if they’re no longer being maintained
If you know all 3 of those above you’re in excellent shape and probably don’t need to keep reading.
If you’re unsure about any of those areas, then you should definitely keep reading.
What are Components?
Essentially, components are blocks of 3rd party code that you integrate into your codebase.
In WordPress, components would be like plugins. They’re built by 3rd parties and you can plug them into your codebase to expand its functionality.
In many applications, components are 3rd party libraries or a larger self-contained package of software you can include in your codebase. jQuery is a good example of this type of component. It’s a popular library that makes writing JavaScript easier and is commonly used in many web applications.
Benefits vs Risks of Components
Components can offer lots of benefits. They allow us to quickly expand the functionality of our code and can even increase its security.
We do not, and should not, write our own encryption libraries. Instead, we use reputable 3rd party libraries whose focus is solely on encryption and, hopefully, know how to do it right.
But, like everything, using components introduces risks.
Because this is code written by someone else, we probably don’t know if it was written securely or if it currently contains vulnerabilities. We may not know if the project was recently taken over by a malicious actor or if new vulnerabilities were accidentally introduced in the latest update.
Components are often open source and used in many applications across the web. This makes it easier for attackers to find and exploit vulnerabilities.
Testing for Known Vulnerabilities in Components
While prevention is much more effective than testing, you should still perform regular vulnerability scanning as an additional layer of defense.
Possible Ways to Help Prevent Using Components with Known Vulnerabilities
According to OWASP, there are a few things you should be doing to identify and prevent component vulnerabilities from putting your application or API at risk.
-
Continuously identify all components in use and their dependencies
Just like with asset management, we need to know what we’re using - especially when things change. Some tools that can help with this include versions, DependencyCheck, and retire.js. -
Monitor for known vulnerabilities
Specifically, you should subscribe to security bulletins for components in use and their dependencies. You can also regularly check CVE and NVD for known vulnerabilities. -
Monitor for unmaintained or unpatched components
Would you know if a component in use or its dependency stops being maintained? Would you know if a component or its dependency stopped releasing security patches? This is a little tougher to keep track of, but it’s important to know if a component you use, and its dependencies, are still being regularly maintained and patched. -
Apply software patches quickly
Once you know you have a vulnerable component, time is of the essence. Try to patch it as quickly as you can. If, for whatever reason, patches can’t be applied, consider using virtual patches. -
Periodically remove unused components
Good patch management includes keeping things cleaned up. If you have a good process for identifying and removing unused components, that will greatly improve your security and make ongoing patch management much easier.
Sum It Up
We all use components in our codebases. They make things easier, but they also introduce risks.
Keeping an eye on things with a well functioning patch management and monitoring system will help to greatly reduce the risk of using components with known vulnerabilities.
Like everything with security, this topic can be complex. Check out the resources below to help further your knowledge and keep learning so you can build customized solutions that work for your situation.