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 is dat PCI DSS 4.0 nu een verschuiving aanmoedigt van jaarlijkse audits naar continue beveiligingsmonitoring, met regelmatige beoordelingen en updates van systeemcomponenten en software.
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 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.
Zelfs in sommige gevallen worden Supply Chain-aanvallen 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.
Remote Code Execution (RCE)- en Command Injection-kwetsbaarheden vormen aanzienlijke beveiligingsrisico's die de noodzaak om alle pagina's te beveiligen verder onderstrepen, 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 de bescherming werkt, loop je nog steeds het risico dat scripts op andere pagina's worden gecompromitteerd, zoals we hebben vastgesteld.
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 door boetes die daaruit voortvloeit, of reputatieschade, is moeilijk te kwantificeren. Toch is het er.
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 voor wat betreft scripts van derden, en het werkt op alle pagina's. Onze aanpak verschilt echter van die van de concurrentie. Onze script herschrijft de bronnen van andere scripts op je site om ze via cside te proxyen 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 biedt volledig inzicht in de aangeboden scripts, 100% van de sessie, 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.
