TL;DR: Magecart-aanvallen
- Wat is een Magecart-aanval: Een Magecart-aanval is een browsergebaseerde web-skimming-aanval waarbij kwaadaardige JavaScript in een website wordt geïnjecteerd om betaalkaartgegevens of gevoelige formulierinvoer rechtstreeks uit de browser van de gebruiker te stelen tijdens het afrekenen of inloggen.
- Waarom Magecart-aanvallen moeilijk te detecteren zijn: Magecart opereert volledig in de browser, waardoor traditionele verdedigingen zoals WAF's, SIEM's en transactiemonitoring niets ongewoons zien terwijl legitieme betalingen gewoon blijven slagen.
- Hoe Magecart-aanvallen te voorkomen: Effectieve preventie vereist het minimaliseren van scripts op afrekenspagina's, het beheren en monitoren van JavaScript van derden, het afdwingen van browsercontroles zoals CSP en SRI, en het inzetten van een continue client-side monitoringtool zoals cside.
"Ik ben onlangs op de hoogte gesteld van een datalek in uw winkel en mijn creditcard is misbruikt."
Dit is een nachtmerrie voor klantenservice. Maar dat niet alleen: uw fraude- en financeteams ontvangen ook meldingen van kaartuitgevers en vragen van betaalproviders.
Magecart gaat niet over het namaken van inlog- of betaalpagina's. Het gaat over het misbruiken van uw echte inlog- en afrekenspagina's die klanten vertrouwen.
Dat is Magecart: het is wat er gebeurt als uw inlog- en afrekenproces de zwakste schakel worden in uw beveiligingscontroles. Zelfs als uw servers, WAF en PCI-controles solide zijn, kunnen een paar regels kwaadaardige JavaScript in de browser wekenlang kaartgegevens en PII skimmen voordat iemand het merkt.
Deze gids legt uit wat Magecart is, hoe het werkt, waarom het moeilijk te detecteren is en welke tools er zijn voor Magecart-preventie.
Wat is een Magecart-aanval?
Een Magecart-aanval is een browsergebaseerde web-skimming-aanval. Kwaadaardige JavaScript wordt geïnjecteerd in een e-commercesite met één doel: betaalkaartgegevens stelen.
Dit is iets wat u uzelf en uw klanten niet toewenst. Het is een nachtmerrie voor webwinkels omdat het het vertrouwen van uw klanten misbruikt. Het veroorzaakt grote schade aan online bedrijven: financiële verliezen, chargebacks, regelgevingsboetes en ernstige reputatieschade.
Uw WAF en server-side beveiligingsstack zullen hier niets van zien. De aanval speelt zich volledig af in de browser van de gebruiker, in een codeomgeving die uw backend-monitoring nooit bereikt. Zelfs andere PCI DSS-gerelateerde controles zoals versleuteling of tokenisatie betekenen niets als de aanvaller de kaartgegevens steelt voordat die verdedigingen überhaupt in werking treden. Transacties aan uw kant blijven gewoon doorgaan alsof er niets aan de hand is. Vanuit uw perspectief ziet het eruit als business as usual. Maar ondertussen worden gegevens stilletjes geëxfiltreerd vanuit de browser van uw klant naar de servers van de aanvaller.
Magecart is een vorm van web-skimming
Magecart is een vorm van web-skimming (of e-skimming). Web-skimming is de online versie van creditcardskimming bij geldautomaten: toetsaanslagen of invoer worden gekopieerd door verborgen apparaten en later gebruikt om elders geld uit te geven. Wanneer aanvallers hun kwaadaardige JavaScript aan een webwinkel toevoegen, biedt dat hen veel mogelijkheden. Ze kunnen zien wat een gebruiker in betaal- of inlogformulieren typt en deze gegevens heimelijk naar hun eigen systemen exfiltreren.
Hoe de term "Magecart" zich heeft ontwikkeld
Rond 2015-2016 begonnen beveiligingsonderzoekers te melden dat op Magento gebaseerde webwinkels het doelwit waren van online kaartskimming-aanvallen. Doorgaans werd JavaScript geïnjecteerd in afrekenspagina's om betaalgegevens en PII te stelen en te exfiltreren. Vandaar: 'Magecart' – 'Mage' van Magento en 'cart' – kort voor winkelwagen.
In de loop van de tijd verspreidden Magecart-aanvallen zich naar andere platforms en op maat gemaakte e-commerceopstellingen. Elk platform met client-side JavaScript en scripts van derden was kwetsbaar, niet alleen Magento.
Van Magento-kaartskimming naar Magecart-stijlaanvallen overal
Magecart evolueerde tot een aanvalsstijl: een label voor digitale skimming, formjacking, e-skimming, online kaartskimming, en het is uitgegroeid tot een grote bedreiging voor online retailplatforms.
Magecart is minder een bijnaam voor een specifieke groep en meer een overkoepelend label voor een ecosysteem van digitale skimminggroepen en -technieken. In grote lijnen gebruiken ze dezelfde aanvalsvector, maar vertrouwen ze op verschillende infrastructuur en tooling.
Hoe Magecart-aanvallen werken
Het idee lijkt eenvoudig: formuliergegevens kopiëren en exfiltreren naar een gecompromitteerd eindpunt. Hoe moeilijk kan het zijn? In werkelijkheid zijn deze aanvallen subtieler en geavanceerder. Op elk moment moet de webwinkel zich gedragen zoals verwacht: geen fouten, geen time-outs.
Om de digitale skimming succesvol te laten zijn, mogen noch uw monitoringsystemen noch uw klanten iets ongewoons opmerken.
Zo verloopt een typische Magecart-aanval in de browser.
1. Kwaadaardige JavaScript in de site injecteren
Eerst heeft de aanvaller een manier nodig om zijn eigen JavaScript in de browser van de gebruiker te laten draaien, want daar vindt de aanval plaats. Ze zoeken naar kwetsbaarheden zoals verouderde of verkeerd geconfigureerde plugins of CMS-componenten, of verwaarloosde scripts van derden zoals een plugin, CDN-bestanden, tagbeheerder enzovoort.
Dit zwakke punt wordt de aanvalsvector: de aanvaller voegt een paar regels van zijn kwaadaardige JavaScript toe aan een bestaand productiebestand of script van een derde partij. De wijziging is klein, vaak vermengd met legitieme code, zodat er niets opvalt tijdens een beveiligingsreview.
2. Betaal- en formuliergegevens uitlezen
Zodra dat gedaan is, krijgt de kwaadaardige JavaScript toegang tot de DOM en leest de gegevens die de gebruiker in het formulier heeft ingevoerd. JavaScript dat de DOM benadert en wijzigt is normaal gedrag in moderne webontwikkeling. Zo maakt JavaScript pagina's dynamisch zonder het volledige HTML-document opnieuw te laden. Veel frameworks zoals React of Svelte zijn afhankelijk van het feit dat JavaScript de DOM kan manipuleren.
De digitale skimmer richt zich nu op specifieke velden in het betaal- of inlogformulier: kaartnummer, vervaldatum, CVV, naam, adres enzovoort. Het kopieert deze waarden zonder het formulier of de gebruikersstroom op een zichtbare manier te wijzigen.
3. De gegevens exfiltreren naar de server van de aanvaller
Zodra de gegevens zijn vastgelegd, is de volgende stap om ze onopgemerkt over te dragen naar een server die door de aanvaller wordt beheerd. Meestal is de trigger voor de exfiltratie het klikken van de gebruiker op de knop 'betalen'/'verzenden'. Op dat moment stelt het script de payload samen (onbewerkt of gecodeerd) met kaartgegevens, PII en vaak contextdetails zoals tijdstempels of URL's.
Typische exfiltratietechnieken zijn fetch, XMLHttpRequest voor oudere code, verborgen afbeeldingsverzoeken en navigator.sendBeacon(). TLS/HTTPS stopt de exfiltratie niet omdat het eruitziet als een legitiem https-verzoek met een zeer kleine payload. Aanvallers gebruiken vaak domeinen die sterk lijken op de legitieme hostnamen van webwinkels, CDN's of analytics, zodat ze geen argwaan wekken. Als het exfiltratieverzoek mislukt, vangt de code de fout gewoon op en wordt niet uitgevoerd. Maar de legitieme transactie gaat wel door.
4. De winkel draaiende houden en afhandeling laten plaatsvinden
Om de Magecart-aanval effectief te laten zijn, moeten transacties blijven stromen. De skimmer exfiltreert een kopie van de gegevens, maar het betaalformulier wordt ook ingediend bij uw backend en betaalgateway. Bestellingen worden aangemaakt, betalingen worden geautoriseerd en uw afhandelingssystemen gaan aan de slag.
Hoe aanvallers toegang krijgen tot webscripts voor Magecart-aanvallen
Aanvallers scannen op zwakke plekken in uw webstack: plaatsen waar scripts kunnen worden bewerkt en skimmingcode kan binnensluipen. Om uw site te verdedigen en een effectief dreigingsmodel op te bouwen, moet u zich richten op een aantal veelvoorkomende toegangspunten voor Magecart-aanvallen.
1. Magecart via plugins, CMS of e-commerceplatformcode
Uw eigen CMS of e-commerceplatform is een direct aanvalsoppervlak. Platforms zoals Magento, WooCommerce, Shopify-apps en aangepaste afrekencode vereisen regelmatige controle. Typische zwakke punten zijn verouderde plugins en extensies, of onveilige bewerkingen van sjablonen of JavaScript-bestanden. Beheerdersaccounts hebben extra bescherming nodig: als een aanvaller als beheerder kan inloggen, zijn scriptwijzigingen eenvoudig.
Als uw webwinkel een verouderde betaal- of trackingplugin in Magento of WooCommerce gebruikt, is digitale skimming slechts één stap verwijderd. Als aanvallers erin slagen de pluginbestanden te wijzigen of een beheerdersaccount te misbruiken, hoeven ze slechts één JavaScript-bestand op de afrekenspagina te bewerken om hun skimmer toe te voegen.
2. Magecart via de toeleveringsketen van code van derden
Dit omvat elke toegang via <script src> of een tagbeheerder: CDN-bibliotheken, A/B-testen of analytics voor uw marketingteam, chat-/ondersteuningswidgets voor klantenservice enzovoort. Deze scripts worden beheerd en gehost door externe leveranciers of geïnjecteerd via tagbeheerders die code op de meeste pagina's kunnen uitvoeren. Eén gecompromitteerd script van een derde partij of een misbruikt tagbeheerderaccount is voldoende om skimmercode te verspreiden naar alle sites en pagina's waar deze code wordt gebruikt.
Soms heeft een Google Tag Manager (GTM)-account of externe chatwidget code die op de hele site wordt geladen (inclusief afrekenspagina's), ook als ze op die pagina's geen functionaliteit bieden. Als GTM wordt overgenomen en er een extra tag met skimmer-JavaScript-code wordt toegevoegd, draait elke afrekenspagina op elke site die de container gebruikt nu Magecart-code.
Waarom Magecart-aanvallen moeilijk te detecteren zijn
Nu we hebben gezien hoe een Magecart-aanval in de browser werkt, is het terecht om te vragen: waarom onderscheppen traditionele verdedigingen dit niet? We hebben WAF-regels, SIEM-dashboards en PCI-controles. Toch hebben deze beveiligingslagen nog steeds een blinde vlek voor client-side, browsergebaseerde aanvallen zoals Magecart.
1. WAF, SIEM en transactiegegevens missen Magecart-aanvallen
De meeste webbeveiligingstools zijn ontworpen om server-side activiteit te beschermen of bedrijfsinfrastructuur te monitoren, niet de browser van gebruikers. Een WAF inspecteert verkeer naar uw applicaties, maar ziet niet wat de browser rechtstreeks naar andere domeinen stuurt. Een SIEM toont server- en infrastructuurlogboeken, maar registreert geen extra uitgaande aanroepen vanuit de browser naar kwaadaardige eindpunten.
Het analyseren van transactiegegevens op fraude zal geen bewijs van een Magecart-aanval aan het licht brengen, omdat de legitieme aankoopstroom normaal wordt afgerond. De skimmer kopieert de kaartgegevens in de browser terwijl de backend een schone, geautoriseerde transactie zonder afwijkingen ziet.
Ervaren aanvallers kunnen gevoelige waarden op DOM-niveau onderscheppen voordat ze ooit naar uw servers worden verzonden, waardoor uw waarschuwingssystemen effectief worden uitgeschakeld.
2. Geen zichtbaarheid van scripts van derden vergroot het Magecart-risico
Volledig inzicht in scripts van derden is een enorme uitdaging. Welke scripts draaien er? Mogen ze draaien op een afrekenformulier of inlogpagina? Wie houdt hun gedrag en wijzigingen in de loop van de tijd bij? Allemaal zeer basale vragen waarmee veel organisaties worstelen als niemand de client-side toeleveringsketen volledig beheert.
Webontwikkelaars hebben beperkte controle over deze scripts, omdat ze worden beheerd en gehost door externe leveranciers. Wanneer eigendom verandert of personeel wordt ontslagen, worden scripts van derden of JavaScript-bibliotheken mogelijk niet meer bijgewerkt en kan een kwetsbaarheid in een van die scripts van derden een beveiligingsrisico worden.
Dit is precies het toegangspunt dat Magecart-aanvallen uitbuiten. Compromitteer één veelgebruikt script of bibliotheek van een derde partij, en u kunt het omzetten in een grootschalige supply chain-aanval op elke site die het gebruikt.
3. Een client-side probleem vereist een client-side verdediging
Dit is het kernprobleem met Magecart: de meeste bedrijven hebben geen echt inzicht in wat er in de browser gebeurt. Server-side beveiligingsdashboards laten niet zien naar welke domeinen de browser verzoeken stuurt tijdens het afrekenen, zelfs niet wanneer dat cross-origin aanroepen zijn (CORS).
Ze geven geen waarschuwing wanneer een nieuw uitgaand domein verschijnt op een betaalformulier. En ze sturen geen waarschuwing bij een Content Security Policy-schending (connect-src) wanneer een script probeert gegevens te exfiltreren naar een onverwacht eindpunt.
4. Fraude wordt pas later ontdekt, veel later
Een van de meest schadelijke aspecten van een Magecart-aanval is dat deze zelden wordt ontdekt door de organisatie die daadwerkelijk is getroffen. In de meeste gevallen komen de eerste tekenen van problemen van banken, kaartuitgevers of klanten. Tegen de tijd dat deze externe meldingen binnenkomen, heeft de skimmer al een aanzienlijk volume aan kaarthoudergegevens verzameld.
Hoe Magecart-aanvallen te voorkomen
De kernprincipes van Magecart-preventie zijn eenvoudig: houd uw afrekenproces zo schoon en minimaal mogelijk, behoud controle over scripts die daar draaien en voeg browsercontroles toe met continue 24/7-monitoring. De volgende logische stappen helpen u preventiemaatregelen te implementeren om uw blootstelling aan Magecart te verminderen.
1. Draai alleen noodzakelijke scripts op inlog- en afrekenspagina's
Voor inloggen en afrekenen voegt elk extra script risico toe. Deze pagina's mogen alleen basis-UX laden en wat strikt noodzakelijk is voor authenticatie en betaling. Verwijder zonder aarzeling marketing, analytics, chatwidgets enzovoort van inlog- en afrekenspagina's.
Isoleer het afrekenproces bij voorkeur en gebruik een minimalistisch sjabloon of zelfs een apart subdomein met alleen noodzakelijke invoer van derden. Zo beperkt u uw aanvalsoppervlak en de mogelijkheden voor Magecart-code om zijn sporen te verbergen. Bovendien is het veel eenvoudiger om op te ruimen als er iets misgaat.
2. Gebruik cside voor beheer van scripts van derden
Maak een scriptinventaris om een duidelijk beeld te krijgen van welke scripts waar draaien en wat ze daadwerkelijk doen. Gevoelige pagina's, waaronder inlog- en afrekenspagina's, mogen alleen scripts van derden laden die zijn goedgekeurd met een onderbouwing.
Definieer ten slotte een wijzigingsbeheerproces om te specificeren wie scripts en tagbeheerdercontainers mag wijzigen. U kunt ook previews en goedkeuring vereisen voordat wijzigingen live gaan. Pas tegelijkertijd strikt leveranciersbeheer toe en maak scriptbeveiliging en incidentafhandeling onderdeel van contracten en onboarding met externe leveranciers.
Een beheertool voor scripts van derden kan deze elementen direct automatiseren met een dashboard dat elk script aan een leverancier koppelt en automatisch beschrijvingen genereert van wat elk script doet.
3. Gebruik browsercontroles: CSP en SRI
Een Content Security Policy (CSP) helpt u te definiëren van welke locaties scripts mogen worden geladen (script-src) en waarheen de browser gegevens mag verzenden (connect-src).
script-src moet worden beperkt tot vertrouwde domeinen en connect-src mag alleen de eindpunten toestaan die nodig zijn voor het afrekenen, in plaats van elke bestemming toe te staan.
Het inschakelen van een CSP helpt ook bij het rapporteren van beleidsschendingen, met name op inlog- en afrekenspagina's. Onverwachte scriptinjectie en exfiltratiegepogingen worden zo zichtbaar. Gebruik voor statische bibliotheken van derden Subresource Integrity (SRI) om integriteit te versterken, maar beschouw het als één laag in uw verdediging, niet als de allesomvattende oplossing.
4. Gebruik cside voor Magecart-monitoring
Bij Magecart heeft u ogen in de browser nodig. Continue, 24/7 geautomatiseerde client-side monitoring onthult welke scripts draaien en verdacht gedrag dat wijst op Magecart-activiteit. Een Magecart-preventietool brengt alle scripts op uw site in kaart en gebruikt een AI-ondersteunde engine om rode vlaggen te detecteren op basis van een verscheidenheid aan datapunten.
cside helpt merchants bij het identificeren en stoppen van:
- Supply chain-aanvallen via JavaScript van derden
- Kwaadaardige of gemanipuleerde scripts van derden
- Verkeerd geconfigureerde scripts die gevoelige gegevens lekken
- Magecart, e-skimming, formjacking en verwante skimmers
cside is gevalideerd voor PCI DSS 4.0.1 client-side vereisten en wordt gebruikt door complianceteams om AVG-, CCPA- en andere privacyschendingen te voorkomen die worden veroorzaakt door risicovolle scripts van derden.
Snelle zelfevaluatie voor Magecart-gereedheid
Bent u klaar om Magecart-stijlaanvallen af te weren? Ja/nee
- Onze afrekens- en inlogpagina's laden alleen scripts waarvan we het doel en het verwachte gedrag kennen
- We hebben een actuele lijst van alle scripts, eigen en van derden, die op onze afrekenspagina draaien
- Marketing, analytics, A/B-testen en chatwidgets worden gemonitord om te garanderen dat ze niet meer gegevens verzamelen dan noodzakelijk
- Wijzigingen in 'vertrouwde' scripts zoals tagbeheerdercontainers worden beheerd …
- We verifiëren scriptintegriteit via een client-side beveiligingstool of een ander mechanisme (zoals Subresource Integrity)
- We hebben client-side monitoring die laat zien waarheen gegevens die door scripts van derden worden verzameld, worden verstuurd
- We hebben een mechanisme om scripts te blokkeren die publiekelijk als gecompromitteerd zijn geïdentificeerd
De grootste Magecart-aanvallen in de recente geschiedenis
Ons 2025 Client-side dreigingsrapport identificeerde meer dan 72.000 websites die zijn getroffen door client-side aanvallen. Die aanvallen volgen hetzelfde patroon als de grootste Magecart-aanvallen in de recente geschiedenis: een paar regels kwaadaardige JavaScript compromitteert miljoenen gebruikers voordat iemand het merkt. Hieronder een kort overzicht van de meest opvallende gevallen.
- Ticketmaster (2018) – Gecompromitteerd chatbotscript Aanvallers injecteerden skimmingcode in een chatbot van een derde partij die werd gehost door Inbenta Technologies. Elke paginalading voerde het kwaadaardige script uit, waardoor betaal- en persoonsgegevens van ongeveer 9,4 miljoen klanten gedurende vier maanden werden blootgesteld. Het incident leidde tot regelgevingsboetes en class action-schikkingen.
- British Airways (2018) – 22 regels kwaadaardige JavaScript Aanvallers kregen toegang via gecompromitteerde inloggegevens van een derde partij en voegden slechts 22 regels skimmercode in aan een bibliotheek die werd gebruikt op de betaalpagina van BA. Gegevens werden geëxfiltreerd naar een look-alike domein ("baways.com"), wat ongeveer 400.000 klanten trof. BA kreeg tientallen miljoenen aan AVG-boetes en jaren van rechtszaken.
- Newegg (2019) – Geïnjecteerd script op afrekenspagina Aanvallers verkregen schrijftoegang tot de betaalserver van Newegg en voegden een kleine skimmer toe aan de afrekenknop. Wanneer klanten een betaling indienden, werden kaartgegevens verzonden naar een nep-analysedomein ("neweggstats.com"), waardoor kaartnummers, CVV's en PII meer dan een maand lang werden gecompromitteerd voordat het werd ontdekt.
FAQ
Hoe weet ik of mijn site een Magecart- of e-skimming-infectie heeft?
Magecart-aanvallen zijn moeilijk te detecteren omdat het afrekenproces gewoon blijft werken en server-side tools niets ongewoons zien. De enige betrouwbare methode is client-side monitoring met een tool zoals cside, die scripts inspecteert die in de browser draaien en verdachte codewijzigingen of uitgaande gegevensoverdrachten markeert.
Kunnen Magecart-aanvallen plaatsvinden als ik een betaalverwerker zoals Stripe of PayPal gebruik?
Ja. Als uw afrekenformulieren op uw eigen website worden gehost (ook bij gebruik van een externe betaalverwerker), kunnen scripts van derden op uw pagina nog steeds toegang krijgen tot wat gebruikers in die velden typen. Als uw site klanten volledig doorstuurt naar het domein van een betaalprovider (bijv. checkout.stripe.com), kan Magecart daar geen kaartgegevens skimmen. Andere gevoelige informatie op uw site, zoals inloggegevens, KYC-gegevens of accountgegevens, kan echter nog steeds worden gescraped als er kwaadaardige scripts aanwezig zijn.
Kan een Magecart-aanval plaatsvinden als ik creditcardgegevens tokeniseer of versleutel?
Ja. Tokenisatie en versleuteling vinden pas plaats nadat de klant de betaling heeft ingediend, maar Magecart steelt de gegevens terwijl de gebruiker typt. Zelfs volledig getokeniseerde of versleutelde workflows blijven kwetsbaar voor skimming als er kwaadaardige scripts op de pagina actief zijn.
