CSP & Magecart Web Skimmers: Facts and Fiction

What are the facts and the fiction behind Content Security Policy (CSP) and Magecart web skimmers?

With e-commerce displaying no signs of slowing down since the start of the COVID-19 pandemic, the Magecart cyber-criminal syndicate is thriving.

By evolving their web skimmers to become harder to detect and avoid, they have been successful in breaching several high-profile businesses.

Security Measures against Magecart web skimmers

After years of discovery and research by the cybersecurity industry, companies started looking for effective protection against this serious threat.

When security teams understand how web skimming attacks operate and how they take advantage of the huge security blindspot that is the client-side, they first turn to CSP (Content Security Policy).

Content Security Policy (CSP)

For a long time, CSP has been perceived as a Swiss army knife of sorts when it comes to client-side security. It originated from the need to mitigate cross-site scripting (XSS) attacks, which have plagued web apps for too long, putting on the spot the limitations of the Same-Origin Policy (SOP) and the web security model.

CSP mitigated some of SOP’s flaws, providing much-needed defense against script injection attacks.

In a nutshell, the most common form of CSP (v1) allows app owners to define which external resources can be loaded and which domains can be contacted.

In theory, CSP appears to prevent external malicious scripts such as web skimmers from loading on the website and from exfiltrating the data to a drop server. However, it fails to provide the required level of protection against web skimming.

CSP version 1

CSP version 1, introduced in 2010, uses a domain-based whitelisting approach. In 2016, a group of Google security researchers led by Lukas Weichselbaum and Michele Spagnuolo discovered that over 94% of CSPs based on whitelists (CSP v1) are bypassable.

CSP version 2

The existence of so many bypasses to CSP v1 led to version 2 being introduced in 2016. This version allowed using nonces and hashes as a more secure way of authorizing scripts.

CSP version 3

Since 2018, there's been a draft of CSP v3, which introduced some additional flexibility to better support bigger web apps.

Despite these advancements, we are seeing vendors push security products to fight Magecart that are actually using CSP v1 under the hood.

Hence the importance of understanding the underlying facts of CSP v1 and why it’s a bad idea to rely on solutions that are based on an approach with plenty of bypasses. Not only that, but there are still several other reasons why CSP v1 and even newer CSP versions fail to provide enough protection against web skimming.

CSP Shortcuts for Web Skimming Success

One of the biggest shortcomings of CSP against web skimming is that it is limited in what it restricts and lacks granularity.

CSP v1 only lets you completely allow or disallow a specific domain or script, regardless of the type of data that is being sent. And that’s what you do with the third-parties you wish to use. What if one third-party is compromised by a web skimmer?

They can do whatever they want inside the web app, scraping data and exfiltrating it through the whitelisted address or using one of the many known CSP v1 bypasses.

CSP only provides this type of control on the network dimension and can’t be used to restrict access to payment forms.

While the most recent versions of CSP are more secure than v1, there are a few known bypasses that work in all CSP versions.

Curiously, what typically is a turnoff for security teams is that CSP is substantially difficult to maintain. It requires a manual and time-consuming process of keeping track of all the resources and domains that the application legitimately uses.

CSP is also very prone to suddenly breaking the application when new scripts or domains are added, and the typical solution to this is to relax the policy, which worsens the lack of granularity problem.

Conclusion

The narrative of CSP’s big role in fighting web skimming attacks is mostly fiction.

If we go over the facts about how web skimming works, we can conclude that a suitable approach to mitigate these attacks must avoid the critical limitations of CSP.

First, it must go beyond the network dimension, providing control over every behavior that happens at the client-side: access to forms, to the DOM, to cookies and local storage, to web APIs, among others.

This breadth greatly increases the chances of detecting signs of malicious activity, namely web skimming attempts. It’s crucial that such an approach provides granular control over each of these dimensions, not following CSP’s all-or-nothing method.

Finally, it must result in detailed and actionable data; otherwise, it can result in severe alert fatigue.

We have been seeing the rise of new approaches that are based on sandboxing and complement browser security's native defenses, adding visibility, resilience, and control.

It is time for companies to vet all the solutions they have at their disposal, separating facts from fiction and doing all the necessary tests to ensure that they are ready to mitigate Magecart attacks.

Originally published in InfoSecurity Magazine