In January 2022, the Segway web store suffered a web supply chain attack - also often referred to as a Magecart attack. In these types of attacks, malicious JavaScript code is added that loads from the client-side, known as third-party scripts.
Many common tools are third-party scripts. Things like analytics, captchas and more. But this avenue can also be used for malicious reasons, as was the case here.
In this attack on Segway, their store is set up on Magento. The attackers targeted vulnerabilities in the CMS itself or one of the plugins installed on the Segway site. After breaching that, they added the JavaScript which appeared to display as the site’s copyright, but was actually used to load an external favicon.
Inside that favicon file, a malicious domain ‘booctstrap[.]com’ was placed. As can be seen from this image from Malwarebytes who broke the news on this attack:
That domain loaded the malicious third-party JavaScript code which aimed at capturing people’s credit card details.
As seen most recently in the Polyfill attack of 2024.
The way not to secure against this
Threat feeds are still the most relied upon solution to solve this issue, but we’d argue that it’s not the preferred way. Fundamentally, they don’t know what they don’t know. Attackers register a new domain, and without having to rewrite any code, the attack is back up again. For days, or sometimes weeks, until it’s spotted again and the thread feeds update their registries.
c/side was designed to stop these web supply chain attacks before they happen.
By putting these third-party scripts in a proxy and analyzing the full code payload before it loads, we spot malicious code like this example. We block it, stopping it from affecting the user, and alert the website owner of the potential attack.
Additionally, we save the code of the scripts in order for the website owner to see it after the event and solve the underlying problem.
Too little attention is given to these client-side attacks. If other security measures fail, like it did in the Segway case, this attack could still have been spotted. By monitoring exactly what happens in the browser of the user, data exfiltration should have been seen and prevented.
Regulation
As seen in this case, e-commerce is often a target. And regulation is catching up, with PCI DSS 4.0 where monitoring of third-party scripts on payment pages is now required (by March 2025). While we applaud this, we urge you to do this on all pages across your entire website. Back in April 2024, we explained in length why not doing so still puts your site at significant risk.
Next to other issues explained in that post, bad actors could exploit compromised scripts on your site to hijack user sessions, impersonate users, and perform unauthorized actions. Potentially bypassing two-factor authentication and still bypassing your payment portal protection that way.
You can use c/side to monitor scripts on all pages and be compliant for that part of PCI DSS 4.0. And, you can protect your site against these types of attacks with c/side.