Kort samengevat: geschiktheid voor scriptattestatie SAQ A van januari 2025
- De attestatievalstrik: Het verwijderen van 6.4.3 en 11.6.1 uit SAQ A heeft het leven niet makkelijker gemaakt. Het verving ze door een zelfattestatie dat "uw site niet vatbaar is voor aanvallen via scripts", en de meeste merchants missen de technische expertise om nauwkeurig te beoordelen of ze vatbaar zijn voor client-side aanvallen.
- Omvang van de aanvallen: JavaScript wordt gebruikt door 98,9% van alle websites, en in januari 2025 detecteerde cside meer dan 15.000 nieuw getroffen websites in één maand, met meer dan 600.000 getroffen sites in 2024. Scannergebaseerde controles missen heimelijke aanvallen die maar 1% van de tijd of in slechts één regio worden geactiveerd.
- De ja verdedigen: Als u vertrouwt op een redirect of een iframe en denkt dat u veilig bent: button-hijacks en overlappende nepformulieren werken nog steeds. Als u de attestatie met zekerheid wilt beantwoorden, is continue client-side monitoring zoals cside de enige manier om die "ja" te verdedigen.
Weinig tijd? Bekijk cside PCI Shield. Dit dekt alles hieronder in één deployment.
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 nu zijn verwijderd uit SAQ A. In plaats daarvan moeten merchants bevestigen:
"moeten 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 nieuwe zelfattestatievereiste heeft echter zorgen gewekt, omdat veel bedrijven niet over de expertise beschikken om hun blootstelling aan client-side aanvallen nauwkeurig te beoordelen. Deze wijzigingen brengen nieuwe complianceuitdagingen met zich mee rondom client-side beveiligingsrisico's, waardoor merchants onzeker blijven over hun geschiktheid en verantwoordelijkheden onder SAQ A.
Als client-side beveiligingsbedrijf helpen wij klanten om aan beide vereisten te voldoen, en in dit artikel leggen we uit wat de update in de praktijk betekent.
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 ze voldoen aan de vereisten die in de vragenlijst zijn beschreven.
SAQ A is ontworpen voor de minst kwetsbare merchants en ontheft hen van bepaalde PCI DSS-vereisten, aangezien zij geen kaarthoudergegevens (Card Holder Data, 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 voor SAQ A: 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 ze vatbaar zijn voor client-side aanvallen.
Aangezien 98,9% van de websites momenteel client-side JavaScript gebruikt, kan deze nieuwe vereiste ervoor zorgen 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. Toch is het document "SAQ Instructions and Guidelines" nog niet bijgewerkt om deze wijzigingen te verwerken.
Gezien de aanzienlijke verandering in reikwijdte zijn wij van mening dat een update noodzakelijk is om ervoor te zorgen dat merchants hun complianceverplichtingen volledig begrijpen.
Wat is een SAQ A en hoe kunt u deze aanvragen
Zoals de PCI SSC het verwoordt:
"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."
Let op dat de bijgewerkte geschiktheidscriteria voor SAQ A zijn gewijzigd naar: "merchants waarvan de accountdatafuncties volledig zijn uitbesteed aan PCI DSS-gevalideerde en -conforme derde partijen, waarbij de merchant uitsluitend papieren rapporten of bonnen met accountgegevens bewaart."
En vereist nu ook van 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 om betalingen te verwerken, heeft de merchant 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 om het risico op client-side aanvallen volledig uit te sluiten.
Om te kunnen 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, en gebruikt in plaats daarvan de meer technische term 'client-side aanvallen' of 'aanvallen van scripts'.
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 zijn betaalkaartgegevens in te voeren. Zodra de transactie is voltooid, wordt de bezoeker 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 wordt ingebed in de website van de merchant 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 tegelijkertijd 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 juist 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 denken dat er iets niet klopte?
Deze pagina kostte 5 minuten om te maken. Hoewel u op deze demopagina geen echte betaalgegevens kunt invoeren, zou ik met nog twee minuten extra 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 zou verlopen zoals verwacht, 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. Om de aanval nog onopvallender te maken, kunnen ze slechts een bepaald percentage van de bezoekers omleiden, dit beperken tot bepaalde tijdstippen of regio's, of de eigen 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:
- Door een ander iframe bovenop het echte iframe van de betalingsaanbieder te renderen.
- Door het echte iframe te verbergen en te vervangen door een nep-invoerveld.
Andere technieken kunnen gevoelige informatie net zo onopgemerkt onderscheppen.
Gerelateerde leesstof: onze compliance-gids voor PCI DSS 6.4.3 en 11.6.1 · hoe u voldoet aan PCI DSS 6.4.3
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 de productieomgeving goed blijft functioneren, is een aanzienlijke uitdaging, vooral bij frameworks en platforms zoals React, Vue, Magento, Drupal en WooCommerce. Dit beveiligingsniveau handmatig bereiken, zonder een dedicated oplossing, is vrijwel onmogelijk zonder enorme, fragiele inspanning.
Beveiligingsrisico's voor door merchants ontworpen en beheerde formulieren
Als uw bedrijf onder categorie 3 valt, waarbij u uw eigen betaalcomponent hebt 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 webapp-frameworks, 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. Hierdoor kunnen scripts die aan een specifiek deel van de site zijn toegevoegd op elke pagina worden uitgevoerd, tenzij er een harde verversing wordt geactiveerd vóór het navigeren. Dit brengt beveiligingsrisico's met zich mee, 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, al jarenlang de populairste benadering van webontwikkeling.
Bovendien vertrouwen moderne stack-ontwikkelaars op open source-afhankelijkheden van NPM. Dat is volkomen logisch, aangezien websites vergelijkbare functies uitvoeren en alles opnieuw vanaf nul schrijven neerkomt op het opnieuw uitvinden van het wiel. Het gebruik van kant-en-klare bibliotheken versnelt webontwikkeling aanzienlijk.
NPM-scripts kunnen eenvoudig client-side opgehaalde payloads injecteren. Beveiligingstools die zich richten op NPM-supplychainbedreigingen hebben moeite om deze injecties effectief te detecteren, omdat ze geen inzicht hebben in client-side activiteit, zeker niet in real-time en 24/7.
Dit virale Medium-artikel uit 2018 legt deze methode op een vermakelijke manier uit.
Tools van derden
Een andere veelgebruikte injectiemethode is het kapen van een script of tool van een derde partij dat aan de website is toegevoegd. Dit kunnen tools zijn voor analytics, advertenties, AB-testen, widgets of 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 toegepast. Het is echt niet zo moeilijk om 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 legacyplatforms
Zelfs als u een legacy, vaak op PHP gebaseerd e-commerceplatform gebruikt, is 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 die werden gebruikt om kaarthoudergegevens te stelen. De dreiging reikt nu verder dan Magento: alleen al in januari 2025 detecteerden we meer dan 15.000 WordPress-websites die getroffen waren door nieuwe client-side aanvallen.
JavaScript wordt als client-side programmeertaal gebruikt op 98,9% van alle websites, wat het een uitgelezen doelwit maakt voor misbruik.
Zonder client-side beveiliging is er daarom geen manier om een aanval met zekerheid uit te sluiten of immuniteit ervoor te claimen.
Real-time client-side monitoring voor websitebeveiliging
De meest effectieve manier om uw website te beveiligen en PCI DSS-compliance te behouden, is door de volledige client-side omgeving te monitoren met een actieve real-time tool. Deze aanpak gaat verder dan traditionele methoden zoals eenmalige crawlers, handmatige scriptbeoordelingen van 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, bijvoorbeeld 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. In sommige gevallen is het echter het enige wat u kunt doen, dus bieden wij er een aan als laatste redmiddel.
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:
Toch laat de vage bewoording ruimte voor interpretatie, waardoor het lastig is om duidelijke compliance vast te stellen. Door dat gebrek aan duidelijkheid vermoeden wij dat 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 zouden 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."
Eén mogelijke uitkomst is dat sommige merchants haastig overstappen op een betaalpagina-opzet van een externe 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 bij de methode van knop-hijacking.
Een andere waarschijnlijke uitkomst is dat bedrijven simpelweg SAQ A aanvragen, toch vertrouwend op zelfbeoordeling, en hopen op het beste zonder de risico's aan te pakken.
Toenemende risico's van client-side aanvallen
Client-side aanvallen nemen toe, gelijk opgaand met de groeiende complexiteit van moderne browsers.
Als client-side beveiligingsbedrijf raden wij de meest beschermende aanpak aan die beschikbaar is, een aanpak die zowel klanten als merchants beschermt.
Client-side aanvallen nemen toe. Meer dan 600.000 websites werden in 2024 getroffen, en alleen al in januari 2025 detecteerden we meer dan 15.000 nieuw getroffen websites.
Uw verantwoordelijkheid: continue monitoring
De beste manier om PCI DSS-compliance te waarborgen, is door 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 verduidelijkingen of vragen kunt u vandaag nog contact met ons opnemen.
