Magecart attacks have taken up a considerable portion of the news cycle over the past year where card data has been harvested from notable enterprises like British Airways, Newegg and Ticketmaster. While the mainstream news has moved on and become silent due to current targets not being quite as significant as BA, the attackers are still operating. In this blog post, we want to talk about a couple of mechanisms you should be using to reduce your attack surface and keep your customers safe
A little background is always good: the Magecart attackers rely on compromising eCommerce platforms like Magento (the origin of their name) usually using object injection attacks against eCommerce extensions (see https://gwillem.gitlab.io/2018/10/23/magecart-extension-0days/), and either directly compromising eCommerce sites, or compromising third party script providers (think analytics scripts, ads, or widgets). There isn’t really one cohesive gang that could be considered to be the definitive Magecart gang. Like most successful hacks, the techniques tend to get adopted by copycats and splinter groups, creating a miniature ecosystem that has dozens of flavours of the same basic concept.
This means that techniques historically considered to be good defence, like blacklisting attacks with web application firewalls, will not necessarily be entirely effective against this style of attack, given the attackers also make use of persistence mechanisms to re-infect applications after the first compromise.
So, what can you do? The first thing is reduce your attack surface if you can. Take a list of any extensions you’re using with your ecommerce site, and consider whether they’re absolutely necessary. Consider reaching out to the developers and ask if they’ve had their code audited by a third party before. You can even request to see a Penetration Test report. You should also think about doing the same to your third party javascript.
There are some important features you can add to your code to protect you from malicious alterations to scripts – the one we’ll discuss in this blog is called Subresource Integrity. This is a feature introduced by the W3C in 2016 which allows browsers to verify that any scripts being loaded by a site are the correct scripts. If you’re familiar with the idea of using hashing algorithms to verify the integrity of files you download, it’s the same mechanism. If you’re not familiar, the simple version is you run a one-way, irreversible algorithm on a file that gives you a string of characters unique to that exact file. Subresource Integrity allows you to embed that string of characters within your application, associated with a third party script. So, your html would look something like this:
<script src=”https://ads.thirdparty.com/analytics.js” integrity=”sha384-randomstringofcharactersgoeshere”></script>
You can generate these SHA384 hashes with the following command on Linux:
openssl dgst -sha384 -binary FILE | base64.
Once you’ve got a set of scripts you can verify as clean, using Subresource Integrity as part of your application means that only those trusted, clean scripts will be run in users’ browsers. There are some downsides – if your third party regularly changes or updates their scripts, it may be costly to use Subresource Integrity as you’ll have to keep updating your hashes. The benefits for your users, and the protection this offers against Magecart-like supply chain attacks is something worth considering.
Digital Interruption also offers virtual CISO and DPO services, so if all this seems too much, reach out to us and we can give you assurance and peace of mind against these kinds of attacks.