This post is a continuation from my first Developer Blog post “PCI Check Up” – outlining the OWASP Top 10 web security vulnerabilities. We keep these security vulnerabilities in mind as we build out our own payments platform and provide integration points to our partner developers. In this post, I will review the number 9 OWASP web security vulnerability.
The number 9 vulnerability is Using Components with Known Vulnerabilities. Most modern web applications take advantage of third-party libraries or frameworks that facilitate application development. If those third-party components have vulnerabilities in them, then by extension any application that uses those components have security vulnerabilities. It seems fairly obvious, but many developers simply lose site of this concern.
A high-profile example of this kind of vulnerability was the Heartbleed bug in the OpenSSL library. When this vulnerability was announced, many and various applications became vulnerable because they included the OpenSSL library. Heartbleed is a severe vulnerability that was highly publicized, but the same thing can happen with other software components.
Mitigating this vulnerability is straightforward, but not something most developers care to do. The basic tasks necessary to mitigate this vulnerability are:
- Identify all third-party libraries, frameworks, and components in use in your application. It is also important to track the versions of these packages that are in use.
- Monitor the security of the components in use in your application. There are several sites and services that publish vulnerabilities. I follow www.us-cert.gov and www.sans.org. (Both of these sites provide published bulletins that make it easier to keep up with vulnerabilities.)
- When security vulnerabilities are discovered, first understand how the software provider is addressing the flaw. Next, you need to incorporate any fix from the vendor you’re your application. This is usually done by upgrading the affected component.
- Sometimes it is necessary to establish policies and conventions around what third-party components can be used in your application. These policies may include accepted vendors or certification requirements for third-party libraries.
Of the OWASP Top 10 list, this is not the most technical vulnerability, but it is easy to address.
