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.
After years of discovery and research by the cybersecurity industry, we are at a stage now where companies have started looking for effective protection against this serious threat. Typically, 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).
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. It’s no wonder then that security teams looking for protection against Magecart place their eyes on CSP. 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. I’ll explain why, by exploring the different versions of CSP.
CSP version 1, introduced in 2010, essentially 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% CSPs based on whitelists (CSP v1) are bypassable. The existence of so many bypasses to CSP v1 eventually led to version 2 being introduced in 2016. This version allowed using nonces and hashes as a more secure way of authorizing scripts. Since 2018, there’s a draft of CSP v3, which introduced some additional flexibility to better support bigger web apps.
Despite these advancements, today 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.
One of the biggest shortcomings of CSP against web skimming is that it is limited in what it restricts and its lack of 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 to the third-parties you wish to use. But what if one is compromised with a web skimmer? Suddenly, 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, for example. And 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 though, 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 relaxing the policy, which worsens the lack of granularity problem.
All in all, it becomes clear that 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 of 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 native defenses, adding visibility, resilience and control. Now is the 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 on: InfoSecurity Magazine
