Skip navigation to main content

OWASP : Using Components with Known Vulnerabilities

Security specialist Jonathan Jenkyn continues his posts with a focus on OWASP; this post covers Using Components with Known Vulnerabilities.

This is the ninth in a series of posts on the OWASP Top Ten

This should be really easy, right? You've got a single Ubuntu web server (14.04.3) running Apache Tomcat (7.0.65). Your web application uses JRE (8u65) and directly includes 49 third party libraries/components, 37 of which have version dependencies on specific other third party libraries/components, bringing the total number of dependencies to just over 300. You need to monitor not only the standard CVE and NVD feeds for vulnerabilities you might be affected by, but also have to monitor reports from both open-source and vendor channels (email, support forums and feeds) for vulnerabilities that might affect your deployment… all of which use different version numbering systems and non-standard search mechanisms.

Ok… it's a train wreck!

Nightmares to Dreams

With a little bit of pro-active laziness (!), you can have this one wrapped up fairly quickly.

  1. First of all, create some policies governing the usage of components in your applications. Make sure that this includes what tests they must meet, perhaps patterns for their inclusion and acceptable licences (GPL2 is very different to GPL3, for instance).
  2. Next consider putting wrappers around the third party components you include. If you're only making use of 5% of the methods available from a package, wrap the component so that only those methods you are actually making use of are exposed, this way if a vulnerability is discovered in one of the other methods, you're in the clear!
  3. Next, keeping a record of each dependency and its version for each release you make is crucial. Having a manifest of the components you've included is really important to the overall vulnerability management piece, and we'll need it for the other steps. There are plugins for most deployment engines out there that will help you achieve this… so use them! (versions for maven being one I've used)
  4. Next, you're going to have to keep an eye on some forums and feeds. Using some filtering technologies will help you sift the wheat from the chaff here. Google has some neat email alerting that you can use to great effect here, but you’re going to need to use that manifest from step (3) as a mechanism to help drive the filters here. Better to get false positives than filter out vulnerabilities that really do affect you.
  5. Finally, make sure that you have correctly and appropriately trained staff monitoring and assessing those vulnerabilities that are identified as potentially affecting your deployment. This comes down to making sure you have a good Vulnerability Management Policy in place, and making sure that the process roles and responsibilities are distinct and understood by everyone affected by the policy. Too often the guy that finds the vulnerability, is the same guy that classifies it, decides to fix or absorb, and implements to the fix. These are all different roles, with different responsibilities, so they should be different people.

 

OWASP have a project which looks specifically at tackling some of the topics that arise regarding component usage in project, check it out at the OWASP website here: https://www.owasp.org/index.php/OWASP_Good_Component_Practices_Project

At KCOM we have numerous projects in service management, in delivery and in implementation at any one time. Each of which will have a very diverse mix of dependencies and technologies. Having a clear policy and process for managing these components is crucial to our success as technology integrators.

Next time :  Unvalidated Redirects and Forwards

Join the conversation on Twitter@OWASP   #OWASPtop10   #VulnerableComponents