Card Skimming Code on a Checkout Page

A few lines of code at the checkout

For several years, and widely since last year, criminal groups have been adding small scripts to the checkout pages of online stores.

The script watches the card fields. As a customer types the number, expiry date and security code, it copies them and sends them to a server the criminals control.

Researchers often group these attacks under one name, Magecart, after the store software the early ones targeted. Some very large companies have been hit, and so have a great many small stores that never made the news.

Small stores are attractive because they are rarely watched.

Why nobody notices

Nothing breaks. The customer completes the purchase, the payment is approved, the order arrives and the goods are shipped.

The copy of the card leaves at the same moment, by a route the customer never sees, often to an address made to look like an analytics or content delivery service.

Weeks later, fraud appears on cards whose only common factor is that they were used at the same store. That is usually how the store finds out: from its payment processor, not from its own website.

How the code gets in

• Outdated store software with a known, published weakness.
• An extension or plugin nobody has updated, or that its developer abandoned.
• A stolen administrator password, often reused from another site.
• A third-party script changed at its source, such as a chat or review widget.
• A theme or add-on downloaded from somewhere other than its maker.

The fourth is the one a store cannot fix by keeping its own house in order. A script loaded from another company's server runs whatever that server sends, including anything an attacker has added there.

The scripts already on the checkout

Look at what a typical small store's checkout loads, and the list is longer than anyone intended.

Analytics, a tag manager, an advertising pixel or two, a chat widget, a reviews badge, a heat-mapping tool someone trialled last year, and the theme's own collection of scripts.

Each can read the page, including what a customer types into it, and each is a door somebody else holds the key to.

The payment step needs almost none of them, and removing the rest is the quickest reduction in exposure a store can make.

Taking card entry off your page

The strongest protection is for the card number never to be typed into your page at all.

A hosted payment page does that: at the payment step the customer moves to a page served by the payment processor, pays there, and returns to your store.

Embedded payment fields come close. The card boxes sit inside your page but are served from the processor's own address, and the browser stops your page's scripts from reading them.

Neither is perfect, since altered code could swap in a fake form, but both put the card number out of easy reach.

The card industry's security rules also ask far less of a store whose pages never handle card data.

A worked example

A small online store selling loose-leaf tea and teaware ran an older version of its store software with about a dozen extensions, one of them last updated in 2016.

In the spring its payment processor called: a cluster of fraudulent charges had been traced to cards whose common point of purchase was the store.

A developer found four lines of scrambled code added to a legitimate script file that loaded on every page. It sent whatever was typed into the checkout fields to an address one letter away from a well-known analytics domain.

The code had come in through the old extension, and had been there for about seven weeks.

The store removed the code and the extension, updated everything else, reset every administrator password and added two-step login.

Card entry moved to the processor's embedded fields, the checkout lost all but two of its scripts, and file change alerts were switched on.

The incident was written up in the store's breach log, and the owner took advice on telling customers.

Watching for changes

Skimming code has to change something: a file on the server, a setting in the store's database, or a script the checkout loads. That makes change itself the thing to watch.

File change monitoring compares the store's files against a known good copy and sends an alert when anything differs. Many security plugins and hosts offer it; an alert outside a planned update deserves a look that day.

Keep a short written list of every script the checkout loads and why. Anything on the page and not on the list is a question, wherever it came from.

A Content Security Policy goes further: a header telling browsers which addresses the page may load scripts from and send data to, so code reporting to an unknown server is blocked.

When it happens anyway

Contain it first. Take the checkout offline, or switch to the processor's hosted page, while the code is found and removed, then tell your payment processor and follow their instructions.

Card details are personal information. Where federal privacy law applies, as it usually does for a store selling across provincial borders, the breach has to be recorded.

If it poses a real risk of significant harm, the Privacy Commissioner and the affected customers must be told as well. Card theft sits close to what that rule has in mind, so take advice early.

The counter-case

A store that already sends customers to the processor's own page to pay has much less exposure. Its remaining risk is mostly a tampered link or a fake form, which file monitoring helps catch.

A store on a platform that runs the checkout itself has handed most of the software side over. Whatever it adds to its own pages is still its responsibility.

And a store taking a handful of orders a month may not need every layer of monitoring, provided card entry is off its pages.

For everyone else: keep the software current, keep the checkout bare, keep card entry off your pages, and watch for change.

This month

1. Update the store software and every extension.
2. Remove extensions nobody maintains any more.
3. List every script the checkout loads.
4. Strip the checkout to what payment needs.
5. Move card entry to the processor's hosted page or fields.
6. Turn on alerts for changed files.
7. Add two-step login for every administrator.

Step five is the one that changes the odds most. Code on your page can only copy what is typed into your page, and once the card number is typed somewhere else, most skimming code has nothing to read.

Keeping the checkout itself short and simple is covered in a checkout that requires an account.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.