Kort samengevat: risico van alleen betaalpagina's beschermen onder PCI DSS
- Compliance is geen dekking: PCI DSS 4.0 verplicht scriptmonitoring alleen op betaalpagina's, dus leveranciers samplen graag 10% van de sessies op een handvol URL's en noemen dat compliance, terwijl ze login-, KYC- en accountpagina's open laten voor exact dezelfde klasse derde-partijscripts.
- Elke pagina, elke sessie: Eén gecompromitteerde CDN-gehoste afhankelijkheid plantte vier aparte backdoors op ongeveer 1.000 sites tegelijk; cside zit tussen de derde partij en de gebruiker op elke pagina, geeft volledig scriptzicht in 100% van de sessies en verbetert vaak de performance via cache.
- Voordat je goedkeurt: Voor je volgende PCI DSS 6.4.3-goedkeuring: beslis of XSS op niet-betaalpagina's, sessiehijacking van MFA-geauthenticeerde gebruikers en supply-chain-aanvallen op nevenscripts in scope tellen voor je websitebeveiligingsprogramma.
Weinig tijd? Bekijk cside's in-browser blokkering van Magecart en skimmers. Dit dekt alles hieronder in één deployment.
PCI DSS 4.0 is er. Vanaf maart 2025 verplicht het dat betaalportalen een manier moeten hebben om elk script op betaalpagina's te autoriseren. Websites moeten een inventaris bijhouden van alle scripts (op die betaalportalen in ieder geval) en de integriteit ervan waarborgen. Je moet nu ongeautoriseerde wijzigingen op betaalpagina's detecteren en erop reageren, inclusief wijzigingen in HTTP-headers en pagina-inhoud. Organisaties moeten deze configuraties minimaal eens per zeven dagen controleren of zoals bepaald door hun risicoanalyse.
Lees hier de volledige vereisten.
Een andere belangrijke passage daarin: PCI DSS 4.0 moedigt nu een verschuiving aan van jaarlijkse audits naar continue beveiligingsmonitoring, wat betekent dat systeemcomponenten en software regelmatig worden beoordeeld en bijgewerkt.
Eindelijk!
Op dit moment zijn alleen betaalportalen verplicht om een systeem te hebben dat JavaScript van derden in toom houdt. Dat is waarom veel van onze concurrenten (lees hier wat wij van hen vinden) hun diensten beperken tot slechts een paar pagina's. Sommigen samplen zelfs de sessie, zodat maar 10% van de sessies beschermd is.
Maar dat is vragen om problemen.
Waarom je alle pagina's moet beschermen
Er blijft een risico op een datalek als je niet alle pagina's beveiligt.
Kwaadwillenden kunnen gecompromitteerde scripts op andere delen van je site gebruiken om gebruikerssessies te kapen. Hiermee kunnen ze legitieme gebruikers nabootsen en ongeautoriseerde acties uitvoeren, waardoor ze mogelijk zelfs bepaalde vormen van tweefactorauthenticatie omzeilen. Dat zou de bescherming van scripts van derden op je betaalportalen potentieel kunnen omzeilen.
Een ander gebied dat je blootstelt aan risico zijn Cross-site scripting (XSS)-kwetsbaarheden. Die stellen aanvallers in staat om kwaadaardige scripts te injecteren in webpagina's die door andere gebruikers worden bekeken. Als alleen het betaalportaal beschermd is, kunnen andere pagina's worden misbruikt voor XSS-aanvallen, wat toch gevolgen heeft voor de gegevens en privacy van gebruikers.
Ook supply-chain-aanvallen worden niet volledig geblokkeerd. Scripts van derden zijn een veelgebruikte vector voor supply-chain-aanvallen. Als aanvallers een leverancier of een script compromitteren dat op je hele site wordt gebruikt, voorkomt het focussen van bescherming op alleen het betaalportaal geen misbruik via andere integraties van derden. Eén CDN-gehost script van cdn.csyndication[.]com werd gebruikt om tegelijkertijd vier afzonderlijke backdoors te planten op 1.000 websites: één gecompromitteerde afhankelijkheid, vier toegangspunten voor de aanvaller.
Remote Code Execution (RCE)- en Command Injection-kwetsbaarheden vormen aanzienlijke risico's die verder aantonen waarom je alle pagina's moet beveiligen, niet alleen kritieke onderdelen zoals betaalportalen. RCE stelt aanvallers in staat om willekeurige code op je server uit te voeren, wat mogelijk leidt tot volledige systeemcompromittering. Dit kan optreden via onveilige verwerking van gebruikersinvoer, zoals het evalueren van code die door gebruikers is geüpload of via formuliervelden is geïnjecteerd.
Command Injection-kwetsbaarheden ontstaan wanneer onveilige gebruikersinvoer wordt uitgevoerd als systeemopdrachten, met name via onjuist gesanitiseerde JavaScript-invoer. Dit kan aanvallers in staat stellen serveracties te manipuleren of toegang te krijgen tot backend-databases, wat leidt tot ongeautoriseerde gegevenswijzigingen of -diefstal.
Tot slot zijn social engineering en phishing een reële bedreiging. Aanvallers kunnen inhoud aanpassen of gebruikers doorsturen naar kwaadaardige sites, waardoor ze worden misleid om gevoelige informatie te verstrekken.
Andere kwetsbaarheden
Zelfs als je betaalportalen beschermd zijn en die bescherming werkt, blijven andere pagina's het risico lopen om te worden gecompromitteerd.
Als dat gebeurt, loop je nog steeds het risico het vertrouwen van gebruikers te verliezen en mogelijk juridische of regelgevende gevolgen te ondervinden, met name met betrekking tot gegevensbeschermingswetten zoals de AVG of CCPA. De schade in kosten die daaruit voortvloeit, of de reputatieschade, is moeilijk te kwantificeren. Maar ze zijn er wel.
Doe het dus meteen goed
Net als de PCI DSS 4.0-regels moedigen wij elke site-eigenaar aan om continue beveiligingsmonitoring toe te passen. En ik hoop dat we duidelijk hebben gemaakt dat dit op alle pagina's doen de beste aanpak is.
De gratis versie van cside maakt je site PCI DSS-compliant wat betreft scripts van derden, en het werkt op alle pagina's. Onze aanpak verschilt echter van die van de concurrentie. Ons script herschrijft de bronnen van andere scripts op je site om ze via cside op te halen en te analyseren en een aantal detecties aan de browserzijde uit te voeren. Zo zit cside in de stroom van het verzoek tussen de gebruiker en het script van derden, zonder extra latentie, en in sommige gevallen zelfs met betere prestaties dankzij het cachen van statische scripts.
Dit geeft volledig inzicht in de aangeboden scripts, over 100% van de sessies, en op alle pagina's, ter bescherming van zowel jou als je gebruikers.
Als je meer wilt lezen over hoe onze aanpak verschilt, ga dan hier naartoe.
