I believe in code re-use. You believe in code re-use. No-one wants to re-invent the wheel, especially not if there is a really great, aero-dynamic, ultra-fast wheel available.
That's why we use libraries and components. But those libraries and components are not written by super-humans. They are written by people like you and me - people who make mistakes.
Don't upset the cart(on)
Once our application is in production, we often don't think about the 3rd party components until we need to change the system.
In fact, we might resist the idea of upgrading just those components. Why? Because we'll need to test everything again. In theory, it should all work ... but sometimes our code is more fragile than we like to admit.
And that leaves us exposed to both the vulnerabilities in our code and in the 3rd party components.
An example: JQuery
According to statistics from W3Techs listed on Wikipedia, 74.4% of the top 10 million websites used JQuery in February 2020. That's 7,440,000 sites! It's also integrated into other products, like Drupal and WordPress themes. It's the most widely deployed JavaScript library in the world.
JQuery provides great cross-browser functionality. But it's not perfect. Many versions of JQuery have known vulnerabilities relating to Cross-site Scripting. XSS, which I'll talk about in a later email, allows hackers to embed malcious JavaScript code in your website.
It's easy for anyone to find out what version of jQuery you are using. And that makes it easy to know what vulnerabilities to target on your site.
An example: Equifax
It's not only client-side libraries that have vulnerabilities. Server-side libraries and components can also leave you exposed.
In March 2017, Equifax had a massive data breach. The personal data of millions of people was stolen from this US credit reporting agency. The main cause of the hack was a known vulnerability in Apache Struts, a Java development framework. The Apache Foundation had released a patch for the bug. Equifax administrators had been told to apply the patch, but ... well, somebody didn't do it.
Take action now
If you don't have a patch management process in place for checking your components, start now:
- Make a list of all the components you are using in your applications. Note their version numbers and where they are being used.
- Check the National Vulnerability Database to see if there are any known vulnerabilities.
- Set up an action plan to install the latest version, and of course, test everything again.
Extra reading
This is #6 of the OWASP Top 10 vulnerabilities. Find out more at OWASP: Vulnerable and Outdated Components .
If you haven't already, join our Security Spotlight series. You'll get a weekly email about web application security.