Counter Magecart


A lot of my decision making methodology I can probably attribute to playing Magic: the Gathering through my teens. Each day, we all encounter situations that are no different than the card game. Should you put it all out on the table stretching for victory or perhaps take the cautious path that where a little extra patience can make all the difference. These are all lessons learned that I hold with me still today when I encounter multiple paths to come to a decision.

My first competitive Magic experiences came during the era when "Control" decks reigned supreme. Counterspell (art pictured above) took anything the opponent played and denied it. Let me tell you, there is nothing more humbling and frustrating to have each single card that you play countered over the course of a long drawn out game.

I believe a bit of that control bleeds over to the infosec defender's mentality. Blue team should have enough resources at their disposal to deny what their opponents attempt to do. Like the "Control" decks, they didn't win 100% of the time, but they definitely fought on their own terms until the very end.

Magecart, today, is functioning in the absence of "Control" decks. This is evident because for every attempt to stop it from happening, nothing is countering it. Some of the most popular tools, Content Security Policy and Subresource Integrity, are spectacularly poor in stopping the attacks. Let me tell you why:

  • Content Security Policy (CSP): In order to be effective using CSP, application developers must not only know what domains their application reaches out to, but also must know what their third party scripts are doing in order to whitelist all functionality. This process must also be built into the development pipeline in order to preserve functionality for the application and is always at risk of being changed to allow communication to all domains for "testing" purposes. Now, I will give some credit, the rulers of the internet did propose specifications into HTTP in order to report on CSP failures ( Unfortunately, it is unsupported by most browsers currently and requires additional development time and administration to be effective... yuck!

  • Subresource Integrity (SRI): SRI allows application developers to hash the contents of the third party Javascript they want to load and direct it to only function if the hash matches when the Javascript is loaded by the client. Sounds great, but your application stops functioning when your third party makes changes and doesn't alert you to them. Your third parties alert you to their changes eventually, though, right? Didn't think so.

Magus Plaustrum (MP) is going to take this lack of control and finally counter Magecart. By utilizing it's Content Delivery Network with logic, it will always serve your client the Javascript you are expecting to send and will also alert you to when your Javascript changes. MP will alert you and can automatically upgrade your versioning or it can block all access until a root cause can be found. The best part? MP only absolutely needs to be implemented on scripts located on pages with sensitive information like credit card details... dramatically lowing your costs. MP is much easier to implement than CSP and turns SRI into a 'triple check' that ensures everything is going to plan. All of this results in saving your administrators or developers hundreds of grueling hours of work.

We all need to make an immediate shift in our strategy and finally take control back!

John Tuckner

Read more posts by this author.