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 helpen voorkomen:
Cross-Site Scripting (XSS): Door de bronnen te beperken waaruit scripts kunnen worden geladen, kan CSP kwaadaardige scripts die in een webpagina worden geïnjecteerd effectief blokkeren.
Als een CSP-beleid bijvoorbeeld script-src 'self' specificeert, zorgt dat ervoor dat alleen scripts van het eigen domein van de website worden uitgevoerd.
Bescherming tegen clickjacking: Met de frame-ancestors-directive voorkomt CSP dat uw site wordt ingesloten in iframes op ongeautoriseerde domeinen, waardoor het risico op clickjacking-aanvallen wordt verminderd.
Data-injectie-aanvallen: CSP beheert het laden van resources zoals afbeeldingen, lettertypen en media, waardoor risico's van resource-injectie of -manipulatie worden verminderd.
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 geen op zichzelf staande oplossing, maar een aanvullend verdedigingsmechanisme dat gepaard gaat met aanzienlijke uitdagingen en beperkingen. Deze tekortkomingen kunnen de effectiviteit belemmeren of zelfs een vals gevoel van veiligheid 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 de praktijk onbruikbaar, wat de toepasbaarheid in de echte wereld beperkt.
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 benadrukt 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.
- *******: 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 belangrijkste kwetsbaarheden in onvolledige CSP-configuraties ligt in het weglaten van de default-src-directive. Zonder deze directive kunnen CSP-beleidsregels worden omzeild om gegevens te exfiltreren via mechanismen zoals prefetching.
- De rol van default-src: Hoewel bedoeld om fallback-regels in te stellen, merkt de CSP-specificatie op dat prefetching niet wordt beheerst door een eigen directive. Zonder default-src omzeilen prefetch-links CSP volledig.
- Praktische tekortkoming: Onze analyse van gecrawlde websites onthulde dat een verrassend groot aantal default-src mist, waardoor ze kwetsbaar zijn voor deze exploit.
- Connect-src helpt niet: Zelfs een goed geconfigureerde connect-src kan op 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 belangrijker.
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 biedt moderne beveiligingsoplossingen die niet afhankelijk zijn van CSP en een meer gestroomlijnde en efficiënte aanpak van client-side bescherming bieden. We hebben een proxyservice gebouwd die alle scripts aan uw kant bijhoudt en proactief kwaadaardige code kan detecteren en blokkeren.
Geen handmatige controle of rapportage nodig.
U kunt gratis beginnen of contact met ons opnemen.
