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 , 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. Cross-site Scripting 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 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. SQL injection 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 , this can be done relatively easily. Ruby on Rails 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 . 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. Formik Another protection for this is data validations. We can install packages such as for us to custom-filter user inputs on the client-side for malicious data inputs not to reach the server. validator 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 tests will dig deep into the codebase as well as the third-party libraries we use and identify any vulnerable lines of code. automated testing tools This means, therefore, that to fully be covered, we must ensure we must include security testing and maybe into our workflow. SecOps Conclusion While it is impossible to be fully updated with every possible security vulnerability, there are services that can make our lives much easier. 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 well with the different tools you are already using. Whitesource’s Vulnerability Database integrates
