The Analytics Script Nobody Added: Unmasking a Card Skimmer
The challenge
Fernhill's checkout runs a card-stealing script. Decode the web address it hides in its code. Name the domain receiving the card numbers.
What you'll learn
- Recognise how a Magecart skimmer exfiltrates card data
- Read obfuscated JavaScript to recover its decode order
- Decode char codes, a reversal and base64 in sequence
- Name the controls that stop third-party script injection
Skills tested
JavaScript deobfuscationIncident responseEncoding
Prerequisites
- What base64 is
- Reading a line of JavaScript
How it works
A web skimmer is JavaScript injected into a payment page, usually through a compromised third-party script or a hacked CMS. It reads the card fields as the customer types and sends them to the attacker, often as new Image().src = url + data, a plain image request that leaves no trace in the shop's own logs.
To survive a quick review, the drop address is obfuscated. Here it is base64, reversed, then stored as character codes. The decoding code ships in the same line, so reading it from the inside out gives the exact recipe: fromCharCode, reverse(), atob.
Common mistakes
- Pressing base64 first. The numbers are character codes; decode them with decimal before anything else.
- Skipping the reverse. A string that starts with
==is base64 written backwards: padding belongs at the end. - Answering google.com. The domain only imitates Google's; read it exactly.
How to defend against it
- Serve checkout with a strict
Content-Security-Policy: allowlistscript-src, and limitconnect-srcandimg-srcso stolen data has nowhere to go. - Load third-party scripts with Subresource Integrity (
integrity=hashes). - Monitor payment pages for script changes (PCI DSS 4.0 requirements 6.4.3 and 11.6.1).
- Prefer hosted payment fields in an iframe from the payment provider, out of reach of page scripts.