How secure are your web application’s open source dependencies?

A recent discovery of a hack suggested that at least 1,000 websites running on open-source eCommerce framework Magento were compromised with the help of a brute force attack. The attackers then used that to steal the credit card credentials and install cryptocurrency mining malware. This attack, riding piggyback on the open source software (OSS) ecosystem, raises some questions about any web app’s open source dependencies.

The importance of open source software security

A 2015 survey reports that 78% of businesses around the world run OSS, and 19% are using OSS indirectly. Only 3% of businesses remained untouched by OSS. Most of the web systems deployed rely heavily on open source components and are thus exposed to various vulnerabilities that afflict the web.

Gatekeepers can get complacent, so the onus falls to the end user to examine the code box, whether sealed or open, to ensure that their deployment is secure.

Web developers are sometimes guilty of heavily relying on OS libraries and dependencies for everything from authentication to UI. There are applications that are built entirely on top of open-source platforms like Magento, Drupal, Joomla, etc.

So, a minor vulnerability can result indeed bring havoc to the entire ecosystem that use the dependency. For instance, here’s a list of some of Angular’s node dependencies .

The list is actually much larger (the actual module count is 806). Most of the time it’s rare that we realize that we’re actually depending on so many modules when we’re writing a piece of code.

Securing your web application isn’t just about preventing future attacks, it’s about having a solid strategy to avert the situation when a vulnerability is disclosed.

While open source dependencies present a security threat, the very fact that it is open makes it more secure. It can be examined by anyone. With proper tools and standard operating procedures in place, the end user is empowered to inspect the open source dependencies and ensure security.

Let’s look at a few different ways to improve the web security of your open source software (OSS) library.

Use tools to check for security vulnerabilities in your dependency

Different tools — both free and commercial — have emerged over the years that help you manage open source vulnerabilities in dependencies (see this article by WhiteSource for more details).

You’re probably already aware of npm audit that comes packed with the latest version of npm.

Here’s an excerpt from the npm blog:

npm audit is a new command that performs a moment-in-time security review of your project’s dependency tree. Audit reports contain information about security vulnerabilities in your dependencies and can help you fix a vulnerability by providing simple-to-run npm commands and recommendations for further troubleshooting.

Together with the auditing capabilities, npm audit gives you alerts every time you install new modules or update existing modules for your project. It uses Node Security Platform that has relies on public vulnerability databases like NIST National Vulnerability Database (NVD) to report for vulnerabilities in dependencies.

Node’s not your primary environment? Fret not! There are other tools that you can use to reliably generate security reports for a library.

An open source command line tool from OWASP called Dependency Check can be used to monitor PHP, Java, .Net and Ruby code.

Alternatively, OSSIndex has several checking modules and sources vulnerability reports from a multitude of sources.

Apart from that, there are commercial organizations like SourceClear, Hakiri, and Snyk that facilitates free security analysis of code using a proprietary vulnerability database gleaned from several sources.

Strict security rules and security standards before using a dependency

Policies should be in place to make the development team accountable for any breach of security. While not always a popular policy, the truth is that both the developer and in-house personnel must certify the absence of security threats before a dependency is pulled into your project.

---

Over 200k developers use LogRocket to create better digital experiences

Learn more →

---

Enforcing a policy that require the developers to prove that the dependency doesn’t have any known vulnerabilities is what’s needed. The Open Web Application Security Project is a good place to keep updated about known vulnerabilities.

Here are a few questions that you should ask yourself before deciding to import a module into your project:

1. Is the open source component in active development state or obsolete?
2. Are there any significant issues in the issue tracker that haven’t been taken care of yet?
3. Is the component tested and ready for production?
4. Is there a popular alternative for the component?

Monitor your open source components constantly

As a developer, you should make an inventory of all the OSS dependencies and keep track of security updates.

It goes without saying that “a lot of eyeballs,” like Linus’ Linus’ law says, are inspecting, continuously discussing and updating OSS status. With so much free help, keeping track of things is a lot easier than it used to be. Remember, though, that it is not a one-time thing. You have to monitor open source dependencies constantly.

Apart from this, you also need a strategy to methodologically check whether any new vulnerabilities have propped up and then deploy a patch as quick as possible.

For instance, if the library is in active development, you can expect them to quickly release an update. If not, you should start an issue in their tracker or make a contribution by patching the vulnerability yourself and creating a pull request.

Test your components and dependencies

Rigorously test all your components and OSS dependencies for hackable code and probable intrusion points. Proper testing and code review might keep you away from trouble even if a vulnerability is found in one of the dependencies. A dependency that’s secure in one environment might be insecure in another environment.

If you write tests and conduct rigorous code reviews for your components and dependencies, you can hope that most if not all the loopholes are shut and that the application is safe for production. Also, do make sure that every input to the app is sanitized. Different code objects may need different sanitization of the same input.

Build in-house tools instead of unsupported (expired) libraries

Are you still using unsupported, expired OSS libraries? That’s probably not a great idea. Consider building your own code object and map the maintenance path for that build.

It’s very common in the open source world for the library developer to abandon the project and the dependency ends up without any active developer. If it’s a dependency that can have security implications for your application, you should consider moving to a similar component that’s actively developed or take up the responsibility of forking it and developing on top of it.

This way, you can repurpose the obsolete code and then give it back to the OSS community. This will also you earn you a little respect as a developer (and possibly, a human) and offer more opportunities in the long run.

200s only Monitor failed and slow network requests in production

Deploying a Node-based web app or website is the easy part. Making sure your Node instance continues to serve resources to your app is where things get tougher. If you’re interested in ensuring requests to the backend or third-party services are successful, try LogRocket.

LogRocket is like a DVR for web and mobile apps, recording literally everything that happens while a user interacts with your app. Instead of guessing why problems happen, you can aggregate and report on problematic network requests to quickly understand the root cause.

LogRocket instruments your app to record baseline performance timings such as page load time, time to first byte, slow network requests, and also logs Redux, NgRx, and Vuex actions/state. Start monitoring for free.