What’s fact and fiction about 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 be harder to detect and block, they have successfully breached several high-profile businesses.
Security Measures against Magecart web skimmers
After years of discovery and research by the cybersecurity industry, companies began seeking effective protection against this serious threat.
When security teams understand how web skimming attacks operate and how they exploit the huge security blind spot that is the client side, they often turn to CSP (Content Security Policy).
Content Security Policy (CSP)
For a long time, CSP has been seen as a Swiss army knife for client-side security. It originated from the need to mitigate cross-site scripting (XSS) attacks, which have plagued web apps for too long and exposed 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 exfiltrating 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 many bypasses in CSP v1 led to the introduction of version 2 in 2016. This version allowed using nonces and hashes as a more secure way of authorizing scripts.
CSP version 3
Since 2018, a draft of CSP v3 has introduced additional flexibility to better support larger web apps.
Despite these advancements, we are seeing vendors push security products to fight Magecart that still use 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. Beyond that, several other reasons explain why CSP v1, and even newer CSP versions, fail to provide enough protection against web skimming.
CSP Shortcuts for Web Skimming Success
One of CSP’s biggest shortcomings against web skimming is that it is limited in what it can restrict and lacks granularity.
CSP v1 only lets you allow or disallow a specific domain or script entirely, regardless of the type of data being sent. And that’s what you do with the third parties you wish to use. What if a web skimmer compromises one third party?
They can do whatever they want inside the web app, scrape data, and exfiltrate it through the whitelisted address or use 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 turns off security teams is that CSP is substantially difficult to maintain. It requires a manual, time-consuming process of tracking all the resources and domains the application legitimately uses.
CSP is also prone to suddenly breaking the application when new scripts or domains are added, and the typical solution 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 review how web skimming works, we can conclude that an effective approach to mitigate these attacks must avoid CSP’s critical limitations.
First, it must go beyond the network dimension and control every client-side behavior: access to forms, the DOM, cookies and local storage, web APIs, and more.
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 dimension, rather than following CSP’s all-or-nothing approach.
Finally, it must produce detailed, actionable data; otherwise, it can lead to severe alert fatigue.
We’ve seen a rise in new approaches based on sandboxing that complement browser security’s native defenses, adding visibility, resilience, and control.
It is time for companies to vet the solutions at their disposal, separate fact from fiction, and run the necessary tests to ensure they are ready to mitigate Magecart attacks.
Originally published in InfoSecurity Magazine
