De grootste bedreiging voor creditcardgegevens is tegenwoordig geen fysieke skimmer, maar online supply-chain-aanvallen op websites. Aanvallers injecteren kwaadaardige JavaScript in betaalpagina's. Eenmaal geïnjecteerd, legt dit script kaartgegevens vast op het moment dat ze worden ingevoerd — vaak zonder dat dit wordt opgemerkt.
De term Magecart wordt vaak synoniem gebruikt voor dit soort aanvallen. De naam is afkomstig van aanvallen op het Magento-platform, dat populair is voor e-commercewebsites. Het is een samenvoeging van "Magento" en "Cart" — een verwijzing naar de winkelwagens bij het afrekenen, waar de aanvallen vaak plaatsvinden.
Zowel Magento als WordPress zijn populaire doelwitten voor client-side-aanvallen. Deze aanvallen richten zich vaak op oudere versies van de platforms die niet goed zijn bijgewerkt. Lees meer over de grootste Magecart-aanvallen uit de geschiedenis.
Visa's Spring 2025 Biannual Threats Report identificeert digitale skimming als een van de "meest wijdverspreide en aanhoudende bedreigingen" in het betalingsecosysteem. Het rapport vermeldt dat Visa's eCommerce Threat Disruption-systeem (eTD) proactief merchantwebsites scant op skimmersignaturen in Noord-Amerika en Europa.
Mastercard's eigen gids Digital Skimming: How to Stay Protected legt uit hoe hun RiskRecon-platform deze kwaadaardige scripts opspoort, de injectiedatums en -duur bijhoudt en gerelateerde kwetsbaarheden identificeert.
Hoe supply-chain-skimming werkt
De aanvaller moet toegang hebben tot een JavaScript-bestand op de doelpagina. Hoe ze dat bereiken, kan variëren. De meest voorkomende aanpak is toegang krijgen tot een script dat al aanwezig is op de website. Dit zijn vaak oudere plugins die niet zijn bijgewerkt of onderhouden, of een script van een derde partij of marketingtool die is gecompromitteerd. Vervolgens passen ze het script aan om hun aanval uit te voeren.
Er zijn varianten hierop, zoals te zien bij de Baways (British Airways)-aanval. Hier slaagde een aanvaller erin het backend te doorbreken en een script rechtstreeks op de BA-website te installeren.
In beide gevallen kan het script dat client-side wordt uitgevoerd (d.w.z. in de browser) allerlei functionaliteiten uitvoeren. Bij skimmingoperaties doen ze het vaakst het volgende:
- Formuliervelden simpelweg kopiëren bij het indienen of via keylogging
- De afrekenpagina doorsturen naar een nep-betaalportaal
- Een kwaadaardig iFrame over de originele betaalpagina leggen
- …
Iedereen met toegang tot JavaScript op een pagina kan vrijwel alles doen wat hij wil. Deze scripts zijn zeer aanpasbaar, dynamisch op basis van verschillende criteria, en de perfecte stille manier om creditcards en persoonsgegevens te skimmen.
Overzicht van oplossingen
Proxy-gebaseerd
Client-side skimming is moeilijk te detecteren, juist omdat het buiten uw infrastructuur plaatsvindt. De scripts die in de browser van uw klant worden uitgevoerd zijn dynamisch, en aanvallers compromitteren vaak tools die al legitieme toegang hebben.
Daarom is het daadwerkelijk zien van de payload zoals die aan echte gebruikers wordt geleverd, cruciaal. Zonder deze zichtbaarheid weet u nooit volledig zeker wat er is uitgevoerd of waar de compromittering begon.
Wij hebben onze oplossing gebouwd rondom een hybride proxymodel, omdat dit de enige aanpak is die volledige, realtime dekking biedt voor moderne frontends. Elk script dat uw gebruikers bereikt, passeert de proxy. Onze supply-chain-beveiligingsoplossing biedt volledige zichtbaarheid van de daadwerkelijk geleverde payload, volledige geschiedenis en analyse van de scripts.
JavaScript-gebaseerde monitoring (Agents)
Sommige leveranciers bieden detectie via JavaScript-tags die u in uw pagina insluit. Dit betekent dat de aanvaller ze ook ziet. Beschouw het als een muizenval: hij is zichtbaar en kan worden vermeden. Als iemand scripts in uw afrekenpagina injecteert, kan diezelfde persoon ook het beschermende of monitorende script aanpassen of uitschakelen.
Detectie-only tools hebben ook de neiging om meldingen te genereren nadat gegevens al zijn geëxfiltreerd. Wij vinden preventie beter.
Crawlers
Crawler-gebaseerde tools werken door bezoeken aan uw website te simuleren en de scripts en resources vast te leggen die tijdens dat bezoek worden geladen. Cruciaal is dat ze niet noodzakelijkerwijs dezelfde scriptpayload ontvangen als een echte gebruiker. Ze 'imiteren' een gebruiker.
Scripts zijn van nature dynamisch en aanvallers maken hier gebruik van. In theorie, en in de praktijk, zijn deze crawlers herkenbaar en dus vermijdbaar.
Crawlers zijn nuttig voor oppervlakkige scans. Maar skimmers opereren niet aan de oppervlakte.
Content Security Policy (CSP)
Content Security Policy (CSP) is een browserfunctie waarmee site-eigenaren kunnen definiëren welke bronnen van content (zoals scripts) op een pagina mogen worden geladen. Wanneer correct geconfigureerd, kan CSP helpen ongeautoriseerde of onverwachte code van derden te blokkeren door scriptoorsprongen te beperken.
Het is een waardevolle preventieve maatregel, met name voor het verminderen van blootstelling aan inline scriptinjecties of het laden vanuit onbekende domeinen. Wij raden aan CSP uitsluitend als een laag te gebruiken. Want CSP kan de payload van het script niet zien.
In onze presentaties gebruiken we vaak de volgende slide om CSP te illustreren:
U heeft 2 dozen. In de ene zit een puppy, in de andere een bom. Welke is welke…? Dat is CSP.
Op onze vergelijkingspagina gaan we dieper in op de 4 hier beschreven benaderingen.
Een korte samenvatting van de oplossingen
Scripts die in de browser van uw klant worden geladen, hebben toegang tot invoervelden, kunnen content aanpassen, gegevens elders naartoe sturen en meer. Ze zijn dynamisch, vaak afkomstig van derden, en kunnen zonder uw medeweten worden gewijzigd.
Dat is waarom client-side skimming zo effectief is. En waarom het voorkomen ervan meer vereist dan oppervlakkige scanning.
Waarom is het leveringspad zo belangrijk?
Omdat dat de enige manier is om te zien wat de gebruiker daadwerkelijk bereikt. Scripts zijn dynamisch. Aanvallers kunnen ze op elk moment wijzigen, vaak conditioneel. Als u niet in het leveringspad zit, vertrouwt u op momentopnames of aannames. In het pad zitten betekent dat u elk verzoek, voor elke sessie, in realtime ziet, en dat u kunt ingrijpen voordat er iets gevaarlijks wordt uitgevoerd.
Wat is de beste manier om deze aanvallen te voorkomen?
De meest effectieve methode vandaag de dag is onze proxy-gebaseerde scriptmonitoring. Deze inspecteert elk script voordat het de browser bereikt, verifieert de integriteit ervan en blokkeert kwaadaardige code in realtime. Het werkt voor elke gebruikerssessie en biedt volledige zichtbaarheid, logging en compliancedekking.
Is JavaScript-gebaseerde monitoring (Agents) een goede optie?
Het kan helpen bij het detecteren van bepaalde bedreigingen, maar het draait in dezelfde omgeving die aanvallers als doelwit hebben. Als een aanvaller een skimmer kan injecteren, kan hij waarschijnlijk ook het monitoringscript uitschakelen of omzeilen. Het is nuttig, maar op zichzelf niet voldoende.
Is een crawler een goede optie?
Crawlers simuleren bezoeken aan uw site en leggen zichtbare scripts vast. Ze zijn geschikt voor periodieke scans, maar ze opereren niet binnen echte sessies. Als een skimmer alleen actief is onder bepaalde omstandigheden (zoals een ingelogde gebruiker of een specifiek IP-bereik), zal een crawler hem niet zien.
Is CSP een goede optie?
CSP (Content Security Policy) kan het risico verminderen door te beperken van welke bronnen scripts mogen worden geladen. Maar het analyseert niet wat een script doet zodra het is geladen. Het is een nuttige laag, maar geen solide detectie- of preventiesysteem.
