PCI SSC werkt SAQ A bij voor PCI DSS 4.0.1 – wat u moet weten
Op 30 januari 2025 publiceerde de PCI SSC (Payment Card Industry Security Standards Council) een update van de Self-Assessment Questionnaire A (SAQ A) voor PCI DSS (Payment Card Industry Data Security Standard) v4.0.1.
De verklaring stelt dat naar aanleiding van feedback van belanghebbenden vereisten 6.4.3 en 11.6.1 niet langer van toepassing zijn op de SAQ A. In plaats daarvan moeten merchants die in aanmerking willen komen voor SAQ A:
"bevestigen dat hun site niet vatbaar is voor aanvallen van scripts die de e-commercesystemen van de merchant kunnen beïnvloeden."
Deze vragenlijst is van toepassing op merchants die de betalingsverwerking volledig uitbesteden aan externe aanbieders en zelf geen betalingsgegevens verwerken of opslaan.
De introductie van de nieuwe zelfverklaringsvereiste heeft echter zorgen gewekt, omdat veel bedrijven niet over de expertise beschikken om hun blootstelling aan client-side aanvallen nauwkeurig te beoordelen. Deze wijzigingen creëren nieuwe complianceproblemen, met name rondom client-side beveiligingsrisico's, waardoor merchants onzeker zijn over hun geschiktheid en verantwoordelijkheden onder SAQ A.
Als client-side beveiligingsbedrijf helpen wij klanten te voldoen aan beide vereisten. In dit artikel willen we de implicaties van de update verduidelijken.
Nieuwe verantwoordelijkheden voor SAQ A-merchants
De PCI SSC heeft deze Self-Assessment Questionnaires (SAQ's) ontwikkeld om de complianceverplichtingen van merchants te beoordelen. Merchants zijn zelf verantwoordelijk voor het evalueren of zij voldoen aan de vereisten in de vragenlijst.
SAQ A is ontworpen voor de minst kwetsbare merchants en ontheft hen van bepaalde PCI DSS-vereisten, omdat zij geen kaarthoudergegevens (CHD) opslaan.
Met deze herziening zijn vereisten 6.4.3 en 11.6.1 niet langer van toepassing op SAQ A-merchants.
Toch geldt er een nieuwe vereiste: merchants moeten zelf verklaren dat "hun site niet vatbaar is voor aanvallen van scripts die de e-commercesystemen van de merchant kunnen beïnvloeden".
Veel merchants beschikken echter niet over de technische expertise om nauwkeurig te beoordelen of zij vatbaar zijn voor client-side aanvallen.
Omdat 98,9% van alle websites momenteel gebruikmaakt van client-side JavaScript, kan deze nieuwe vereiste ertoe leiden dat veel merchants niet langer in aanmerking komen voor SAQ A.
Behoefte aan meer duidelijkheid
De PCI SSC biedt een reeks Self-Assessment Questionnaires aan. Het document "SAQ Instructions and Guidelines" is echter nog niet bijgewerkt om deze wijzigingen te verwerken.
Gezien de aanzienlijke verandering in reikwijdte zijn wij van mening dat een update noodzakelijk is om merchants volledig inzicht te geven in hun complianceverplichtingen.
Wat is een SAQ A en hoe kunt u deze aanvragen
Zoals de PCI SSC het omschrijft:
"SAQ A-merchants kunnen zowel e-commerce- als mail/telefoonorder-merchants zijn (card-not-present), en slaan geen kaarthoudergegevens op, verwerken of verzenden deze niet in elektronisch formaat op hun systemen of locaties."
De bijgewerkte geschiktheidscriteria voor SAQ A zijn gewijzigd naar: "merchants waarbij accountdatafuncties volledig zijn uitbesteed aan PCI DSS-gevalideerde en -conforme derde partijen, waarbij de merchant uitsluitend papieren rapporten of bonnen met accountgegevens bewaart."
En nu vereist ook dat de merchant: "moet bevestigen dat hun site niet vatbaar is voor aanvallen van scripts die de e-commercesystemen van de merchant kunnen beïnvloeden."
Als een merchant gebruikmaakt van de webpagina van een externe aanbieder voor betalingsverwerking, hebben merchants geen controle over of er een client-side scriptaanval plaatsvindt op de betaalpagina van de derde partij. Monitoring is de verantwoordelijkheid van de betalingsverwerker.
Wat de tweede groep betreft, zijn de uitspraken over iframes vaag en scheppen ze een onjuist beeld. Bij gebruik van een iframe is het vrijwel onmogelijk het risico van client-side aanvallen volledig uit te sluiten.
Om te bevestigen dat de site van een merchant niet vatbaar is voor client-side aanvallen, bekijken we wanneer client-side aanvallen plaatsvinden en wat als een client-side aanval wordt beschouwd.
De PCI SSC-documentatie is gestopt met het gebruik van de term "skimming" omdat deze vaag en voor interpretatie vatbaar is. In plaats daarvan wordt de meer technische term 'client-side aanvallen' of 'aanvallen van scripts' gehanteerd.
Wij definiëren 'client-side aanvallen' of 'aanvallen van scripts' als elke methode die een kwaadwillende gebruikt om de betaalkaartgegevens van een gebruiker rechtstreeks vanuit diens browser te onderscheppen.
Hoe client-side aanvallen plaatsvinden
Er zijn 3 categorieën digitale betaalpagina's:
- Redirect-betaalpagina's: bij het afrekenen wordt een bezoeker doorgestuurd naar het aparte domein van een betalingsaanbieder om hun betaalkaartgegevens in te voeren. Zodra de transactie is voltooid, worden ze teruggestuurd naar de site van de merchant.
- Een ingesloten betaalformulier: betalingsgegevens worden verzameld via een iframe of widget, waarbij een 'minibrowser' van een derde partij in de website van de merchant is ingebed om het formulier van de betalingsaanbieder weer te geven.
- Een door de merchant ontworpen en beheerd formulier: het betaalformulier is ontworpen en wordt beheerd door de merchant en stuurt de betalingsgegevens via een API naar de betalingsverwerker.
Elke categorie heeft zijn eigen beveiligingsimplicaties, en inzicht in waar en welke client-side risico's van toepassing zijn, is essentieel voor compliance.
Beveiligingsrisico's voor redirect-pagina's
Redirect-pagina's lijken misschien veilig, maar merchants hebben geen controle over de betaalpagina. Als er een kwaadaardig script wordt geïnjecteerd, kunnen aanvallers het omleidingsproces kapen en klanten naar een frauduleuze betaalpagina sturen die er identiek uitziet als de echte, waarbij hun betalingsgegevens worden gestolen. Zelfs bij gebruik van een vertrouwde externe aanbieder voor de betaling blijven client-side risico's bestaan. Kwaadaardige scripts kunnen klikfuncties aanpassen en zo de afrekenflow onopgemerkt wijzigen. Het gebruik van een externe betalingsaanbieder elimineert het risico op client-side aanvallen niet; het stelt de sites van merchants bloot aan een iets andere uitvoering van aanvallen.
Aanvalsdemo: hoe een betaalpagina kan worden gemanipuleerd
Stel dat u online winkelt en op de knop 'Nu betalen' hieronder klikt.
.pay-button:active { background-color: #166534; }
Nu betalenZou u bij het zien van die pagina iets verdachts opmerken?
Deze pagina kostte 5 minuten om te maken. Hoewel u op die demopagina geen echte betalingsgegevens kunt invoeren, zou ik met nog twee minuten werk alle gegevens die u in dat betaalveld invoert kunnen onderscheppen en gebruiken om de daadwerkelijke merchant te betalen. Dat betekent dat u uw orderbevestiging zou ontvangen en alles zoals verwacht zou verlopen, terwijl tegelijkertijd de creditcardgegevens worden gestolen.
Aanvallers kunnen zelfs dynamisch het logo van de merchant invoegen, waardoor de neppagina er identiek uitziet als de originele site. En om de aanval nog onopvallender te maken, kunnen ze slechts een bepaald percentage van de eindklanten omleiden, op een bepaald tijdstip of in bepaalde delen van de wereld, of zelfs de IP-adressen van de merchant vermijden, zodat de aanval lange tijd onder de radar kan blijven.
Door de knopdruk te kapen die de gebruiker naar de betaalpagina omleidt, had de betalingsverwerker de aanval niet kunnen voorkomen. De merchant was in dit voorbeeld de enige partij die actie had kunnen ondernemen om de aanval te voorkomen.
Beveiligingsrisico's voor ingesloten betaalformulieren
Als uw bedrijf onder categorie 2 valt, wat betekent dat u een iframe in uw website insluit om het formulier van een externe betalingsaanbieder weer te geven, blijft uw afrekenproces kwetsbaar voor client-side aanvallen.
Een kwaadaardig script kan de kaarthoudergegevens op verschillende manieren eenvoudig onderscheppen:
- Een ander iframe renderen bovenop het iframe van de daadwerkelijke betalingsaanbieder.
- Het echte iframe verbergen en vervangen door een nep-invoerveld.
- En diverse andere aanvalsmethoden om gevoelige informatie onopgemerkt te onderscheppen.
Elk kwaadaardig JavaScript op de website van een merchant heeft vrij spel over de pagina en kan deze aanvallen uitvoeren. De enige manier om dit risico volledig te elimineren, is alle JavaScript van de afrekenpagina te verwijderen of zeer strikte CSP-headers en SRI-directives te implementeren — wat zelden haalbaar is, omdat de meeste betalingsaanbieders (en veelgebruikte kritieke tools zoals chatbots, websiteanalytics, foutrapportage, enz.) dynamisch client-side JavaScript nodig hebben om correct te functioneren.
Het handhaven van deze maatregelen terwijl tegelijkertijd een goede productiefunctionaliteit wordt gewaarborgd, is een aanzienlijke uitdaging, met name bij gebruik van frameworks en platforms zoals React, Vue, Magento, Drupal, WooCommerce, enz. Dit beveiligingsniveau handmatig bereiken zonder aanschaf van een dedicated oplossing is vrijwel onmogelijk zonder enorme inspanning met ingrijpende gevolgen.
Beveiligingsrisico's voor door merchants ontworpen en beheerde formulieren
Als uw bedrijf onder categorie 3 valt, waarbij u uw eigen betaalcomponent heeft gebouwd, is uw afrekenproces nog kwetsbaarder. Deze door merchants beheerde betaalformulieren kennen dezelfde kaaprisico's als ingesloten iframes — en meer — omdat andere scripts die op de site draaien betalingsgegevens kunnen keyloggen.
En hoe worden client-side aanvallen geïnjecteerd?
Moderne webframeworks
Moderne single-page webapplicatieframeworks, zoals React, zijn de standaard geworden. Deze frameworks genereren "single-page webapps" omdat ze vertrouwen op client-side JavaScript om de webpagina dynamisch bij te werken, wat zorgt voor sneller laden en naadloze navigatie tussen pagina's.
Het hele punt van deze frameworks is echter dat ze de pagina niet herladen. Als gevolg hiervan kunnen scripts die aan een specifiek deel van de site zijn toegevoegd op elke pagina worden uitgevoerd, tenzij een harde verversing wordt geactiveerd vóór het navigeren. Dit introduceert beveiligingsrisico's, omdat kwaadaardige scripts actief kunnen blijven wanneer de gebruiker navigeert naar pagina's waarvoor die scripts niet bedoeld waren.
Als gevolg hiervan wordt de oorspronkelijke focus van de specificatie op "scripts op de betaalpagina" ineffectief voor single-page applicaties, de populairste benadering van webontwikkeling gedurende vele jaren.
Bovendien zijn moderne stack-ontwikkelaars afhankelijk van open source-afhankelijkheden van NPM. Dat is volkomen logisch, omdat websites vergelijkbare functies uitvoeren en alles opnieuw schrijven van scratch zoiets zou zijn als het wiel opnieuw uitvinden. Het gebruik van kant-en-klare bibliotheken versnelt webontwikkeling aanzienlijk.
Wat velen niet beseffen, is dat NPM-scripts eenvoudig client-side opgehaalde payloads kunnen injecteren. Beveiligingstools die zich richten op NPM supply chain-bedreigingen hebben moeite om deze injecties effectief te detecteren omdat ze geen inzicht hebben in client-side activiteit, zeker niet 100% van de tijd en in real-time.
Dit uitstekende virale Medium-artikel uit 2018 verduidelijkt deze methode op een tamelijk vermakelijke manier.
Tools van derden
Een andere veelgebruikte injectiemethode is het kapen van een script/tool van een derde partij dat aan de website is toegevoegd. Dit kunnen tools zijn voor analysedoeleinden, advertenties, AB-testtools, widgets, social media-trackingscripts… Deze scripts hebben vaak een afhankelijkheidsboom met veel ingebedde open source-tools.
De polyfill-aanval van juni 2024 was een groot voorbeeld van deze aanvalsmethode die in het wild werd gebruikt. Het is echt niet zo moeilijk uit te voeren. Aanvallers kunnen een S3-bucket kapen, een verlopen domein overnemen dat in websites is ingebed, een verlaten S3-URL claimen of deelnemen aan een open source-project en stilletjes een afhankelijkheid van een derde partij injecteren… de mogelijkheden zijn eindeloos.
Injecties via legacy-platforms
Zelfs als u een legacy-platform gebruikt, vaak gebaseerd op PHP, is het in de loop der tijd bewezen dat deze zeer vatbaar zijn voor client-side injecties via veelvoorkomende CVE's.
De naam "Magecart", een verouderde term voor client-side aanvallen, is ontstaan uit client-side injecties in Magento om kaarthoudergegevens te exfiltreren. Toch reikt deze dreiging verder dan Magento. In januari 2025 alleen al hebben we meer dan 15.000 websites gedetecteerd die zijn getroffen door nieuwe WordPress client-side aanvallen, wat het groeiende risico op alle platforms benadrukt.
In deze context is het belangrijk te erkennen dat JavaScript als client-side programmeertaal wordt gebruikt door 98,9% van alle websites, waardoor het een belangrijk doelwit is voor misbruik.
Zonder client-side beveiliging is er dan ook geen manier om een aanval met zekerheid uit te sluiten of immuniteit daarvoor te claimen.
Real-time client-side monitoring voor websitebeveiliging
De meest effectieve manier om uw website te beveiligen en PCI DSS-compliance te handhaven, is door de volledige client-side te monitoren met een actieve, real-time monitoringtool. Deze aanpak gaat verder dan traditionele methoden zoals een eenmalige crawler, handmatige scriptbeoordeling op een betaalpagina of het controleren van de front-end code op bekende kwaadaardige URL's.
Alleen door continue monitoring kunt u met vertrouwen verklaren dat uw "site niet vatbaar is voor aanvallen van scripts die de e-commercesystemen van de merchant kunnen beïnvloeden".
Client-side scripts zijn dynamisch en kunnen conditioneel worden gerenderd. Een kwaadwillende kan een kwaadaardige payload injecteren die onder specifieke omstandigheden wordt geactiveerd, zoals slechts 1% van de tijd, op een specifiek tijdstip of alleen voor klanten in een bepaalde regio.
Vanwege deze ontwijkende en heimelijke technieken is een op scanners gebaseerde aanpak verre van ideaal voor deze vector, omdat er te veel blinde vlekken overblijven… maar in sommige gevallen is het het enige wat u kunt doen, dus bieden wij er een aan als noodoplossing.
Komt u in aanmerking voor SAQ A – diagram
Op basis van onze interpretatie zou de onderstaande vragenlijst u moeten helpen begrijpen of u in aanmerking komt voor SAQ A:
De vage bewoordingen laten echter ruimte voor interpretatie, waardoor het moeilijk is om duidelijke compliance vast te stellen. Door het gebrek aan duidelijkheid vermoeden wij dat het met zekerheid in aanmerking komen voor SAQ A een uitdaging is, zeker gezien hoe dicht deze wijzigingen bij de compliancedeadline van 31 maart 2025 liggen.
In de praktijk zullen de meeste merchants moeite hebben om met vertrouwen "ja" te antwoorden op de vraag:
"De merchant heeft bevestigd dat hun site niet vatbaar is voor aanvallen van scripts die de e-commercesystemen van de merchant kunnen beïnvloeden."
Een mogelijke uitkomst is dat sommige merchants haastig overstappen op een betaalpagina-opzet van een derde partij, in de veronderstelling dat dit de beveiliging verbetert en hen in aanmerking laat komen voor SAQ A. Toch elimineert dit het risico op creditcarddiefstal niet als de scripts van hun website zijn gecompromitteerd, zoals uitgelegd met de methode van knopkaping.
Een andere waarschijnlijke uitkomst is dat bedrijven simpelweg de SAQ A aanvragen, toch vertrouwen op zelfbeoordeling en hopen op het beste zonder de risico's aan te pakken.
Toenemende risico's van client-side aanvallen
Gezien het huidige aanvalslandschap en de toenemende complexiteit van moderne browsers staan bedrijven op een cruciaal punt.
Als cyberbeveiligingsbedrijf zullen wij altijd pleiten voor de veiligste aanpak, een aanpak die zowel klanten als bedrijven actief beschermt.
Client-side aanvallen nemen toe. Meer dan 600.000 websites werden in 2024 getroffen en in januari 2025 alleen al hebben we meer dan 15.000 nieuw getroffen websites gedetecteerd.
Uw verantwoordelijkheid: continue monitoring
De beste manier om PCI DSS-compliance te waarborgen, is uw volledige client-side omgeving in real-time te monitoren. Het is uw verantwoordelijkheid om deze bedreigingen voor te blijven en uw klanten te beschermen.
Voor verduidelijking of vragen, neem vandaag nog contact met ons op.
