Wat is formjacking? Hoe de aanval werkt en hoe je hem stopt

Kort samengevat: wat is formjacking

• JavaScript geïnjecteerd op een formulier om te stelen wat gebruikers typen voor submit. Kaartvelden, credentials of PII.
• Het draait in de browser nadat de pagina is geserveerd. Je WAF en origin-logs zien niets. Het gecompromitteerde script zit binnen een vertrouwd toegestaan domein.
• Compliance-pad: 6.4.3-scriptinventaris en 11.6.1-tamperdetectie. Technisch pad: in-sessie-monitoring.

Hoe formjacking werkt

Een formjacking-aanval verloopt in vier stappen.

Het diagram volgt één afrekening (shop.example[.]com/checkout) over vijf fasen, en laat zien waarom een weergave op netwerkniveau blind blijft terwijl een weergave op browserniveau het wel opmerkt:

De netwerklaag is blind omdat het exfiltratieverzoek de browser rechtstreeks naar het domein van de aanvaller verlaat. cside bewaakt de browserlaag, dus de geïnjecteerde listener en de uitgaande beacon worden opgemerkt waar ze daadwerkelijk draaien.

1. Code op de pagina plaatsen. De aanvaller plaatst JavaScript op de doelpagina, bijna altijd zonder medeweten van de site-eigenaar. De meest voorkomende route is het compromitteren van een script van derden, een analysetag, een chat-widget, een A/B-testingtool of een betalingsbibliotheek, zodat de skimmer verpakt aankomt in code die de site al vertrouwt en bij elke betaaltransactie laadt.

2. De formuliervelden koppelen. Zodra het script geladen is, koppelt het event-listeners aan het betaal- of inlogformulier. Een listener op het input-event wordt geactiveerd bij elke toetsaanslag; een op het submit-event wordt geactiveerd wanneer de gebruiker op betalen klikt. Het script kan ook direct waarden lezen uit de DOM nadat de velden zijn ingevuld.

3. De gegevens kopiëren. De listener vangt de veldwaarden op, kaartnummer, vervaldatum, CVV, factuuradres, precies zoals de gebruiker ze heeft ingevoerd. Het formulier zelf wordt niet aangepast. De transactie van de gebruiker gaat nog steeds via de legitieme betalingsverwerker.

4. Exfiltreren. De gestolen gegevens worden gecodeerd en verstuurd naar een door de aanvaller gecontroleerd domein, vaak vermomd als een analyseping of een afbeeldingsverzoek om op te gaan in het normale uitgaande verkeer van de pagina. De meeste Content Security Policy-headers blokkeren dit niet, omdat de aanvaller ofwel een domein gebruikt dat de policy al toestaat of een bestaande hiaat benut.

Hoe aanvallers formjacking-code op je site krijgen

Formjacking vereist geen directe aanval op je servers. De drie meest voorkomende afleverroutes:

Compromittering van scripts van derden. De meeste betaal- en e-commercepagina's laden 20 tot 60 scripts van derden, analyseplatforms, chat-tools, tagmanagers, betalingsbibliotheken, widgets van marketingleveranciers. Elk van die leveranciers is een aanvalsoppervlak. Als de aanvaller de CDN of infrastructuur van de leverancier comprometteert, ontvangt elke site die dat script laadt de skimmer. Het British Airways-datalek in 2018 bracht de persoonsgegevens van 429.612 klanten in gevaar nadat aanvallers het JavaScript in de betaalstroom van de luchtvaartmaatschappij hadden gewijzigd. Onderzoekers koppelden de aanval aan Magecart-dreigingsactoren die een gecompromitteerd script van een externe leverancier gebruikten, niet een directe aanval op de servers van British Airways zelf. (Wikipedia: British Airways-datalek)

Verlopen of gekaapte domeinen. Sites laden soms scripts van domeinen van derden die inmiddels zijn verlopen of van eigenaar zijn gewisseld. Een aanvaller die dat domein registreert, kan vervolgens willekeurig JavaScript serveren aan elke site die nog steeds de oude scripttag laadt. Omdat de URL niet is veranderd en het domein eerder legitieme code serveerde, signaleert geen automatische controle dit onmiddellijk.

Directe code-injectie. Als de aanvaller een kwetsbaarheid exploiteert in de CMS, het beheerpaneel of een plugin van de site, kan hij het formjacking-script rechtstreeks in de eigen bestanden van de site injecteren. Deze route vereist meer toegang maar laat geen externe afhankelijkheid achter om te traceren.

Wat formjacking target

Aanvallers geven prioriteit aan pagina's die hoogwaardige gegevens verzamelen met minimale weerstand:

Betaalpagina's zijn het primaire doelwit omdat kaartgegevens een directe doorverkoopmarkt hebben. Inloggegevens zijn de tweede prioriteit omdat ze accountovername mogelijk maken op platforms met opgeslagen betaalmethoden.

Waarom traditionele beveiligingstools formjacking missen

Webapplicatiefirewalls beschermen verkeer dat je server bereikt. Formjacking-gegevens verlaten de browser rechtstreeks naar een domein van de aanvaller, de WAF ziet ze nooit.

Serverside-scanners inspecteren code die op je origin in rust ligt. Een gecompromitteerd script van derden laadt tijdens runtime van de CDN van een leverancier, waardoor het nooit op je server staat om gescand te worden.

Periodieke handmatige reviews controleren de scripts die staan vermeld in je tagmanager of coderepository. Een skimmer die tussen reviewcycli in een script van derden is geïnjecteerd, is onzichtbaar totdat iemand de volgende audit uitvoert, vaak weken later.

