Kort samengevat: wat is e-skimming
- Wat e-skimming is: E-skimming is een cyberaanval waarbij code wordt geïnjecteerd op de website van een merchant. Gebruikers die een betaalpagina bezoeken, hebben hun gegevens gestolen door schadelijke code die de ingevoerde kaartgegevens bewaakt en "skimt".
- Gestolen vóór versleuteling: E-skimming legt gegevens vast vóór of tijdens het indienen van de betaling. Informatie wordt gestolen voordat deze de grens van versleuteling of serverbeveiliging bereikt.
- Hoe cside helpt: Om e-skimming te voorkomen, gebruik je een tool zoals cside die het gedrag van scripts van derden bewaakt en je waarschuwt bij verdachte activiteit.
- Handmatige browsercontrols: Als alternatief kun je browsercontrols zoals CSP en SRI gebruiken om handmatig te beperken welke scripts van derden toegang hebben tot betaalpagina's.
- De compliance-invalshoek: PCI DSS 4.0.1 Vereisten 6.4.3 en 11.6.1 (verplicht sinds 31 maart 2025) eisen dat merchants elk script op betaalpagina's inventariseren en toezien op ongeautoriseerde wijzigingen — directe regelgevingsdruk om e-skimming aan te pakken.
Weinig tijd? Bekijk cside's in-browser blokkering van Magecart en skimmers. Dit dekt alles hieronder in één deployment.
Wat is e-skimming?
- E-skimming
- E-skimming (ook wel "web skimming" genoemd) is een cyberaanval waarbij een kwaadwillende een stukje code injecteert op de website van een merchant. Wanneer een gebruiker de betaalpagina bezoekt, bewaakt de schadelijke code de formulierinvoer om kaartgegevens te skimmen, die vervolgens worden verzonden naar een door de aanvaller beheerde server voor frauduleus gebruik.
E-skimming is een client-side aanval waarbij schadelijk JavaScript dat in de betaalpagina van een merchant is geïnjecteerd, kaartnummers, vervaldatums, CVCs en factuuradressen vastlegt terwijl gebruikers ze typen, voordat de gegevens enige server-side versleuteling bereiken. De gestolen gegevens worden in realtime naar een door de aanvaller beheerde server gestuurd en verkocht op dark-web markten of rechtstreeks gebruikt voor kaartfraude. E-skimming is het digitale equivalent van een fysieke kaartskimmer die aan een geldautomaat is bevestigd, behalve dat het onzichtbaar is, uitsluitend uit software bestaat en maandenlang onopgemerkt kan blijven draaien.
Ter vergelijking: fysiek kaartskimmen is wanneer een apparaat op een geldautomaat of betaaltoetsenbord wordt geplaatst. Een nietsvermoedende klant gebruikt zijn kaart om een aankoop te doen, het apparaat legt de creditcardgegevens en de ingevoerde pincode vast. Het apparaat is zo gebouwd dat het onopgemerkt blijft voor het personeel.
Op vergelijkbare wijze zijn e-skimming code-injecties ontworpen om onzichtbaar te zijn. Ze blijven vaak wekenlang (en in sommige gevallen maandenlang) op betaalpagina's staan voordat website-eigenaren het doorhebben.
Welke gegevens worden bij e-skimming-aanvallen gestolen
| Gegevenstype | Gemiddelde prijs op het dark web |
|---|---|
| Amerikaanse creditcard | $10 tot $100 |
| Gmail-account | $60 |
| Banklogingegevens | $200 tot $1.000 |
| Zakelijke logingegevens | $100 tot $10.000 |
Hoewel e-skimming het vaakst verwijst naar het stelen van creditcardgegevens, kan web skimming ook in bredere zin verwijzen naar aanvallen die op deze informatie zijn gericht:
- Inloggegevens (gebruikersnaam, e-mailadres, wachtwoord)
- Persoonsgegevens (adres, wettelijke naam, telefoonnummers)
Is e-skimming een client-side aanval?
Ja. Web skimming, e-skimming of digitaal skimmen (verschillende namen voor dezelfde aanvalsvector) is een vorm van client-side aanval.
Dit zijn vaak goed voorbereide, geavanceerde aanvallen, een specialiteit van bepaalde hackergemeenschappen die Magecart-aanvallen uitvoeren.
Er zijn ook andere client-side aanvallen, zoals phishing met UI-overlays of nep-betaalpagina's.
Tijdens web skimming sturen aanvallers gestolen gegevens door naar hun eigen server, meestal via een domein dat sterk lijkt op dat van de legitieme merchant. Deze aanvalsmethode werd onder meer gebruikt tegen Ticketmaster en British Airways.
Welke websites zijn kwetsbaar voor e-skimming?
Elke website die werkt met scripts van derden, met name wanneer deze worden uitgevoerd op inlog- of betaalpagina's. Sites gebouwd op Magento, WooCommerce of andere low-code platforms zijn bijzonder kwetsbaar.
Hoewel de platforms zelf veilig zijn en hun beveiligingsteams actief proberen bekende kwetsbaarheden te patchen, worden deze platforms vaak gebruikt door niet-technische gebruikers die minder snel doorhebben dat er een aanval plaatsvindt.
Voorkom e-skimming met cside geautomatiseerde client-side beveiliging
Hoe e-skimming werkt en waar het misgaat
Om te begrijpen hoe e-skimmers te werk gaan, moeten we kijken naar hoe online betalingen werken.
Wanneer shoppers hun winkelwagen hebben gevuld en klaar zijn om te bestellen, komen ze op de betaalpagina terecht. Daar vullen ze de formuliervelden in. Nadat de betaling is ingediend, worden de gegevens versleuteld en verzonden naar de merchant en de kaartuitgever. Als de transactie wordt goedgekeurd, begint de afhandeling.
Zodra de betaling is ingediend, worden de gegevens beschermd door versleuteling, servercontrols, API-beveiliging en andere verdedigingslagen. Helaas legt e-skimming informatie vast vóór/tijdens het indienen van de betaling. De schadelijke code luistert naar toetsaanslagen terwijl de gebruiker de informatie invoert. Deze specifieke techniek, waarbij formuliervelden worden gehaakt om gegevens vast te leggen terwijl ze worden getypt, staat bekend als formjacking.
Hoe hackers e-skimming code injecteren
Wanneer een gebruiker een pagina van jouw website bezoekt, laadt zijn browser een mix van code. Deels first-party code die jouw team heeft gemaakt (of geschreven door het platform dat je gebruikt, zoals Shopify of WooCommerce). Maar jouw website serveert ook code van derden.
Voor e-commercesites omvat dit plugins en scripts van derden:
- Analysetools (zoals Amplitude)
- Promotietools (zoals nieuwsbrief e-mailcaptures)
- Bundle builders
- Advertentietracking (Meta, Google)
En nog veel andere tools van derden die essentieel zijn voor e-commercesites.
Scripts van derden zijn een toegangspunt voor web skimming
Elk script van een derde partij is een toegangspunt voor aanvallers. Ze kunnen via verschillende methoden worden geïnfiltreerd:
- Verlopen domeinen: Wanneer een oud domein niet wordt verlengd, kunnen aanvallers het domein kopen en de code aanpassen. Als jouw website code ophaalt van dat domein, wordt de schadelijke code meegeladen.
- Supply chain-aanvallen: Als een vertrouwde derde partij wordt gehackt, kan hun script schadelijke code verspreiden naar jouw site.
- Via tag managers: Als aanvallers toegang krijgen tot Google Tag Manager, kunnen ze code injecteren die rechtstreeks naar jouw live website gaat zonder enige controle. De activiteit van dat script blijft verborgen omdat het gebundeld is met meerdere andere scripts.
- Blootgestelde inloggegevens: Gestolen inloggegevens kunnen aanvallers interne toegang geven tot jouw systemen. In plaats van te proberen de kluis (jouw servers) te kraken, kunnen ze ervoor kiezen code op jouw website te injecteren.
Afzonderlijk zijn gevestigde tools van derden veilig en brengen ze minimaal risico met zich mee. Maar moderne websites hebben tientallen scripts van derden. Een rapport van Web Almanac stelde vast dat het mediane aantal domeinen van derden op een website 23 bedraagt. En die scripts van derden laden op hun beurt meer scripts in (4th-party scripts) om hen te helpen bij gegevensverwerking.
Een chatbot (script van een derde partij) kan een documentanalysetool inladen om klanten te helpen met supporttickets door hun PDF's te analyseren. Je hebt die documentanalysetool nooit rechtstreeks geautoriseerd, maar hij wordt toch op jouw site geserveerd (en heeft toegang tot gevoelige informatie).
Je begint het probleem misschien te zien: jouw website eindigt met tientallen scripts die code op jouw site kunnen injecteren zonder dat iemand ze in de gaten houdt.
Wat aanvallers doen met e-geskimde gegevens
Wat is het gevaar eigenlijk? In een optimaal scenario voor de aanvaller: ze maken een script waarmee ze kunnen zien wat gebruikers invoeren in het betaalformulier. Bingo. Ze zien nu persoonsgegevens en het kaartnummer, de vervaldatum en de CVC-code.
Als ze erin slagen die gegevens te kopiëren en naar hun eigen server te exfiltreren, is de buit veiliggesteld. Ze kunnen die informatie verkopen op het dark web of de kaartgegevens zelf gebruiken voor fraude.
Hoe online merchants e-skimming kunnen voorkomen
1. Bewaak scripts van derden: tot welke gegevens hebben ze toegang en waar sturen ze die naartoe?
Realtime scriptmonitoring is essentieel. Tools die scripts van derden bewaken en hun gedrag in de gaten houden, slaan alarm wanneer verdachte activiteit wordt gedetecteerd. Als een analysescript bijvoorbeeld plotseling formuliergegevens begint te lezen en naar een server in Rusland stuurt, kan er sprake zijn van een client-side aanval.
Het cside-platform bewaakt scripts van derden om te zien tot welke gegevens ze toegang hebben en waarschuwt je onmiddellijk als de gegevenstoegang verandert.
2. Beperk welke scripts op betaalpagina's worden uitgevoerd
Voor merchants is de eerste stap weten welke scripts op betaalpagina's worden uitgevoerd. Zorg er als voorzorgsmaatregel voor dat daar alleen noodzakelijke scripts worden uitgevoerd. Alles wat niet strikt noodzakelijk is voor betaling of fraudepreventie: verwijder het.
3. Gebruik cside voor governance van scripts van derden
Veel websites staan standaard toe dat scripts van derden rechtstreeks naar de live site gaan. Marketingteams en ontwikkelaars willen snelle updates voor verbeterde functionaliteit. Zelfs bedrijven die elk script controleren, keuren ze eenmalig goed en herzien ze zelden.
Het lijkt misschien enorm veel handmatig werk om elk toegevoegd script te beoordelen, maar een tool zoals cside houdt automatisch elk nieuw toegevoegd script bij en geeft een door AI geschreven samenvatting en risicoscore, zodat je snel kunt goedkeuren. Alle scripts worden bijgehouden in een "live inventaris" die privacy-compliance- of beveiligingsteams eenvoudig kunnen beheren.
4. Implementeer browserbeveiligingscontrols: CSP en SRI
E-skimming-aanvallen spelen zich af in de browser, dus we kunnen daar een verdedigingslaag inzetten. CSP en SRI bieden dat. Toegegeven, ze lossen niet alles op, maar ze zorgen wel voor meer zichtbaarheid.
Een strikte CSP bepaalt welke bronnen scripts mogen laden en welke eindpunten ze mogen bereiken. De scriptinhoud zelf wordt niet gecontroleerd, maar ongewenste gegevensstromen worden opgemerkt en kunnen worden geblokkeerd. Begin met Content-Security-Policy-Report-Only om te testen of alles nog goed werkt.
SRI voegt een hash toe aan bestanden: zo controleer je of een script is gewijzigd bij de bron of tijdens de overdracht. Dit maakt het veel moeilijker om schadelijke code te verspreiden via een update of gecompromitteerde leverancier. Dit werkt voornamelijk voor statische scripts. Maar automatisch bijgewerkte scripts van derden doorbreken de hashcontrole.
Waarom traditionele webbeveiliging e-skimming niet onderschept
De malware draait niet op de server van de merchant. Het draait in de browser van de klant, met dezelfde rechten en bevoegdheden als de eigen code van de merchant.
JavaScript wordt geaccepteerd en uitgevoerd in de DOM. Traditionele webbeveiligingstools hebben hier vaak geen zicht op. Zelfs client-side verdedigingstools zoals Content Security Policy kijken alleen naar de bron van elk script. Als een vertrouwde bron schadelijke code serveert, zullen content security policies die aanval niet onderscheppen of blokkeren.
Wat PCI DSS 4.0.1 vereist om e-skimming te voorkomen
PCI DSS 4.0.1 introduceerde twee vereisten die direct gericht zijn op e-skimming, beide verplicht sinds 31 maart 2025:
Vereiste 6.4.3: Scriptinventaris en -autorisatie voor betaalpagina's. Elk script dat op een betaalpagina wordt geladen, moet gedocumenteerd zijn in een inventaris, geautoriseerd zijn met een zakelijke rechtvaardiging, en de integriteit ervan moet worden beschermd. Merchants moeten kunnen bevestigen dat er geen ongeautoriseerd script op de betaalpagina draait. Handmatige beoordelingen falen in de praktijk: scripts worden vaak door marketingteams via tag managers toegevoegd en nooit door beveiliging herzien.
Vereiste 11.6.1: Manipulatiedetectiemechanisme voor betaalpagina's. Merchants moeten een mechanisme inzetten dat ongeautoriseerde wijzigingen in HTTP-headers en de inhoud van betaalpagina's detecteert. Het mechanisme moet waarschuwen bij wijzigingen en moet de pagina minimaal eens per zeven dagen evalueren (of zoals gedefinieerd door een gerichte risicoanalyse). Een gecompromitteerd script van een derde partij dat het formuliergedrag wijzigt, voldoet aan de definitie van "ongeautoriseerde wijziging."
Samen betekenen deze vereisten dat handmatige scriptbeoordelingen en periodieke audits niet langer voldoende zijn. Geautomatiseerde, continue client-side monitoring (het soort dat cside biedt) is waarvoor PCI DSS 4.0.1 geschreven werd om te verplichten.
Hoe ziet compliance met 6.4.3 en 11.6.1 er in de praktijk uit?
Compliance vereist drie zaken die continu op elke betaalpagina draaien:
- Een live scriptinventaris die elk first-party en third-party script vastlegt, inclusief brondomein en zakelijke rechtvaardiging.
- Integriteitsverificatie die bevestigt dat elk script niet is gewijzigd sinds autorisatie.
- Manipulatiedetectie die waarschuwt binnen het vereiste evaluatievenster wanneer een ongeautoriseerde wijziging in pagina-inhoud of headers wordt gedetecteerd.
Handmatige spreadsheets en maandelijkse beoordelingen kunnen niet op schaal aan deze vereisten voldoen. Geautomatiseerde tools die de daadwerkelijke browseruitvoering bewaken (die zien wat scripts werkelijk doen, niet alleen wat hun broncode zegt) vormen de praktische weg naar compliance.
| PCI DSS 4.0.1 Vereiste | Wat het verplicht | Ingangsdatum |
|---|---|---|
| 6.4.3 | Scriptinventaris, -autorisatie en -integriteit op betaalpagina's | 31 maart 2025 |
| 11.6.1 | Manipulatiedetectiemechanisme met waarschuwingen voor wijzigingen op betaalpagina's | 31 maart 2025 |
Verder lezen:
