Magecart is webskimming die in de browser draait. Kwaadaardige JavaScript landt op een checkout- of login-pagina, leest wat de bezoeker in het formulier typt, en stuurt een kopie naar een server die de aanvaller controleert. De legitieme betaling gaat gewoon door, dus vanaf je servers ziet het eruit als een normale dag met schone transacties. Alles lijkt prima terwijl kaartdata vertrekt, en die kloof is het hele probleem.
Dit bericht legt de mechaniek uit voor iemand die de dreiging voor het eerst tegenkomt. Het is geen preventiebeleid en niet de formjacking-vs-Magecart-taxonomie. Het loopt de daadwerkelijke sequentie door: hoe de code binnenkomt, hoe hij data vastlegt, en hoe hij vertrekt. Begrijp die drie zetten en je begrijpt waarom een web application firewall, een SIEM en een betaalprocessor allemaal groen kunnen staan terwijl een skimmer draait. cside bewaakt die browserlaag direct, kijkt naar elk script terwijl het executeert, en flagt het moment dat er één velden begint te lezen of een domein aanroept dat het nooit eerder aanraakte, wat de basis is voor het in realtime detecteren van Magecart in plaats van na de breach.
De aanval in drie zetten
Elke skimming-campagne, ongeacht welke groep hem draait, komt neer op dezelfde lifecycle. Strip de branding eraf en je houdt drie zetten over.
| Zet | Wat er gebeurt | Waar het leeft |
|---|---|---|
| Injecteer | Aanvaller krijgt zijn JavaScript op je pagina geladen | Een gecompromitteerd first-party-bestand, third-party-tag of tag-manager |
| Leg vast | Het script leest kaart- of credential-data uit het formulier | De DOM en form-event-listeners in de browser |
| Exfiltreer | Een kopie van de data wordt naar de server van de aanvaller gestuurd | Een outbound browser-request naar een aanvaller-domein |
De rest van dit bericht loopt elke zet op volgorde door, omdat die volgorde is wat de aanval onzichtbaar maakt.
Zet 1: hoe de code op de pagina komt
De aanvaller heeft nodig dat zijn JavaScript executeert in de browser van de bezoeker. Hij heeft drie veelvoorkomende routes op de pagina, geen waarvan de logica van je origin-server raken.
- Een zelf-gehost bestand. Hij krijgt schrijftoegang via een kwetsbare plugin, een verouderde CMS, of een gestolen admin-login, en voegt dan een paar regels toe aan een JavaScript-bestand dat je al uitlevert. De wijziging is klein en vaak weggestopt in legitieme code, dus een diff valt niet op.
- Een third-party-script. Hij compromitteert een vendor wiens script je direct laadt met
<script src>, zoals een analytics-, chat- of A/B-test-widget. Nu shipt de skimmer vanaf het vendor-domein naar elke klant die je pagina laadt, en hij staat nooit in je repository om te vinden, en daarom is het beveiligen van third-party-scripts een eigen discipline. - Een tag-manager. Hij neemt een Google Tag Manager-container of vergelijkbaar over en voegt één tag met de skimmer toe. Elke site en pagina die die container gebruikt draait nu de code, inclusief checkout-pagina's waar de tag niets te zoeken heeft.
De third-party- en tag-manager-routes schalen, wat ze tot de gevaarlijke maakt. Eén gecompromitteerde vendor zaait skimmers over elke site die hem vertrouwt, en een script dat jij goedkeurde kan een ander script meetrekken dat je nooit reviewde, het fourth-party-probleem. Dit is de supply-chain-vorm die PCI DSS 4.0.1-requirement 6.4.3 en 11.6.1 aanpakken door een inventaris en autorisatie van elk script op een betaalpagina te eisen. De Ticketmaster-breuk van 2018 nam precies dit pad: de skimmer bereikte checkout via het gecompromitteerde chatbot-script van een leverancier, niet via Ticketmasters eigen code (Wikipedia-samenvatting van het 2018-incident).
Zet 2: hoe de skimmer je formulier leest
Zodra het script draait is het lezen van het formulier gewone webdevelopment die tegen je wordt gekeerd. De DOM lezen en wijzigen is hoe elk modern framework werkt, dus de acties van de skimmer lijken op normaal pagina-gedrag. Een skimmer doet doorgaans één of meer van het volgende:
- Leest input-waarden direct. Het selecteert de kaartnummer-, expiry-, CVV- en naamvelden op hun
id-,name- ofautocomplete-attributen en leest.valuerechtstreeks uit de DOM. - Koppelt event-listeners. Het haakt
input,keyup,changeofblurop de betaalvelden, zodat het elke toetsaanslag vangt zelfs als de gebruiker nooit indient. - Kaapt het submit-pad. Het wikkelt de submit-handler van het formulier of haakt de "betaal"-knop, en stelt de volledige payload samen op het moment dat de gebruiker commit.
- Patcht netwerk-primitieven. Geavanceerde skimmers overschrijven
fetch,XMLHttpRequest.prototype.sendofnavigator.sendBeaconom het echte betaal-verzoek te lezen terwijl je eigen code het verstuurt. - Overlayt een neptveld. Sommige injecteren een nep-betaal-iframe bovenop het echte, zodat de shopper kaartgegevens direct in de input van de aanvaller typt. cside's eigen analyse van een Magecart-campagne vond een nep-betaal-frame dat bij checkout werd ingevoegd via één geobfusceerde JavaScript-regel, het soort swap dat een server-side scan nooit ziet.
Conditioneel serveren is wat het stil houdt
De skimmer vuurt niet voor iedereen. Hij gate zichzelf zodat de mensen die hem hoogstwaarschijnlijk zouden vangen, namelijk security-teams, scanners en bots, het kwaadaardige gedrag nooit zien:
- Pad-gating. Veel skimmers wapenen alleen op URL's die matchen met een checkout- of login-patroon, dus de code ligt elders slapend.
- Automatiseringsdetectie.
navigator.webdriverlezen geefttruein headless- en geautomatiseerde browsers, dus de skimmer kan schone code serveren aan een scanner en de echte payload aan een shopper. Geavanceerdere varianten zoeken naar Selenium-globals of Chrome DevTools Protocol (CDP)Runtime-leksen om geïnstrumenteerde browsers te spotten. - Eénmaal-per-sessie vuren. Eén keer exfiltreren voorkomt dubbele netwerk-ruis die in een log zou opvallen.
Die wapenwedloop escaleert ook aan de aanvallerskant: het cside Future of Web Security 2026-rapport volgde playwright-stealth dat ruwweg tienvoudig groeide over 2025, automatisering gebouwd om navigator.webdriver en vergelijkbare checks te verslaan. Dezelfde evasie die de tooling van een aanvaller voor defenders verbergt, is wat een skimmer voor de jouwe verbergt. De code is bovenop dit alles meestal geobfusceerd, wat de intentie bij een handmatige review begraaft.
Zet 3: hoe de data vertrekt
Vastleggen is nutteloos voor de aanvaller totdat de data hem bereikt. Exfiltratie is één outbound request vanuit de browser, en de aanvaller heeft verschillende stille manieren om het te versturen.
| Methode | Hoe het er op de draad uitziet |
|---|---|
navigator.sendBeacon() | Een kleine POST die betrouwbaar vuurt bij unload, ontworpen voor analytics, dus het valt niet op |
fetch() / XMLHttpRequest | Een standaard async-request, vaak naar een look-alike-domein dat een CDN of analytics-host imiteert |
| Image-request | De payload wordt toegevoegd aan de src van een <img> als query-string; de browser "laadt" een afbeelding die eigenlijk een data-drop is |
| WebSocket | Een persistente kanaal om vastgelegde toetsaanslagen bijna realtime te streamen |
Drie eigenschappen maken deze lek van buitenaf vrijwel onmogelijk te spotten. De request is HTTPS, dus hij is versleuteld als al je andere verkeer. De bestemming is meestal een typosquat- of vers-geregistreerd look-alike-domein dat leest als een echte vendor. De British Airways-skimmer exfiltreerde naar baways.com, dus het springt niet uit een log. En de payload is klein en vaak base64-gecodeerd, dus het leest als een routine-telemetrie-ping. Cruciaal: dit request gaat van de browser rechtstreeks naar de aanvaller; het passeert nooit je origin, je WAF of je betaal-gateway. Dat is de hele reden dat de diefstal onzichtbaar is voor de server.
Waarom je server, WAF en processor het nooit zien
Zet de drie zetten samen en de blinde vlek is evident. De code laadde in de browser, las het veld in de browser, en stuurde de kopie vanuit de browser naar een derde domein. Je backend zag enkel de legitieme, geautoriseerde transactie.
- Een web application firewall inspecteert requests die op je origin aankomen. Het exfiltratie-request komt daar nooit aan, dus de WAF heeft niets te inspecteren.
- Een SIEM aggregeert server- en infrastructuur-logs, en de skimmer genereert geen server-event. Fraudemonitoring flagt aankoop-anomalieën, maar de echte aankoop voltooide precies zoals verwacht.
- Een betaalprocessor zoals Stripe of Adyen beveiligt de transactie die hij ontvangt. Als je kaartvelden op je eigen pagina staan, leest een skimmer ze voordat de processor ooit betrokken is, en je pagina blijft zijn eigen PCI DSS 4.0.1 6.4.3- en 11.6.1-bewijs verschuldigd ongeacht de processor.
De aanval leeft in een runtime die je server-side stack niet kan bereiken. Een client-side probleem vraagt om een client-side verdediging.
Hoe browserlaag-monitoring elke zet vangt
Detectie moet zitten waar de skimmer draait. cside bewaakt scripts en gedrag in de browser, dus elke zet laat een signaal achter waarop het kan acteren.
- Injecteer toont zich als een nieuw of gewijzigd script. cside onderhoudt een scriptinventaris en flagt toevoegingen, wijzigingen en gemanipuleerde third-party-tags wanneer ze verschijnen, niet weken later in een frauderapport.
- Vastleggen toont zich als gedrag. Onverwachte listeners op betaalvelden, code die inputs leest die hij niet zou moeten, en overrides van
fetchofsendBeaconzijn runtime-anomalieën tegen een bekend-goede baseline. - Exfiltreer toont zich als een bestemming. cside brengt outbound requests naar domeinen buiten je allowlist aan de oppervlakte, de signatuurzet van een skimmer die probeert te vertrekken.
Omdat cside draait in echte browsers in plaats van een clean-room-scanner, verbert conditioneel serveren de skimmer niet zoals bij een headless-crawler. Dezelfde zichtbaarheid levert het bewijs dat PCI DSS 4.0.1 verwacht: een geautoriseerde inventaris van betaalpagina-scripts voor 6.4.3, en alerting op ongeautoriseerde wijzigingen van script-content en headers voor 11.6.1, beide verplicht sinds 2025-03-31.
