August 13, 2021

How Your Code Dependencies Expose You To Web Supply Chain Attacks

By Pedro Fortuna | 4 min read

jscrambler-blog-code-dependencies-web-supply-chain-attacks

As the demand for faster product development continues to grow, developers increasingly rely on code snippets from external sources, especially JavaScript libraries and frameworks. This results in an average web application with more than 1,000 modules, also known as code dependencies.

But what does the increased usage of third-party code mean in terms of security? In this blog post, we’ll walk you through the risks of code dependencies when it comes to web supply chain attacks. So let’s get started.

JavaScript, the #1 language of the web

In recent years, we have seen the technologies used for creating web products develop rapidly, and JavaScript became the predominant language of the Web. In fact, JavaScript is part of 97% of modern websites and every single Fortune 500 company is using it. They rely specifically on npm, a JavaScript package ecosystem built globally by millions of developers. But what was the main driver when it comes to JavaScript’s success?

The JavaScript open-source community really started to thrive after the Node.js environment was released back in 2009. This started the move of creating reusable code pieces, usually called modules or packages, that could be shared by different projects. With the development of this ecosystem, we have seen fully functional front-end frameworks and libraries like React and Angular appear. In turn, this has significantly increased the speed of development, not only for Web apps but also for mobile and desktop, with frameworks like React Native, Ionic, and NativeScript.

Naturally, in such a fast-paced industry, companies could not miss out on the opportunity to cut product development time by relying on peer-reviewed third-party modules. Not only that, but as the community-built modules became more specific and started satisfying more needs it became less and less needed to develop every piece of code in-house. As such, the use of third-party code became standard in the Web development scheme and now the average website has more than 1000 code dependencies.

How Your Code Dependencies Expose You To Web Supply Chain Attacks

Despite its benefits for product development, the use of third-party code represents some security concerns.

A 2019 study by researchers from the Technical University of Darmstadt found that each code dependency that companies use contains, on average, 80 dependencies of its own. While simply multiplying this figure by the 1,000 transient dependencies of the average web app is not accurate by itself (different packages often share the same dependencies), we can safely conclude that, just by getting to the second level of the web supply chain, we are already dealing with many thousands of code dependencies.

And when this same team of researchers further analyzed the actual maintainers of these packages, the overall finding was concerning: if 20 high-profile developer accounts are compromised by attackers, half of the entire ecosystem is breached. In other words, hundreds of thousands of private and public organizations worldwide would be attacked by a global web supply chain attack.

So, it’s clear that, by relying so heavily on third-party code, companies are left with zero control and visibility over the code they are using and its behaviors. This low visibility scenario is ideal for attackers to thrive, specifically through web supply chain attacks.

In a web supply chain attack, attackers target the supply chain of websites and all of their third and fourth parties. This approach allows for easier and more scalable attacks. For instance, if an attacker manages to modify a weaker third-party provider, they can basically inject arbitrary code into the website and do what they want.

The fact that there’s no privilege separation in JavaScript development makes it particularly dangerous to have arbitrary code running on your website. This means that all pieces of third-party code have the same privileges as code that is developed internally, and so they are free to do anything on your website. They can add additional code to the web page, hidden in plain sight, for example, to display a fake popup for phishing purposes or to redirect the user to websites containing malware. With that, attackers can then leak any data they collected and send it to a drop server under their control.

magecart

You can already imagine the consequences of allowing attackers easy access to the credentials or PII of your users. With strict regulations like GDPR and CCPA, this is a clear violation of users’ privacy rights. And when you add the fact that supply chain attacks often go unnoticed for weeks or even months, as we saw in the case of the Magecart web skimming group attack on British Airways in 2018, companies are left with devastating consequences.

Safely Integrating Third-Party Code

The bottom line is third-party code isn’t going anywhere as it is still one of the most valuable assets for competitive product development. But the key to mitigating the risks associated with externally sourced code is learning how to safely integrate it. This requires development teams and security teams to reduce code dependencies when possible and put in place webpage monitoring to gain visibility and control over the behavior of all code running at the client-side.

Gaining this level of visibility is essential for companies to regain control over their web supply chain. And to thoroughly achieve the desired level of security, they need to do it continuously at runtime.

To take the first step to achieve full website visibility and control, get started with Jscrambler’s free website inventory report and get valuable insights into what scripts are running on your website and what suspicious connections they are doing.

Author
Pedro FortunaCTO and Co-Founder of Jscrambler. Experienced in academia and as a security researcher, Pedro has co-authored several application security patents and is an active member of the AppSec community.
View All Posts

Subscribe to our weekly newsletter

Learn more about new security threats and technologies.

I agree to receive these emails and accept the Privacy Policy.