Why Script Vetting Isn't Enough to Prevent Client-Side Attacks

Prevent client-side attacks and avoid customer data leakages, compliance nightmares, or revenue losses. How can companies implement stricter third-party control? What does this rigorous control mean?

Considering the context of web supply chain attacks, for instance, is Scrip vetting the best answer?

In the wake of recent supply chain attacks, such as the one from SolarWinds or even the one that led to the Celsius Networks phishing attack, there is an urgent need for stricter third-party control.

Find out if script vetting is enough to prevent client-side attacks.

What is Third-party Script Vetting?

To grasp the concept of third-party vetting, we must look at the average website.

With the growing demand for faster product development, developers rely on externally sourced code, especially JavaScript frameworks and libraries.

This results in the average web app having more than 1000 modules, also known as code dependencies. Because each one of the modules can also have dependencies, each application ends up with thousands of pieces of third-party code.

Then there are the additional scripts that websites use at runtime. Almost every website today uses externally sourced services like chatbots, analytics, or ads.

With such heavy usage of third parties, the attack surface increases, specifically supply chain attacks. Because these attacks rely on the lack of visibility companies have over their code dependencies in the supply chain, they can often go unnoticed for weeks.

We have seen this happen in the case of the Magecart web skimming group attack on British Airways in 2018, which went unnoticed for over two months.

The concept behind third-party script vetting is that companies vet each third-party script and the company that provides it to guarantee they are legitimate and secure. Vetted scripts are allowed, and those that fail the vetting process are abandoned (at least while they remain insecure).

The process of vetting the script provider is typically done by looking for certifications (ISO or SOC) that attest to the company’s commitment to security. On the other hand, script vetting involves scanning the code for any vulnerabilities or security weaknesses that could make it easier for attackers to compromise the script.

This may seem like a definitive answer to the problem.

However, while this method of third-party vetting helps companies address web supply chain attacks, it must be coupled with additional security measures.

Why is Script Vetting Not Enough to Prevent Web Supply Chain Attacks?

If we were to closely observe the pieces of any given website over a few days, we would witness hundreds of code dependencies constantly changing. Each of these frameworks and libraries receives updates, as do their respective third parties.

When we contrast this dynamic scenario with the concept of script vetting, we can see why script vetting alone is not enough to guarantee the security of third-party scripts.

Script Vetting problems

The biggest problem with script vetting is that it provides a picture of a moment at a particular time. That said, a script successfully vetted and deemed secure today can become a security liability.

If we were to trust vetting alone, we would trust this script without reservations, disregarding its behavior on our website.

The perfect example to illustrate this is the Copay incident. An attacker took over a legitimate script, updating it with malicious code. Thus, it made its way into production releases of a crypto wallet and stole some of its users’ crypto.

Another issue is that the average website contains 35 different third-party components. Seeing how the web supply chain is as secure as its weakest link, a robust vetting strategy would entail going through every single one of these scripts, which is a complex task.

The script vetting process is not without flaws. While scanning for vulnerabilities is a good security practice, it does not analyze every line of code for potentially malicious behaviors. A script with no known vulnerabilities can still be dangerous if it tries to access sensitive user data.

Gaining Full Visibility and Control

Script vetting is not the definitive answer to web supply chain security. So, what is the answer?

The short answer is security in depth.

Script vetting doesn’t address how a legitimate script can suddenly change its behavior. The next step for an in-depth approach is real-time visibility of how each one behaves on the website.

This visibility allows companies to detect suspicious behaviors, such as a known script suddenly starting to tamper with a payment form (Magecart attack) or attempting to send data out to an unknown domain (data leakage).

Magecart web skimming attacks remain active for 22 days on average before being detected. Therefore, this real-time visibility can improve incident response and contain data leaks.

Security-in-depth Approach

Visibility is only half of the response needed for a security-in-depth approach.

The other half comes from having complete control over the behavior of each script.

Effective control means being able to restrict specific allowed or disallowed behaviors in real-time so that any attempt at malicious activity is blocked, thwarting the attack.

To achieve this level of control, companies must look for solutions to establish flexible rules that block all malicious activity on the client side. Plus, these solutions must not compromise the regular functionality of each script.

There is still a long way to go before companies can fully control their web supply chain.

The first step might be to request a Free Website Inventory Report. This allows you to gain visibility into the scripts and their behaviors running on your website.