PCI DSS Qualified Security Assessors staan al voor de enorme taak om beveiligingsexperts te zijn op meer dan 397 pagina's dichte inhoud. Wat het er niet makkelijker op maakt: veel merchants haasten zich om de goedkoopste oplossing te vinden die hen door de beoordeling heen helpt. Ze rekken de grenzen op van wat de minimaal aanvaardbare aanpak is. Hoewel dergelijke oplossingen op het eerste gezicht alle vakjes lijken aan te vinken, laten veel ervan Kaarthouders schaamteloos blootgesteld aan client-side aanvallen. In sommige gevallen bewegen deze oplossingen zich in het grijze gebied van vage bewoordingen, maar voldoen ze feitelijk niet aan de compliance-normen.
Deze gids helpt QSA's om deze rode vlaggen te herkennen. We hebben dit geschreven op basis van onze eigen ervaring met assessors en de technische evaluaties die we hebben uitgevoerd tijdens de ontwikkeling van een PCI-oplossing voor onze klanten.
Een beknopte checklist voor QSA's:
Om te voldoen aan de vereisten van 6.4.3 en 11.6.1 moet een merchant kunnen aantonen (intern gebouwd of via een leverancier):
- Een mechanisme om de scripts op de pagina te beheren en de mogelijkheid om ze te blokkeren. CSP, SRI of een client-side script kunnen dit bewerkstelligen. Een crawler alleen echter niet.
- De scriptinhoud kan worden gecontroleerd op indicatoren van kwaadaardige intentie. Hiervoor moet de oplossing de scriptinhoud kunnen tonen. Geen mogelijkheid om de scriptinhoud te tonen = geen mogelijkheid om de scriptintegriteit te verifiëren. Geen bewijs = geen compliance.
- Een inventaris van alle scripts (inline, first-party, third-party en afhankelijkheden van de scripts) moet worden bijgehouden met een technische of zakelijke rechtvaardiging.
- Beveiligingsheaders van betaalpagina's moeten minimaal wekelijks worden gemonitord en weergegeven.
- Er is een mechanisme aanwezig dat waarschuwt bij het verwijderen van client-side beveiligingsmaatregelen.
- Scriptinhoud moet actief worden gemonitord en bij wijzigingen moeten er meldingen worden verstuurd.
De oplossing van een merchant zou falen als deze:
- Geen client-side script of CSP of SRI heeft dat scripts kan blokkeren van laden (voldoet niet aan 6.4.3)
- Puur een crawler is zonder enige aanpassing van code op de pagina (voldoet niet aan 6.4.3)
- Alleen script-URL's controleert maar de scriptinhoud niet monitort (voldoet niet aan 11.6.1)
- Geen meldingen verstuurt wanneer beveiligingsheaders worden verwijderd of gewijzigd (voldoet niet aan 11.6.1)
- Beveiligingsheaders niet minimaal wekelijks bijhoudt en weergeeft (voldoet niet aan 11.6.1)
Waarom deze vereisten bestaan:
Vereisten 6.4.3 en 11.6.1 hebben betrekking op client-side aanvallen. Aanvallen die worden uitgevoerd in de applicatieomgeving op het apparaat van de gebruiker, maar die plaatsvinden als gevolg van uw afhankelijkheden als merchant. Dit toepassingsgebied is toegevoegd in PCI DSS v4. Kaartuitgevers hebben aangegeven dat een aanzienlijk deel van de diefstal van Kaarthoudergegevens (CHD) client-side plaatsvindt, buiten het zichtbereik van andere beveiligingsmaatregelen. Een Web Application Firewall heeft geen invloed op client-side uitvoeringen, met name niet die van third parties. Daarom was deze uitbreiding van het toepassingsgebied noodzakelijk. Veel andere compliance-frameworks volgen dit voorbeeld door vereisten met betrekking tot supply-chain security uit te breiden naar client-side uitvoeringen.
Zijn PCI-vereisten van toepassing op Single-page Applications (SPA's)?
De PCI DSS-specificatie maakt geen onderscheid tussen single-page webapplicatietechnologieën en server-side gerenderde webapplicaties. Dit kan verwarring veroorzaken, omdat sommige vereisten mogelijk niet van toepassing lijken of technisch niet haalbaar zijn zonder de volledige single-page application te monitoren. De gevraagde beveiligingsmaatregelen zijn echter wel degelijk van toepassing op single-page applications. SPA's hebben in veel opzichten aanzienlijk bijgedragen aan de behoefte aan strengere beveiligingsvereisten, doordat ze de hoeveelheid code die client-side wordt uitgevoerd sterk hebben vergroot.
Zie: Wat is het verschil tussen server-side gerenderde webapplicaties en single-page applications
Toepassingsgebied van 6.4.3 & 11.6.1:
De PCI-specificatie stelt dat "Deze vereiste van toepassing is op alle scripts die worden geladen vanuit de omgeving van de entiteit en scripts die worden geladen van third en fourth parties". Elke vermelding van 'script' omvat dus scripts van dezelfde oorsprong (1st party), third parties en subrequests van die third parties.
Veel traditionele tools monitoren geen client-side scripts van dezelfde oorsprong of scripts die inline worden geïnjecteerd. Met andere woorden: deze tools monitoren geen first-party scripts of de stukjes code die rechtstreeks op de pagina worden geplaatst (bijv. analytics-tags). Dit is een probleem, omdat client-side aanvallen regelmatig zijn ontstaan via scripts van dezelfde oorsprong.
6.4.3:
De vereiste stelt:
"Alle betaalpaginascripts die worden geladen en uitgevoerd in de browser van de consument worden als volgt beheerd:"
1. "Er is een methode geïmplementeerd om te bevestigen dat elk script geautoriseerd is."
Dit betekent dat niet-geautoriseerde scripts moeten worden tegengehouden. Er zijn slechts 2 manieren om dit te doen:
- CSP of SRI's implementeren voor scripts: Zorg ervoor dat de Content Security Policies (CSP) strikt zijn en in blokkerende modus staan. CSP is van nature een mechanisme om bronnen te vertrouwen, niet de scripts zelf. Dit zijn fundamenteel verschillende dingen. Als een vertrouwde bron wordt gecompromitteerd, kunnen kwaadaardige scripts er zonder enige beveiligingsmaatregel doorheen glippen.
Subresource Integrity (SRI) werkt wel op scriptniveau en valideert de daadwerkelijke payload. SRI is echter niet altijd een praktische optie voor dynamische scripts die regelmatig veranderen aan de client-side.
- Een client-side script gebruiken: Een client-side script dat vóór alle andere scripts laadt, kan scripts aanpassen of verwijderen. Het kan voorkomen dat niet-geautoriseerde scripts gedeeltelijk of volledig worden uitgevoerd.
Als een merchant geen CSP, SRI of client-side script op een pagina heeft om te voorkomen dat niet-geautoriseerde scripts worden geladen, wordt niet voldaan aan 6.4.3.
Belangrijk: een op een crawler gebaseerde oplossing zonder CSP voldoet niet aan de PCI-vereisten. Er zijn een aantal leveranciers die crawlers aanbieden die niet aan deze vereiste voldoen.
2. "Er is een methode geïmplementeerd om de integriteit van elk script te waarborgen."
Dit betekent dat elk script moet worden gemonitord. In 11.6.1 wordt verder uitgelegd dat dit ook de scriptinhoud omvat. Een beveiligingsoplossing die voldoet aan 6.4.3 en 11.6.1 moet daarom de scriptinhoud kunnen tonen die aan de gebruiker is aangeboden.
Waar de oplossing draait is van belang: Oplossingen die extern draaien, kunnen niet garanderen dat het script dat zij hebben beoordeeld ook daadwerkelijk aan eindgebruikers wordt aangeboden. Het is bekend dat kwaadwillenden de IP-adressen van cloudproviders van crawlers identificeren en kwaadaardige scripts uitsluiten van aanbieding aan die adressen. Het is daarom onduidelijk of aan de vereiste kan worden voldaan door een oplossing die niet tijdens runtime in de applicatie aanwezig is. CSP alleen kan de scriptintegriteit niet verifiëren, omdat het de scriptinhoud niet inspecteert. SRI valideert de scriptinhoud echter wel aan de hand van een hash.
Script-URL's en Threat Feeds: Sommige oplossingen claimen compliance door script-URL's te controleren aan de hand van threat feeds, maar dat verifieert alleen de bestandsnaam en niet de inhoud. Omdat 11.6.1 specifiek vereist dat de daadwerkelijke scriptpayload wordt gemonitord, schieten deze benaderingen tekort. Het is om dezelfde reden dat antivirussoftware niet stopt bij bestandsnamen, maar ook inspecteert wat erin zit.
Als vuistregel geldt: als een oplossing de scriptinhoud niet toont, voldoet deze niet aan de vereisten voor integriteitsmonitoring.
Validatietest: Om te begrijpen of een oplossing de scriptintegriteit kan verifiëren, wordt aanbevolen een test uit te voeren door een voorbeeld van een 'kwaadaardig' script te implementeren in een stagingomgeving.
3. "Er wordt een inventaris bijgehouden van alle scripts met een schriftelijke zakelijke of technische rechtvaardiging waarom elk script noodzakelijk is."
Merchants kunnen spreadsheets of dashboards van leveranciers gebruiken om aan deze vereiste te voldoen. AI wordt vaak ingezet om de rechtvaardigingen te schrijven. Sommige oplossingen bieden dit niet standaard aan; in dat geval kan een spreadsheet worden gebruikt. Het is echter belangrijk dat deze spreadsheet up-to-date is. Een exportbestand van een Google Tag Manager-dashboard volstaat niet, omdat de applicatie zelf mogelijk client-side scripts heeft die buiten Google Tag Manager om zijn geïnjecteerd.
Verouderde of onvolledige inventarissen: Het wordt aanbevolen dat een QSA de betreffende oplossing controleert om te verifiëren dat alle scripts in de inventaris staan en dat de inventaris up-to-date is.
Een 'agent-loze aanpak' gebruiken: De PCI DSS v4-documentatie biedt richtlijnen en suggereert het gebruik van CSP, SRI of een eigen script of tag-managementsysteem dat kwaadaardige scriptuitvoering kan voorkomen. Er is geen sprake van een passief observatiemiddel zoals een scanner, crawler of agent. Aan de vereiste om te voorkomen dat een kwaadaardig script wordt geladen, kan niet worden voldaan zonder een script of CSP-header aan een webpagina toe te voegen.
11.6.1
Er is als volgt een mechanisme voor wijzigings- en manipulatiedetectie ingezet:
1. "Om personeel te waarschuwen voor ongeautoriseerde wijzigingen (inclusief indicatoren van compromittering, wijzigingen, toevoegingen en verwijderingen) aan de beveiligingsgerelateerde HTTP-headers en de scriptinhoud van betaalpagina's zoals ontvangen door de browser van de consument."
Deze vereiste heeft betrekking op het monitoren van alle server-side beveiligingsheaders die kunnen worden aangepast in de periode voorafgaand aan een aanval, maar ook op de vereiste om de scriptpayloads te monitoren.
De scriptpayload moet worden geanalyseerd en er moeten tijdig meldingen worden verstuurd bij een compromittering. Een melding zonder indicatoren van de reden ervan is uiteraard zinloos; om bruikbaar te zijn, moet de scriptinhoud worden opgeslagen en weergegeven voor forensisch onderzoek.
Voorbeelden van wijzigingen die meldingen vereisen: "E-commerce skimming-code of -technieken mogen niet worden toegevoegd aan betaalpagina's zoals ontvangen door de browser van de consument zonder dat er tijdig een melding wordt gegenereerd. Anti-skimming-maatregelen mogen niet worden verwijderd van betaalpagina's zonder dat er onmiddellijk een melding wordt gegenereerd."
Het is ook noodzakelijk om een mechanisme te hebben dat bewaakt of er met de beveiligingsoplossing zelf wordt geknoeid. Als deze wordt verwijderd, moet dit resulteren in een melding.
Om aan deze vereisten te voldoen, moeten de onderstaande beveiligingsheaders worden gemonitord:
| Beveiligingsheader | Beschrijving |
|---|---|
| Content Security Policy | Ook bekend als CSP-header. |
| Content Security Policy Report Only | De CSP-header maar in alleen-rapportagemodus, niet blokkerend. |
| Report To | Rapportage-eindpunt conform de verouderde specificatie. |
| Reporting Endpoints | Alternatief rapportage-eindpunt conform de recentere specificatie. |
| Strict Transport Security (HSTS) | Beperkt de browser tot uitsluitend verbinden via HTTPS. |
| X-Frame-Options | Maakt het mogelijk te definiëren of iframes in de webpagina mogen worden geïnjecteerd. |
| Cross-Origin Resource Policy (CORP) | Stelt de webpagina in staat te definiëren welke resources mogen worden geladen en van waar. Gerelateerd aan CORS en Same-Origin Policy. |
| Cross-Origin Opener Policy | Stelt de webpagina in staat te definiëren hoe de browser moet omgaan met verschillende contexten zoals tabbladen, iframes en vensters. |
| Cross-Origin Embedder Policy | Maakt het mogelijk te bepalen welke cross-origin componenten de browser mag laden. |
| Permissions Policy | Maakt het mogelijk te definiëren welke apparaat-API's mogen worden benaderd door de webapplicatie en haar afhankelijkheden. |
| X-Content-Type-Options | Dwingt de browser strikt de inhoudstypen te controleren. Browsers zouden anders kwaadaardige injecties via onbedoelde inhoudstypen kunnen toestaan. Een veelgebruikte methode bij client-side uitvoeringen en MIME-stijlaanvallen. |
| X-Permitted-Cross-Domain-Policies | Is een meer verouderde beveiligingsheader die aangeeft van welke domeinen Flash Player en PDF-lezers content mochten ophalen. |
| Referrer Policy | Leuk weetje: er zit een typefout in de HTTP-specificatie voor 'referer'. Deze header maakt het mogelijk te definiëren hoeveel informatie wordt meegestuurd door de referrer, de vorige pagina of de bovenliggende pagina. |
| X-XSS-Protection | Is een verouderde beveiligingsheader om de native XSS-detectiefuncties van de browser in of uit te schakelen. |
2. "Het mechanisme is geconfigureerd om de ontvangen HTTP-headers en betaalpagina's te evalueren"
Dit sluit aan bij de hierboven genoemde punten over het monitoren van alle beveiligingsgerelateerde HTTP-headers op de betaalpagina.
3. "De functies van het mechanisme worden als volgt uitgevoerd: Minimaal wekelijks OF periodiek (met de frequentie die is vastgelegd in de gerichte risicoanalyse van de entiteit, uitgevoerd conform alle elementen zoals gespecificeerd in Vereiste 12.3.1)."
Dit gedeelte geeft aan dat deze controles minimaal wekelijks moeten plaatsvinden, of met de frequentie die door 12.3.1 wordt voorgeschreven. Steekproeven zijn toegestaan voor HTTP-headers en scriptinhoud, maar minimaal wekelijks moeten deze worden beoordeeld. Een week is een lange tijd; het wordt aanbevolen merchants te adviseren een proactievere beveiligingshouding aan te nemen.
AOC's en ROC's voor leveranciers
Leveranciers die beveiligingsoplossingen bieden voor 6.4.3 en 11.6.1 zijn geen TPSP in de context van betalingen (Third-Party Service Provider) en vereisen geen SAQ, AOC of ROC voor hun eigen product door een QSA. Sommige grotere leveranciers beschikken over deze certificeringen voor andere onderdelen van hun bedrijf, en soms vermelden zij hun PCI-gerelateerde tools in die rapporten. Dat betekent niet automatisch dat die tools zijn getest of gevalideerd. De merchant blijft uiteindelijk verantwoordelijk voor het aantonen van compliance met PCI DSS. Sommige leveranciers betalen QSA's om hun oplossingen te beoordelen en whitepapers te publiceren, maar ook dit garandeert niet volledig de compliance voor individuele merchants.
Server-side gerenderde webapplicaties versus single-page applications:
Traditionele server-gerenderde apps laden bij elke klik op een element een nieuwe pagina van de server. Bijvoorbeeld: een online bankportaal waarbij elke klik (bijv. het bekijken van saldi) een volledig nieuwe pagina laadt van de servers van de bank.
Single-page applications (SPA's) daarentegen laden eenmalig en vertrouwen op JavaScript om inhoud dynamisch bij te werken. Bijvoorbeeld: een e-commerce checkout gebouwd in React waarbij de pagina nooit volledig herlaadt; in plaats daarvan worden formulieren, productdetails en betaalvelden dynamisch bijgewerkt in de browser. Het gebruik van single-page applications is sterk toegenomen doordat steeds meer websites worden gebouwd met webontwikkelingsframeworks zoals React, Angular en Vue.
