TL;DR
- 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".
- 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.
- 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.
- Als alternatief kun je browsercontrols zoals CSP en SRI gebruiken om handmatig te beperken welke scripts van derden toegang hebben tot betaalpagina's.
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.
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 ontworpen dat het onzichtbaar is en niet opvalt bij medewerkers.
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, volledige naam, telefoonnummers)
Is e-skimming een client-side aanval?
Ja. Web skimming, e-skimming of digitaal skimmen (verschillende namen voor dezelfde aanvalsvector) zijn een vorm van client-side aanval.
Dit zijn vaak goed voorbereide en geavanceerde aanvallen, waarbij bepaalde hackergemeenschappen zich hebben gespecialiseerd in het uitvoeren van Magecart-aanvallen.
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 gebruikt tegen Ticketmaster en British Airways, onder anderen.
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 een heel arsenaal aan andere verdedigingsprocessen. Helaas legt e-skimming informatie vast vóór/tijdens het indienen van de betaling. De schadelijke code luistert mee op toetsaanslagen terwijl de gebruiker de informatie invoert.
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. Een voorzorgsmaatregel is ervoor zorgen 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 browserbeveiliging: 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 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 webbeveiliging heeft 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.
