Top Open Source Vulnerabilities to Watch Out

Open Source packages are a mainstay for most software engineering projects. We are so accustomed as developers to run our `npm install` (for Node developers) or add gems to our Rails projects. While we may be taking them for granted, we might be opening up our codebase, and hence, our users to security risks.

Our duty as responsible engineers is to be vigilant of new potential threats and vulnerabilities, especially in mostly used open-source libraries.

In light of the new year (and finally leaving 2020 behind), here are some top vulnerabilities from last year to look out for coming into 2021. While the list probably doesn’t show us any new ones, it’s still imperative to be very familiar with them. Hackers, while wily and innovative themselves, will always go back and try new ways of exploiting these common vulnerabilities.

Cross-Site Scripting

Cross-site Scripting, or XSS as it’s commonly called, is a way for malicious code to go around the Same Origin Policy (SOP) followed by most websites and web applications.

SOP ensures that a web application cannot access or manipulate data or content from another origin website or web app. This means that a user who is logged on to his bank’s app can be sure that another website opened in the same browser cannot access data from the bank app.

XSS attackers will exploit a web application that produces dynamic HTML content. This is possible because any user input to any dynamically generated HTML form doesn’t get sanitized. Malicious JavaScript code can be entered as user input, and the web applications’ SOP will not be able to get in the way. An example of what such malicious code can do is hijack the session cookies in the user’s browser and capture login information.

One way to fix this is to use packages that can sanitize inputs to dynamically generated HTML code. One such solution is DomPurify.

SQL Injection

SQL injection still is going to be a common vulnerability in the next coming years. While the intensity of SQL injection attacks has mellowed, it’s always important to be aware that it exists.

In this vulnerability, an attacker will try to gain access to the database that an application connects to by “injecting” a SQL statement as user input in a form.

This usually happens when the application in question does not sanitize the inputs it allows from users.

Hackers use SQL injection to retrieve sensitive data or manipulate the database to steal, change, or destroy information.

One way to prevent this is to ensure that your application is to ensure HTTP queries are sanitized or parameterized. In frameworks such as Ruby on Rails, this can be done relatively easily.

Exposing Sensitive Information and Data

This particular vulnerability is related to SQL injection. Still, it’s good to put it on its own as it is a probably tactic that attackers can employ - create packages that inherently allow SQL injection attacks.

There are many open-source libraries that aid in data input tasks, such as Formik. These libraries take in information from the user. Therefore, it’s imperative that for us to protect our users’ data, we make sure that we carefully select which package we install into our project.

Another protection for this is data validations. We can install packages such as validator for us to custom-filter user inputs on the client-side for malicious data inputs not to reach the server.

Using Open Source Libraries That Have Vulnerable Dependencies

Libraries themselves use other open-source libraries. While the libraries that we use aren’t in themselves vulnerable, their dependencies might be. Now having some criteria for selecting a package to use (such as choosing only packages with a minimum number of downloads) helps. But being sure that such packages we install are free from vulnerable dependencies is a more challenging thing to do. 

This is where we need to incorporate some automated testing tools. Automated tests will dig deep into the codebase as well as the third-party libraries we use and identify any vulnerable lines of code.

This means, therefore, that to fully be covered, we must ensure we must include security testing and maybe SecOps into our workflow.

Conclusion

While it is impossible to be fully updated with every possible security vulnerability, there are services that can make our lives much easier. Whitesource’s Vulnerability Database is a good example as it constantly updates its library with new and old vulnerabilities. It has by far the largest collection. What I love about it is that it not only shows every relevant information about each vulnerability but also the fixes available. This makes it very convenient to work with (you can install Whitesource easily to your project). It integrates well with the different tools you are already using.