Subresource Integrity (SRI) beschermt scripts waarvoor je bij implementatie een hash berekent. Het kan scripts niet beschermen die worden geladen van door leveranciers gecontroleerde CDNs waar de aanvaller schrijftoegang heeft, of scripts die dynamisch worden gegenereerd per verzoek.

PCI DSS 4.0.1-vereisten 6.4.3 en 11.6.1 bestaan omdat de sector dit gat herkende. Scriptinventarisatie en continue manipulatiemonitoring op betaalpagina's werden op 1 april 2025 verplicht, niet optioneel best practice. (PCI Security Standards Council)

Skimmers ontwijken ook actief scanners. De meeste controleren navigator.webdriver, dat true retourneert in geautomatiseerde headless browsers, en serveren schone code aan beveiligingstools terwijl ze de volledige skimmer draaien voor echte gebruikers.

Hoe formjacking te detecteren

Formjacking detecteren vereist zicht op wat JavaScript doet tijdens runtime in de browsers van echte bezoekers. De specifieke signalen om te monitoren:

• Nieuwe of gewijzigde scripts op gevoelige pagina's. Een script dat de dag ervoor niet aanwezig was, of waarvan de inhoud buiten een gepland implementatievenster is gewijzigd, is de eerste indicator.
• Onverwachte event-listeners op formuliervelden. Legitieme code koppelt submit-listeners om formulieren te verwerken. Een listener op input-, keydown- of keyup-events op betaal- of inlogvelden, toegevoegd door een script van derden, is een formjacking-kenmerk.
• Uitgaande gegevens naar niet-vermelde domeinen. Elk netwerkverzoek van een betaalpagina naar een domein dat niet op je goedgekeurde toegestane lijst staat, vereist onmiddellijk onderzoek.
• Gecodeerde payloads in uitgaande verzoeken. Formjackers coderen gestolen gegevens, vaak in base64, voordat ze ze verzenden. Een beacon met een ongebruikelijk lange gecodeerde parameter die niet overeenkomt met een bekend analysegebeurtenis is een alarmsignaal.

De sleutellimiet is dat alleen monitoring binnen de browser deze signalen in realiteit kan zien. Scanners die van buitenaf opereren, missen formjacking dat zichzelf verbergt voor echte gebruikers.

Hoe formjacking te voorkomen

Geen enkele maatregel elimineert alle formjacking-routes. Het combineren van meerdere maatregelen verkleint het aanvalsoppervlak aanzienlijk:

1. Inventariseer elk script op gevoelige pagina's. Ken elk eigen en extern script dat laadt op betaal- en inlogpagina's, wie het heeft geautoriseerd en waarom het er is. Niet-herkende scripts mogen niet laden.

2. Monitor wijzigingen continu. Een script dat verandert tussen auditcycli is een ongedetecteerd datalek. Continue manipulatiemonitoring, verplicht onder PCI DSS 4.0.1-vereiste 11.6.1, detecteert wijzigingen binnen minuten in plaats van weken.

3. Pas SRI toe waar praktisch. Voor scripts die je volledig beheert en zelf versiebeheert, controleren SRI-hashes of het script niet is gewijzigd sinds de implementatie. SRI werkt niet voor regelmatig bijgewerkte scripts van derden of scripts die dynamisch per verzoek worden gegenereerd.

4. Stel je Content Security Policy strikt in. Een strikte CSP beperkt naar welke domeinen scripts gegevens kunnen sturen, waardoor het aantal exfiltratiemogelijkheden van een skimmer wordt verminderd. In de praktijk moeten betaalpagina's vaak veel domeinen toestaan voor legitieme analyses en betalingsfunctionaliteit, wat een volledige blokkering moeilijk maakt.

5. Implementeer client-side monitoring van echte bezoekers. De meest directe verdediging is monitoring die observeert wat elk script doet in echte browsers, niet een scanner die synthetische verzoeken uitvoert van buitenaf. Dit is de aanpak van cside.

Hoe cside formjacking detecteert in echte browsers

cside wordt ingezet als één eigen JavaScript-snippet dat scriptgedrag bewaakt in de browsers van echte bezoekers, geen crawler of scanner die van buitenaf opereert.

Voor formjacking detecteert cside:

• Event-listeners die zijn gekoppeld aan formuliervelden door scripts van derden, met bijzondere aandacht voor listeners die worden geactiveerd bij toetsaanslagen in plaats van bij het verzenden van het formulier
• Uitgaande gegevensverzoeken naar domeinen die niet op de goedgekeurde toegestane lijst van de site staan
• Nieuwe scripts die verschijnen op betaal- of inlogpagina's buiten een implementatievenster
• Wijzigingen in bestaande scripts, inclusief runtime-wijzigingen in de geladen output van een leverancierstag

Omdat cside opereert op de browserlaag naast de aanval, vangt het de skimmer op het moment dat hij wordt geactiveerd, voordat gegevens al zijn geëxfiltreerd. Voor organisaties die onder PCI DSS 4.0.1 vallen, koppelt PCI Shield deze monitoring aan vereisten 6.4.3 (scriptinventarisatie en -autorisatie) en 11.6.1 (manipulatiedetectie), en genereert continu QSA-klare rapporten.

Voor context over hoe formjacking zich verhoudt tot het bredere digitale skimming-ecosysteem en Magecart-dreigingsgroepen, zie de begeleidende gids: Formjacking vs Magecart vs digitaal skimmen.

Boek een demo om te zien wat cside vindt op je betaalpagina's, of lees meer over e-skimming-preventie.

Gerelateerd lezen

• How Polyfill.io hit 490k websites (browser supply-chain attack)
• Magecart attacks explained: how web skimming works
• Online credit card skimming