Third party components play a huge role in web applications. Libraries, frameworks and system components are used on the vast majority of websites.
Using third party code is an opportunity to cut down development time and difficulty.

But what is the impact in terms of security?

What is a third party component?

A 3rd party component is any piece of software that can be reused and that is developed and distributed by another entity. It can be an open-source component, or a commercial one. We can find different categories of third party components, such as:

  • System components (e.g. OpenSSL)
  • Web servers (e.g. Apache httpd, Nginx, IIS, Tomcat…)
  • Execution engines, interpreters, back-end environment (e.g. .net, Java, PHP, Ruby, Python…)
  • Frameworks (e.g. Symfony, CakePHP, .Net, Spring, GWT, Rails…)
  • Libraries (e.g. Assetic, Validation, jQuery, JUnit, Lucene, PDFSharp…)

What are the biggest risks with 3rd party components?

Users are usually not aware of updates, meaning that a vulnerable component might remain on a production server for a while without being updated.
Being aware of updates requires a proactive approach. By simply downloading and installing a component, developers are not systematically registered on anything that would notify them about security updates, or any other usual update.

On top of this, being aware of updates then requires some budget and time in order to effectively apply these updates (with the necessary functional validations, technical validations and deployment to production).

Failing third party component, gear - illustration

The turnover in technical teams and the lack of documentation is also a good reason for third party components to go stale inside web applications.

As a result, web applications leveraging these 3rd party components and benefiting from the open source world also benefit from more or less dangerous security flaws.
The exact nature of the vulnerability and the resulting impact really depends on the affected component, on the way it has been integrated into the app, and on the business case.

Examples of security flaws brought by third party components

jQuery DOM XSS via # selector

Old version of jQuery are vulnerable to DOM XSS attacks (CVE-2011-4969 – https://www.cvedetails.com/cve/CVE-2011-4969/).
The following link shows which versions of the library are vulnerable : http://domstorm.skepticfx.com/modules?id=53990c76fd987e64ab000002

ExtJS

Like many other libraries, ExtJS has been delivered with some vulnerabilities, at some point in time.
The CVE detailed on this page (http://www.cvedetails.com/cve/CVE-2007-2285/) gives us some indications about one vulnerability that affects example files delivered with the library.

By exploiting the vulnerability and under specific conditions, it is possible to access any file on the system (like /etc/passwd, or source code of an application that is hosted on the server).

How to enhance your security when working with 3rd party components

Organizations must take steps to maximize controls over 3rd party code. Tracking which components are downloaded, incorporated into projects, but also which of them require updates or need to be removed.
These steps require both processes and tools, with clear responsibilities within development teams. Below is an organizational proposal aiming at driving the flow of this external source code and reducing the probability of 3rd party vulnerabilities on your production applications.

Four objectives: Catalog, Analyze, Control and Monitor. Each objective consists of different actions (processes).

  • Catalog
    • Identify components used in projects
    • Maintain a central catalog of components
  • Analyze
    • Detect vulnerabilities in components
    • Get rid of unused components (on a project basis)
  • Control
    • Implement a central components repository
    • Establish a global policy around components
    • Control project when releasing new versions
  • Monitor
    • Detect available 3rd party component updates
    • Blacklist components that are not maintained

The overall mission is to put in place a complete follow-up of components used in your projects, from the initial selection of the component to planning its retirement.

A number of solutions are available to manage third party components, and can be separated into two categories: manual, and automated, with of course intermediate solutions mixing both approaches.
If you start from the ground, implementing these processes is really a good bargain and will help you taking big steps forward.

Automating

Different solutions are available on the market to automate and strengthen these controls.
Some of these tools are open source, others are commercial. Some are limited to a certain range of third party components, some include additional checks such as licenses.

We will go through these different solutions in one of our upcoming articles. Stay tuned!