Kort samengevat: grenzen van CSP-compliance
- CSP is een kritieke browser-native verdediging, maar biedt op zichzelf geen PCI DSS 4.0.1-compliance. De Polyfill.io-supply-chain-aanval van 2024 slaagde op honderdduizenden sites waar CSP correct was geconfigureerd.
- De fundamentele beperking is dat CSP domeinen toestaat, geen code-integriteit. Als een vertrouwd domein wordt gecompromitteerd (zoals Polyfill.io werd), staat CSP nog steeds toe dat de kwaadaardige code laadt en uitvoert.
- PCI DSS 4.0.1 §6.4.3 en §11.6.1 vereisen expliciet capaciteiten voorbij CSP: script-inventaris met zakelijke rechtvaardiging, integriteitsverificatie bij elke laadbeurt, en detectie van ongeautoriseerde wijzigingen op betaalpagina's.
Weinig tijd? Bekijk cside's in-browser blokkering van Magecart en skimmers. Dit dekt alles hieronder in één deployment.
Wat is een Content Security Policy (CSP)?
Een Content Security Policy (CSP) is een HTTP-responsheader die browsers instrueert welke scriptbronnen, stylesheets en frames mogen worden geladen. Het beperkt XSS door ongeautoriseerde inline scripts en externe loads te blokkeren. CSP is een noodzakelijke basis, maar detecteert geen gedragsafwijkingen in geautoriseerde scripts, houdt niet bij wat scripts tijdens runtime doen, en voldoet niet aan de vereiste van PCI DSS 6.4.3 voor een script-autorisatie-inventaris met zakelijke rechtvaardiging.
Content Security Policy (CSP) is een beveiligingsfunctie van webbrowsers waarmee een website-eigenaar een set regels kan definiëren die bepalen welke resources (bijv. scripts, stijlen, afbeeldingen) door de browser mogen worden geladen en uitgevoerd. We noemen dit de client-side, het allerlaatste punt in de webtoeleveringsketen.
Mits correct geconfigureerd, helpt het een breed scala aan aanvallen te voorkomen. Maar die eerste drie woorden maken alle verschil.
Het kan cross-site scripting (XSS) helpen voorkomen: door de bronnen te beperken waaruit scripts kunnen laden, blokkeert CSP kwaadaardige scripts die in een webpagina worden geïnjecteerd. Als een CSP-beleid bijvoorbeeld script-src 'self' specificeert, kunnen alleen scripts van het eigen domein van de website worden uitgevoerd. Het beschermt ook tegen clickjacking, de frame-ancestors-directive voorkomt dat een site wordt ingesloten in iframes op ongeautoriseerde domeinen, en het beperkt data-injectie-aanvallen door te bepalen welke afbeeldingen, lettertypen en media mogen worden geladen.
Zoals we zullen zien, is dat in de praktijk niet helemaal het geval.
Het doel van CSP (mits correct geconfigureerd)
Verdediging tegen malafide content van derden
Websites zijn vaak afhankelijk van content van derden, zoals analysetools of advertentiescripts, die aanvalsvectoren kunnen worden als ze worden gecompromitteerd. CSP minimaliseert dit risico door content te beperken tot vooraf goedgekeurde, vertrouwde bronnen, waardoor uw site wordt beschermd tegen kwetsbaarheden in bibliotheken van derden.
Voorkomen van data-exfiltratie
Kwaadaardige scripts die zijn ontworpen om gevoelige gegevens te extraheren en naar ongeautoriseerde domeinen te sturen, vormen een constante bedreiging. CSP fungeert als een barrière die dergelijke scripts blokkeert en ervoor zorgt dat gebruikersgegevens veilig blijven.
Bescherming tegen supply chain-aanvallen
In combinatie met Subresource Integrity (SRI) valideert CSP scripts en stijlen van derden om te controleren of ze niet zijn gewijzigd tijdens de levering. Dit voegt een theoretische beveiliging toe tegen supply chain-compromissen.
Controle over onbedoeld dynamisch gedrag
CSP-directives zoals script-src, style-src en beperkingen op unsafe-eval voorkomen de uitvoering van dynamisch gegenereerde of gewijzigde code. Dit verkleint het aanvalsoppervlak door exploits te beperken die afhankelijk zijn van eval() of inline scripts.
Lichtgewicht en zeer configureerbaar
Geleverd via server-side headers heeft CSP minimale impact op de applicatieprestaties. De flexibiliteit ervan maakt op maat gemaakte configuraties mogelijk, waardoor het geschikt is voor een breed scala aan gebruikssituaties en architectuurbehoeften.
De uitdagingen en beperkingen van CSP
Waarom heeft CSP dan een slechte reputatie? In theorie klinkt het als een ideale oplossing. Een krachtig hulpmiddel om volledig te bepalen wat browsers op een website mogen laden.
In de praktijk komt de realiteit echter ver tekort.
CSP is een aanvullend verdedigingsmechanisme, geen op zichzelf staande oplossing, en het gaat gepaard met aanzienlijke uitdagingen en beperkingen die de effectiviteit kunnen belemmeren of zelfs een vals gevoel van veiligheid kunnen geven.
Complexiteit van implementatie
Het opstellen van een effectieve CSP voor moderne webapplicaties is een moeilijke taak. Websites zijn vaak afhankelijk van talloze domeinen van derden voor analyses, CDN's, advertenties en lettertypen, waardoor het vrijwel onmogelijk is om een strikt beleid te maken zonder bepaalde functionaliteit te verbreken. Het beheren van directives zoals script-src, style-src en img-src over diverse bronnen wordt inderdaad onbeheersbaar, met name voor grote en voortdurend veranderende applicaties.
Onvermogen om specifieke scripts te blokkeren
CSP werkt op basis van een allowlist-model dat resources van vertrouwde domeinen toestaat, maar geen individuele scripts of resources van die domeinen kan blokkeren.
Een snel voorbeeld: als u een domein zoals cdn.example.com toestaat, kan CSP niet voorkomen dat kwaadaardige scripts die daar worden gehost worden uitgevoerd.
Recente updates van CSP introduceren een functie om deze beperking aan te pakken met behulp van Subresource Integrity (SRI) ingebouwd in de script-src-directive. Hiermee kunnen specifieke scripts op de allowlist worden geplaatst met behulp van hashes van hun inhoud, zodat alleen de exacte, geverifieerde versie van een script kan worden geladen.
Hoewel krachtig in theorie, heeft deze aanpak een significant nadeel: elke update van het script maakt de hash ongeldig, waardoor de SRI-controle mislukt en het script niet meer functioneert.
Voor scripts die regelmatig worden bijgewerkt, zoals die van marketingtools, maakt dit de hashfunctie nutteloos. Tenzij u werkt met gegarandeerd statische scripts, is dit mechanisme in wezen onbruikbaar.
Hoge onderhoudskosten
CSP-beleid vereist regelmatige updates om rekening te houden met:
- Nieuwe scripts, stijlen of resources voor toegevoegde functies of pagina's.
- Wijzigingen in domeinen of diensten van derden.
- Externe factoren, zoals een API-wijziging van een derde partij, die een eerder functionerend beleid kunnen verbreken.
Alleen al hiervoor is een monitoringtool nodig om updates bij te houden.
Risico's van afhankelijkheden van derden
Het toestaan van resources van derden in CSP-beleid impliceert inherent vertrouwen dat die externe domeinen veilig blijven. Maar gecompromitteerde of kwaadaardige scripts van vertrouwde derde partijen kunnen nog steeds worden uitgevoerd, waardoor CSP-bescherming volledig wordt omzeild.
Deze afhankelijkheid is zelf een kritieke kwetsbaarheid in het CSP-model.
We zagen dit bij de Polyfill-aanval van 2024, waarbij precies dit gebeurde. Meer dan een half miljoen websites vertrouwden op één domein om een script op hun site te injecteren. Zelfs websites met een robuuste CSP-strategie werden slachtoffer.
Uitdagingen met inline scripts en stijlen
Standaard blokkeert CSP inline scripts en stijlen, wat een goede beveiligingsmaatregel is. Maar ook hier zijn er problemen.
- Veel frameworks (bijv. React, Angular) en legacy-systemen zijn sterk afhankelijk van inline scripts, waardoor handhaving moeilijk is zonder uitgebreide refactoring.
- Veel marketingtools bieden voorbeelden met inline
<script>-tags om externe JavaScript-bundels te laden. Hoewel deze scripts vanuit afzonderlijke bestanden zouden kunnen worden uitgevoerd, worden ze in de voorbeelden vaak direct ingesloten, wat CSP-handhaving bemoeilijkt en potentiële risico's introduceert. - Om hiermee om te gaan, grijpen ontwikkelaars vaak terug op unsafe-inline, wat de beveiliging van CSP ondermijnt door alle inline content toe te staan.
Overmatig gebruik van versoepelende directives
Om te voorkomen dat functionaliteit wordt verbroken, moeten ontwikkelaars CSP-beleid daadwerkelijk verzwakken. Een omgekeerde manier om functie boven veiligheid te stellen.
unsafe-inline: staat inline scripts en stijlen toe, waardoor de primaire beveiligingsdoelen van CSP teniet worden gedaan.unsafe-eval: staat het gebruik van eval() en vergelijkbare methoden toe, die zeer exploiteerbaar zijn.*(wildcard): verleent toegang tot elk domein, waardoor de waarde van het beleid effectief wordt geneutraliseerd.
Debuggen van CSP-overtredingen
Het diagnosticeren van CSP-gerelateerde problemen is extreem tijdrovend en frustrerend.
- Browsers loggen CSP-overtredingen naar de console, maar de logs missen vaak voldoende context om de hoofdoorzaak te identificeren.
- Het debuggen van te strikte beleidsregels die functionaliteit verbreken, vereist aanzienlijke inspanning, waardoor ontwikkelaars het beleid versoepelen en de beveiliging in gevaar brengen.
Verbreken van bestaande functionaliteit
Zoals eerder vermeld, kunnen strikte CSP-beleidsregels essentiële componenten verstoren.
- Integraties van derden zoals analyses, advertenties of sociale widgets.
- Legacy-applicaties die afhankelijk zijn van inline scripts, stijlen of dynamisch geladen resources.Om de functionaliteit te herstellen, versoepelen ontwikkelaars vaak de beperkingen, waardoor de beoogde beveiliging wordt ondermijnd.
Browserinconsistenties
CSP-handhaving verschilt van browser tot browser, wat de zaak er niet beter op maakt.
- Oudere browsers kunnen bepaalde directives volledig negeren.
- Sommige directives, zoals worker-src of navigate-to, hebben geen universele ondersteuning, wat hun effectiviteit beperkt.
Gebrek aan gestandaardiseerde rapportage
Hoewel CSP overtredingsrapportage ondersteunt, is er geen universeel geaccepteerd formaat of hulpmiddel voor het verwerken van deze rapporten, waardoor het voor teams moeilijker is om ze effectief te analyseren en erop te reageren.
Eenvoudige exfiltratie-omwegen bij onvolledige CSP-beleidsregels
Een van de grootste kwetsbaarheden in onvolledige CSP-configuraties is de ontbrekende default-src-directive. Zonder deze kunnen CSP-beleidsregels worden omzeild om gegevens te exfiltreren via mechanismen zoals prefetching.
Hoewel default-src bedoeld is om fallback-regels in te stellen, merkt de CSP-specificatie op dat prefetching niet wordt geregeld door een eigen directive, dus zonder default-src omzeilen prefetch-links CSP volledig. Onze analyse van gecrawlde websites toonde een verrassend groot aantal sites zonder default-src, waardoor ze kwetsbaar zijn voor deze exploit. En connect-src helpt ook niet: zelfs een goed geconfigureerde connect-src kan prefetch-gebaseerde exfiltratie niet voorkomen, omdat deze niet van toepassing is op dergelijke verbindingen.
Vermijd CSP, doe dit in plaats daarvan
CSP biedt op papier waardevolle voordelen. In een echte omgeving wordt het gebruik ervan al snel een omslachtige taak. Toch wordt client-side beveiliging steeds gangbaarder.
Controleer bij het zoeken naar een client-side beveiligingstool of ze niet uitsluitend op CSP vertrouwen als basis voor resource-monitoring door het te configureren in de "report-only"-modus. Dergelijke oplossingen zijn voornamelijk afhankelijk van CSP om resourcegedrag bij te houden en te rapporteren, met beperkte blokkeermogelijkheden als aanvullende functie.
Hoewel dit waarschijnlijk voldoende is voor compliance, stelt het u bloot aan een wereld van problemen als u wordt aangevallen.
cside heeft moderne beveiligingsoplossingen die niet afhankelijk zijn van CSP, voor een efficiëntere aanpak van client-side bescherming. We hebben een dienst gebouwd die alle scripts aan uw kant bijhoudt, en die proactief kwaadaardige code kan opsporen en blokkeren.
Geen handmatige controle of rapportage nodig.
U kunt gratis beginnen of contact met ons opnemen.
