The rapid advancement of technology and digital acceleration we are currently witnessing has played a very important role across all industry sectors. This is especially relevant when we are talking about the development of software products, namely web applications. Here, the usage of third-party code has become the norm, contributing to an overall acceleration of the development lifecycle. However, what are the impacts of this third-party code on application security?

In this post, we will explore the current state of web application development, the associated security risks, and most importantly how to vet and manage third-party scripts in web apps.

The current state of the web app development

The current demanding and extremely dynamic market puts added pressure on development teams to deliver products faster. In order to keep up with this pace, teams often have to shorten the development lifecycle of web apps, which ends up raising concerns in the topic of application security.

To understand the core of the security concerns, we first need to understand that to fasten the development lifecycle, teams rely on various third-party scripts, frameworks, and libraries. In fact, 70% of the code in the average web app is being sourced from third parties. And with 35 third-party components and 31 fourth-party components on average, it’s no wonder that the typical web application contains a huge mashup of client-side code (as illustrated below). But why does this result in a larger attack surface?

When development teams use externally-sourced pieces of code, they are inherently trusting this third-party code along with any fourth-party code that it uses, and so on. The result is that companies end up having a long chain of code dependencies without really having good visibility over what they are effectively running and what each piece of code is actually doing.

The risks of the lack of visibility over third-party code

The main problem of lacking visibility and control of third-party code is that third-party scripts have the same privileges as all the code that is developed internally. This means that, for instance, a third-party chat plugin can suddenly start interfering with a payment form (which is precisely what happened in the Ticketmaster/Inbenta Magecart attack of 2018).

Because the typical modern web app today has a lot of sensitive data continuously passing through the client-side (whether it is pulled from the database and shown to the user, or whether the user types it into a form), all that sensitive data is at risk of being leaked by a rogue third-party script.

When an attacker manages to breach the provider of a third-party script, companies that are using that script have no visibility that the attack is even happening. Web application firewalls and other network defenses consistently fail to detect the attack because it originates from a source that’s trusted by default (a legitimate third party).

Because of this, attackers have a larger window to exfiltrate any data collected and send it to a drop server under their control. In the case of Magecart web skimming attacks, for instance, research has shown that they have risen by 20% during the pandemic and remain active for 22 days on average before being detected and removed.

Consequences of a third-party script-based attack

With the development of strict regulations like GDPR and CCPA, the leakage of sensitive user data into the hands of attackers is a clear violation of users’ privacy rights. More specifically, when it comes to payment data, this can also mean a breach of compliance with PCI DSS.

Breaching compliance with any of these regulations results in very high financial costs due to the payment of hefty fines. Magecart attacks are some of the most well-known third-party-based attacks, since they have resulted in some of the highest fines seen in the scope of compliance with security and privacy regulations.

Apart from the direct breach of compliance, it is also important to beware of the damage to the company’s reputation, which can result in various business losses and leave a permanent dent in its relationship with customers.

Vetting and managing the behavior of third-party scripts

The first step needed to address the problem of script-based attacks is to gain visibility of which third-party scripts are actually running on the website and what types of actions they are performing (i.e. their behavior).

We are currently providing a free website inventory report which provides a snapshot of these scripts and their behavior broken down into actionable insights.

The report starts by detailing the number of domains that are receiving data from the website and how many of these are third party.

It also analyzes the assets that are loaded on the website, including the number of assets coming from third parties and how many different domains are loading these assets.

Another key detail is the number of poisoning events detected on forms and on network events, as these may indicate that third-party scripts are collecting data from forms or intercepting network data (data leakage).

The report also presents high-level tables displaying critical client-side security threats, such as the one below.

Finally, it includes several other tables and graphs with detailed information on specific detections such as code/native API poisoning, source domains, destination domains, resources/scripts, breakdown of scripts into first- and third-party, and a digested overview of the critical issues.

All this information allows easily vetting the behavior of third-party scripts and taking an important step towards reducing the website’s attack surface.

Request your own free website inventory report today!