paint-brush
Top Open Source Vulnerabilities to Watch Outby@ryvee
373 reads
373 reads

Top Open Source Vulnerabilities to Watch Out

by Ry VeeJanuary 4th, 2021
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Top Open Source Vulnerabilities to Watch Out for coming into 2021. Database is a good example as it constantly updates its library with new and old vulnerabilities. Vulnerability is related to SQL injection, but it’s always important to be aware that it exists. Using open-source libraries that have vulnerable dependencies might be. 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. Automated tests will dig deep into the codebase as well as the third-party libraries we use and maybe even more.

Company Mentioned

Mention Thumbnail
featured image - Top Open Source Vulnerabilities to Watch Out
Ry Vee HackerNoon profile picture

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.