When developing software, we have to use 3rd party libraries in many cases. For example, if we want to send an email from our application, we would use a well known email sending library like apache.commons.email. If we want to make an HTTP call to an external website or an API, from our application we would use the httpclient library of apache. However before using a 3rd party library, it is important to check if there are any known security vulnerabilities reported against these libraries. For that, you can search in the National Vulnerability Database [1] and make sure it is safe to use the library in your application. However, it is difficult to do this manually when you have many external dependencies in your application. In such case, you can use a tool to do the search for you. OWASP Dependency Check [2] is an example for this which I am going to explain in this blog post.
Here I will explain how to use the command line tool of OWASP Dependency Check to analyze external dependencies and generate a report based on the known vulnerabilities detected. First, download the command line tool from the official website. At the time of this writing, the latest version is 1.4.3.
In the bin directory of the dependency-check tool, you can find the executable script. dependency-check.bat file is for running the tool on Windows and the dependency-check.sh file is for running on Linux.
If you just execute the script without providing any parameters, you can see the list of parameters that you need to provide for performing the vulnerability analysis and generating reports.
Following are the basic parameters that are required when running a vulnerability analysis.
Parameter
|
Description
|
--project
|
You can specify a name for the project and this would appear in the report
|
--scan
|
The folder which contains the 3rd party dependency libraries
|
--out
|
The folder where the vulnerability analysis reports should be generated
|
--suppression
|
An XML file that contains the known vulnerabilities that should be hidden from the report (false positives)
|
Now let’s do an analysis using OWASP Dependency Check. First I download commons-httpclient-3.1 and httpclient-4.5.2 libraries and put them in a folder.
Following is the sample command to run for performing the vulnerability analysis.
./dependency-check.sh --project "<myproject>" --scan <folder containing 3rd party libraries> --out <folder to generate reports> --suppression <xml file containing suppressions>
|
Here I skip the suppression and just do the analysis. I have put the above downloaded 2 libraries to /home/tharindu/dependencies/mydependencies folder in my filesystem and I would generate the reports to the /home/tharindu/dependencies/reports folder.
./dependency-check.sh --project "myproject" --scan /home/tharindu/dependencies/mydependencies --out /home/tharindu/dependencies/reports
|
When you run the OWASP Dependency Check for the very first time, it would download the known vulnerabilities from the National Vulnerability Database (NVD) and it would maintain these information in a local database. So, when running this for the very first time, it would take some time as it has to download all the vulnerability details.
By default the duration for syncing the local database and NVD is 4 hours. If you have run the Dependency Check within 4 hours, it will just use the data in local database without trying to update the local database with NVD.
Once you run the Dependency Check against the folder where your project dependencies are, it would generate the vulnerability analysis report.
Based on the analysis, I can see that the commons-httpclient-3.1.jar is having 3 known security vulnerabilities, but httpclient-4.5.2.jar is not having any reported security vulnerability.
Following are the 3 known security vulnerabilities reported against commons-httpclient-3.1.jar.
A known security vulnerability would have a unique identification number (CVE [3]) and a score (CVSS [4], a scalo from 0 to 10) and the severity. The severity is decided based on the CVSS score. The identification number follows the format CVE-<reported year>-sequence number.
When we identify that there is a known security vulnerability in a 3rd party library, we can check if that library has a higher version where this issue is fixed. In above example httpclient 3.1’s vulnerabilities are fixed in its latest version.
If the latest version of a 3rd party library is also having known vulnerabilities, you can try to use an alternative which has no reported vulnerabilities so you can make sure your project is not dependent on any external library that is not safe to use.
However there comes situations where you have no option other than using a particular 3rd party library, but still that library has some known vulnerabilities. In such case, you can go through each vulnerability and check if it has any impact to your project. For example, the 3 known issues in httpclient 3.1 are related to SSL, hostname and certificate validation. Let’s say your project uses this library just to call some URL (API) via HTTP (not HTTPS), then your project has no impact from the reported vulnerabilities of httpclient. So these issues become false positives in your case.
In such situation, you might need to get a vulnerability analysis report for 3rd party dependencies that clearly reflects the actual vulnerabilities and hides false positives. Then you can use the suppress option in Dependency Check.
When you get the Dependency Check report, next to each vulnerability in the report, there is a button named suppress. If you want to hide that vulnerability from the report, click on this button and it would popup a message that contains some XML content.
You can create an XML file with below content and put the XML content you got by clicking on the suppress button as child elements under <suppressions> tag.
<?xml version="1.0" encoding="UTF-8"?>
<suppressions xmlns="https://www.owasp.org/index.php/OWASP_Dependency_Check_Suppression">
<!-- add each vulnerability suppression here-->
</suppressions>
|
A sample is below.
<?xml version="1.0" encoding="UTF-8"?>
<suppressions xmlns="https://www.owasp.org/index.php/OWASP_Dependency_Check_Suppression"> <suppress> <notes><![CDATA[file name: commons-httpclient-3.1.jar]]></notes> <sha1>964cd74171f427720480efdec40a7c7f6e58426a</sha1> <cve>CVE-2015-5262</cve> </suppress> </suppressions> |
Then you can run the Dependency Check again with the --suppression parameter where you provide the file path to the XML file that contains the suppressions.
./dependency-check.sh --project "myproject" --scan /home/tharindu/dependencies/mydependencies --out /home/tharindu/dependencies/reports --suppression /home/tharindu/dependencies/suppress.xml
|
Then the report would show how many vulnerabilities are suppressed.
Also the report would contain a new section called Suppressed Vulnerabilities and you can make this section hidden or visible in the report.
In conclusion, before using an external library as a dependency for your project, it is important to know those are safe to use. You can simply use a tool like OWASP Dependency Check and do a vulnerability analysis for the 3rd party dependencies. You can follow this as a process in your organization to ensure that you do not use components with known vulnerabilities in your projects. This is one major software security risk listed under OWASP Top 10 [5] as well.
References
Tharindu Edirisinghe
Platform Security Team
WSO2
