Skip to main content

Common misconceptions about the rise of Magecart attacks

security
(Image credit: Shutterstock / Askobol)

How time flies. Just this week I realised that the British Airways breach (probably the de-facto poster child of Magecart attacks), celebrated its 2 year anniversary. But even before the BA breach, I had been investigating the advanced tactics that cyber criminal groups use to infiltrate the client-side of websites.

Web skimming is a prime example of a highly effective attack. It’s no wonder then that so many different groups follow the Magecart modus operandi. Since the BA breach, I’ve analysed over 65 high-profile web skimming attacks that affected thousands of different companies. Worryingly, Magecart shows no signs of slowing down.

But today, fortunately, we know a lot more about web skimming attacks than we did in 2018. So, in order to prepare businesses to be able to properly handle this threat, I thought I’d present 5 of the biggest misconceptions surrounding Magecart attacks.

About the author

Pedro Fortuna is CTO at Jscrambler

Magecart only attacks Magento-based websites

At first glance, many make the connection between Magecart and Magento - the Content Management System widely used in E-Commerce shops. Indeed, the Magecart name was probably first coined because the cybercriminal syndicate initially focused on Magento-based stores. These were typically very poorly configured security-wise, with default passwords galore and a lack of software updates. Those days are far behind us. Today, industry associates Magecart with any web skimming attacks that originate on any website and from any third-party. As long as the attacker manages to inject the web skimmer into the website, it’s good to go. And a new Magecart attack is born.

Magecart only attacks big websites

At the risk of repeating myself, Magecart attacks can target any website. Most of us have heard of the high-profile breaches on well-known names such as Macy’s and Warner Music Group. However, most Magecart groups aren’t launching highly targeted attacks on specific companies. And even those who are may end up infecting hundreds of websites in a single attack, as they mostly go after the dependencies and third-party code that is used by large, medium and small companies. When Magecart casts its net over the web supply chain, it’s typically aiming for both big and small fish alike.

Your website is not at risk if you develop and maintain it internally

There’s often the argument of “we develop everything in-house”, which leads to the idea that your team controls every single aspect of your website. However, today’s typical web application contains a huge mashup of client-side code. According to recent stats, two-thirds of the scripts used on the average website come from third-parties. Plus, the development of these platforms typically integrates frameworks and libraries that contain dozens of pieces of third-party code of their own, creating a long chain of code dependencies. And each instance of third-party code presents attackers with another possible way in. And even in those rarer cases where the company is self-hosting everything and has minimal reliance on third-party code, it’s still at risk. There have been multiple instances of first-party Magecart attacks, and those too remained undetected for weeks.

Magecart attacks can be mitigated with a Web Application Firewall

This is another misconception. Web Application Firewalls (WAFs) are widely used to monitor and protect the network, blocking unknown or untrusted connections. However, much like server-side defenses, a WAF doesn’t detect whatever is happening on the client-side. And since Magecart attacks originate from a source that is trusted by default - a legitimate third-party supplier or a piece of first-party code - the malicious web skimming code easily bypasses WAFs.

CSP and SRI are the way to go if you want to prevent Magecart attacks

I saved this one for last because it’s certainly the one I hear most often. Content Security Policy (CSP) and Subresource Integrity (SRI) are two techniques that are commonly employed to minimise exposure to data exfiltration and third-party attacks. However, we now know that these approaches aren’t the right answer to fight off Magecart. While CSP does limit the external sources to which a website can connect, it can be bypassed, allowing attackers to exfiltrate credit card details anyhow. SRI adopts different tactics - it enables the website to block external scripts when their file integrity changes. In this way, the script would be blocked after the skimmer was injected. However, the big downside to SRI is that it’s very challenging to get right and ends up being a very high-maintenance solution that companies tend to avoid.

I’d like to be able to say that these are the only misconceptions on the topic of Magecart - sadly, there are still many more. On the flip side, industry has learned a great deal about these attacks in the past few years and we know that one of the most effective Magecart mitigation strategies is detecting and blocking malicious client-side behaviors in real-time. As more and more companies understand the need for this new layer of client-side security, I’m confident that Magecart’s days are numbered.