Using Components With Known Vulnerabilities

Introduction

Most developers are excited about achieving the user's requirements and never bother to check which components they are using to achieve their goals. Web applications these days require a lot of functionality to keep up with ever-growing technological trends and this demands developers at every point and time to include one or more third-party libraries in their applications. Doing so is not a problem but it only becomes one when they find out that their application has been attacked via that library's behavior or associated dependency. Using components with known vulnerabilities exposes the organization to attacks such as Cross-Site Scripting, Injection, or any other vulnerability listed on the OSWAP top Ten 2017 depending on the component that has been exploited. In this article, we are going to learn about using components with known vulnerabilities.

Components with known vulnerabilities

In application development, it is common practice that as the project becomes more complex, you require using one or more libraries that enable you to meet your requirements. At the end of the day, their application is a collection of web services, Web APIs, libraries, open-source, and legacy code. Developers end up using third-party or some of the frameworks libraries without doing much research on the library’s capabilities and weaknesses. Thanks to the Common Vulnerabilities and Exposures’ (CVE) database developers may easily find out some of the most common threats and vulnerabilities and how they may be exploited.

Web applications and Web APIs are vulnerable if developers are not aware of the vulnerabilities which the components they are using have. A developer may use secure coding practices but use an insecure library without checking its associated vulnerabilities thereby exposing the application to severe attacks depending on the level at which the library exists.

Attackers normally do not exploit vulnerabilities using custom methods or techniques. Rather just like developers, attackers also follow the vulnerability updates as they are announced and take time to scrutinize their targeted applications for these common vulnerabilities and if they discover any penetration points they exploit these vulnerabilities to attack their targets.

Normally when official libraries are created it is common practice to check for vulnerabilities and if any are found over time the developers may include a patch in the next version or update of the library or framework. It is therefore very important that developers also check the version of the library they include in their project and also follow its update sequence such that they do not leave their applications exposed to danger once the components are out-dated.

Mitigation or Prevention of using components with known vulnerabilities

Organizations need to understand the libraries which they are using and their update timelines. Organizations need to keep track of the libraries used by their applications on the client and server-side.
Remove all the dependencies which the application is not using including unnecessary features, unused references, etc. This will minimize your application's risk and help with easy monitoring of your libraries and application behavior.
Use tools such as Dependency-Check to monitor which dependencies your application is using. Dependency-Check also helps with providing the libraries' associated vulnerabilities.
Keep all patches up to date and monitor their behavior and weaknesses through participation in user forums or subscribing to the email newsletter of the framework's developers. This may keep you up to date with the weaknesses or changes applied which may help improve your application safety and performance.
Organizations along with developers need to come up with firm policies on third-party and open source components. They need to cross-check and run necessary sanitizations and checks on all third-party and open source components which they intend to use before deploying their applications.

Conclusion

The inclusion of third party libraries or framework libraries is a normal practice in development but needs to be done with prior knowledge of the possible dangers this could cause to your application and the organization.