Webbeveiligingsheaders: Content Security Policy en JavaScript-uitvoering

In het complexe digitale landschap van vandaag is de beveiliging van webapplicaties van het grootste belang. Een van de meest effectieve verdedigingen tegen diverse aanvallen, met name Cross-Site Scripting (XSS), is het gebruik van webbeveiligingsheaders. Onder deze headers onderscheidt Content Security Policy (CSP) zich als een krachtig mechanisme om te bepalen welke bronnen een browser mag laden voor een bepaalde pagina. Dit artikel biedt een uitgebreide gids voor het begrijpen en effectief implementeren van CSP om uw webapplicaties en gebruikers te beschermen.

Webbeveiligingsheaders begrijpen

Webbeveiligingsheaders zijn HTTP-responseheaders die de browser instructies geven over hoe te handelen bij bepaalde soorten content. Ze vormen een cruciaal onderdeel van een 'defense-in-depth'-strategie en werken samen met andere beveiligingsmaatregelen om risico's te beperken.

Enkele van de meest gebruikte webbeveiligingsheaders zijn:

• Content Security Policy (CSP): Bepaalt welke bronnen de user-agent mag laden.
• HTTP Strict Transport Security (HSTS): Dwingt browsers om HTTPS te gebruiken.
• X-Frame-Options: Beschermt tegen Clickjacking-aanvallen.
• X-Content-Type-Options: Voorkomt kwetsbaarheden door MIME-sniffing.
• Referrer-Policy: Bepaalt hoeveel referrer-informatie met verzoeken moet worden meegestuurd.
• Permissions-Policy (voorheen Feature-Policy): Maakt gedetailleerde controle over browserfuncties mogelijk.

Dit artikel richt zich voornamelijk op Content Security Policy (CSP) en de impact ervan op de uitvoering van JavaScript.

Wat is Content Security Policy (CSP)?

CSP is een HTTP-responseheader waarmee u een 'whitelist' kunt definiëren van bronnen waaruit de browser resources mag laden. Dit omvat JavaScript, CSS, afbeeldingen, lettertypen en andere assets. Door deze vertrouwde bronnen expliciet te definiëren, kunt u het risico op XSS-aanvallen aanzienlijk verminderen, waarbij kwaadaardige scripts op uw website worden geïnjecteerd en uitgevoerd in de context van de browser van uw gebruikers.

Zie CSP als een firewall voor uw browser, maar in plaats van netwerkverkeer te blokkeren, blokkeert het de uitvoering van niet-vertrouwde code.

Waarom is CSP belangrijk voor de uitvoering van JavaScript?

JavaScript is een krachtige taal die gebruikt kan worden om dynamische en interactieve webervaringen te creëren. De flexibiliteit ervan maakt het echter ook een belangrijk doelwit voor aanvallers. XSS-aanvallen omvatten vaak het injecteren van kwaadaardige JavaScript-code op een website, die vervolgens kan worden gebruikt om gebruikersgegevens te stelen, gebruikers om te leiden naar phishing-sites of de website te beschadigen.

CSP kan deze aanvallen effectief voorkomen door de bronnen te beperken van waaruit JavaScript kan worden geladen en uitgevoerd. Standaard blokkeert CSP alle inline JavaScript (code binnen <script>-tags) en JavaScript dat wordt geladen vanaf externe domeinen. U kunt vervolgens selectief vertrouwde bronnen inschakelen met behulp van CSP-richtlijnen.

CSP-richtlijnen: De bouwstenen van uw beleid

CSP-richtlijnen (directives) bepalen de soorten resources die geladen mogen worden en de bronnen van waaruit ze geladen mogen worden. Hier zijn enkele van de belangrijkste richtlijnen:

• default-src: Dient als een fallback voor andere fetch-richtlijnen. Als een specifieke richtlijn niet is gedefinieerd, wordt default-src gebruikt.
• script-src: Specificeert de toegestane bronnen voor JavaScript-code.
• style-src: Specificeert de toegestane bronnen voor CSS-stylesheets.
• img-src: Specificeert de toegestane bronnen voor afbeeldingen.
• font-src: Specificeert de toegestane bronnen voor lettertypen.
• media-src: Specificeert de toegestane bronnen voor audio- en videobestanden.
• object-src: Specificeert de toegestane bronnen voor plug-ins (bijv. Flash).
• frame-src: Specificeert de toegestane bronnen voor frames (<frame>, <iframe>).
• connect-src: Specificeert de toegestane origins voor netwerkverzoeken (bijv. XMLHttpRequest, Fetch API, WebSockets).
• base-uri: Beperkt de URL's die gebruikt kunnen worden in het <base>-element van een document.
• form-action: Beperkt de URL's waarnaar formulieren kunnen worden verzonden.
• upgrade-insecure-requests: Instrueert de browser om alle onveilige URL's (HTTP) te upgraden naar veilige URL's (HTTPS).
• block-all-mixed-content: Voorkomt dat de browser bronnen laadt via HTTP wanneer de pagina via HTTPS is geladen.

Elke richtlijn kan verschillende bron-expressies accepteren, waaronder:

• *: Staat bronnen van elke herkomst toe (over het algemeen niet aanbevolen).
• 'self': Staat bronnen van dezelfde oorsprong (schema, host en poort) als het document toe.
• 'none': Verbiedt bronnen van alle herkomsten.
• 'unsafe-inline': Staat het gebruik van inline JavaScript en CSS toe (sterk afgeraden).
• 'unsafe-eval': Staat het gebruik van eval() en gerelateerde functies toe (sterk afgeraden).
• 'unsafe-hashes': Staat specifieke inline event handlers toe op basis van hun SHA256-, SHA384- of SHA512-hash (voorzichtig gebruiken).
• data:: Staat data:-URI's toe (bijv. inline afbeeldingen gecodeerd als base64).
• https://example.com: Staat bronnen van het opgegeven domein (en optioneel poort) via HTTPS toe.
• *.example.com: Staat bronnen van elk subdomein van example.com toe.
• nonce-{random-value}: Staat specifieke inline scripts of stijlen toe met een overeenkomend nonce-attribuut (aanbevolen voor inline code).
• sha256-{hash-value}: Staat specifieke inline scripts of stijlen toe met een overeenkomende SHA256-hash (alternatief voor nonces).

CSP implementeren: Praktische voorbeelden

Er zijn twee primaire manieren om CSP te implementeren:

1. HTTP-header: Het versturen van de Content-Security-Policy-header in de HTTP-response. Dit is de voorkeursmethode.
2. <meta>-tag: Het gebruik van een <meta>-tag in de <head>-sectie van het HTML-document. Deze methode heeft beperkingen en wordt over het algemeen niet aanbevolen.

De HTTP-header gebruiken

Om de CSP-header in te stellen, moet u uw webserver configureren. De exacte stappen variëren afhankelijk van uw server (bijv. Apache, Nginx, IIS).

Hier zijn enkele voorbeelden van CSP-headers:

Basis CSP

Dit beleid staat alleen bronnen van dezelfde oorsprong toe:

            Content-Security-Policy: default-src 'self';
            

              
                Copy
              
            
          

Bronnen van specifieke domeinen toestaan

Dit beleid staat JavaScript toe van https://cdn.example.com en afbeeldingen van https://images.example.net:

            Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; img-src 'self' https://images.example.net;
            

              
                Copy
              
            
          

Nonces gebruiken voor inline scripts

Dit beleid staat inline scripts toe die een overeenkomend nonce-attribuut hebben:

            Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-rAnd0mN0nc3';
            

              
                Copy
              
            
          

In uw HTML:

            <script nonce="rAnd0mN0nc3">
 // Uw inline script
</script>
            

              
                Copy
              
            
          

Let op: De nonce-waarde moet voor elk verzoek willekeurig worden gegenereerd om te voorkomen dat aanvallers de CSP omzeilen.

Hashes gebruiken voor inline scripts

Dit beleid staat specifieke inline scripts toe op basis van hun SHA256-hash:

            Content-Security-Policy: default-src 'self'; script-src 'self' 'sha256-qznLcsROx4GACP2dm0UCKCzCG+HiZ1guq6ZZDob/Tng=';
            

              
                Copy
              
            
          

Om de SHA256-hash te genereren, kunt u verschillende online tools of command-line hulpprogramma's gebruiken (bijv. openssl dgst -sha256 -binary input.js | openssl base64).

De <meta>-tag gebruiken

Hoewel niet aanbevolen voor complexe beleidsregels, kan de <meta>-tag worden gebruikt om een basis-CSP in te stellen. Bijvoorbeeld:

            <meta http-equiv="Content-Security-Policy" content="default-src 'self';">
            

              
                Copy
              
            
          

Beperkingen van de <meta>-tag:

• Kan niet worden gebruikt om de report-uri-richtlijn te specificeren.
• Wordt niet zo breed ondersteund als de HTTP-header.
• Minder flexibel en moeilijker te beheren voor complexe beleidsregels.

CSP Report-Only-modus

Voordat u een CSP afdwingt, wordt het ten zeerste aanbevolen om de Content-Security-Policy-Report-Only-header te gebruiken. Hiermee kunt u de impact van uw beleid monitoren zonder daadwerkelijk bronnen te blokkeren. De browser rapporteert eventuele overtredingen aan een opgegeven URL, zodat u uw beleid kunt verfijnen voordat u het in productie implementeert.

            Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report;
            

              
                Copy
              
            
          

U moet een server-side endpoint (bijv. /csp-report) configureren om de CSP-rapporten te ontvangen en te verwerken. Deze rapporten zijn doorgaans JSON-objecten die informatie bevatten over de geschonden richtlijn, de geblokkeerde URI en andere relevante details.

Veelvoorkomende CSP-fouten en hoe ze te vermijden

Het implementeren van CSP kan een uitdaging zijn, en het is gemakkelijk om fouten te maken die uw beveiliging kunnen verzwakken of uw website kunnen breken. Hier zijn enkele veelvoorkomende valkuilen om te vermijden:

• 'unsafe-inline' en 'unsafe-eval' gebruiken: Deze richtlijnen schakelen in wezen de bescherming die CSP biedt uit en moeten waar mogelijk worden vermeden. Gebruik nonces of hashes voor inline scripts en vermijd het gebruik van eval().
• * gebruiken: Het toestaan van bronnen van elke herkomst ondermijnt het doel van CSP. Wees zo specifiek mogelijk bij het definiëren van uw beleid.
• Niet grondig testen: Test uw CSP altijd in de report-only-modus voordat u deze afdwingt. Monitor de rapporten en pas uw beleid waar nodig aan.
• Onjuiste configuratie van de report-uri: Zorg ervoor dat uw report-uri-endpoint correct is geconfigureerd om CSP-rapporten te ontvangen en te verwerken.
• Verzuimen om uw CSP bij te werken: Naarmate uw website evolueert, moet uw CSP mogelijk worden bijgewerkt om wijzigingen in uw resource-afhankelijkheden weer te geven.
• Te restrictief beleid: Beleidsregels die te restrictief zijn, kunnen uw website breken en gebruikers frustreren. Vind een balans tussen veiligheid en bruikbaarheid.

CSP en externe bibliotheken

Veel websites zijn afhankelijk van externe bibliotheken en diensten, zoals CDN's, analyseproviders en social media-widgets. Bij het implementeren van CSP is het belangrijk om rekening te houden met deze afhankelijkheden en ervoor te zorgen dat uw beleid hen toestaat om bronnen correct te laden.

Hier zijn enkele strategieën voor het omgaan met externe bibliotheken:

• Whitelist expliciet de domeinen van vertrouwde externe providers: Als u bijvoorbeeld jQuery van een CDN gebruikt, voeg dan het domein van de CDN toe aan uw script-src-richtlijn.
• Gebruik Subresource Integrity (SRI): Met SRI kunt u verifiëren dat de bestanden die u van externe bronnen laadt, niet zijn gemanipuleerd. Om SRI te gebruiken, moet u een cryptografische hash van het bestand genereren en deze opnemen in de <script>- of <link>-tag.
• Overweeg om externe bibliotheken op uw eigen server te hosten: Dit geeft u meer controle over de bronnen en vermindert uw afhankelijkheid van externe providers.

Voorbeeld met SRI:

            <script
 src="https://cdn.example.com/jquery.min.js"
 integrity="sha384-vtXRMe3mGCkKsTB9UMvnoknreNzcMRujMQFFSQhtI2zxLlClmHsfq9em6JzhbqQ"
 crossorigin="anonymous"></script>
            

              
                Copy
              
            
          

CSP en Single-Page Applications (SPA's)

SPA's zijn vaak sterk afhankelijk van JavaScript en dynamische codegeneratie, wat het implementeren van CSP uitdagender kan maken. Hier zijn enkele tips voor het beveiligen van SPA's met CSP:

• Vermijd het gebruik van 'unsafe-eval': SPA's gebruiken vaak templating-engines of andere technieken die afhankelijk zijn van eval(). Overweeg in plaats daarvan alternatieve benaderingen die geen eval() vereisen, zoals voorgecompileerde templates.
• Gebruik nonces of hashes voor inline scripts: SPA's injecteren vaak dynamisch JavaScript-code. Gebruik nonces of hashes om ervoor te zorgen dat alleen vertrouwde code wordt uitgevoerd.
• Configureer de connect-src-richtlijn zorgvuldig: SPA's doen vaak API-verzoeken naar verschillende endpoints. Zorg ervoor dat u alleen de noodzakelijke domeinen op de whitelist zet in de connect-src-richtlijn.
• Overweeg het gebruik van een CSP-bewust framework: Sommige JavaScript-frameworks bieden ingebouwde ondersteuning voor CSP, wat het gemakkelijker maakt om een veilig beleid te implementeren en te onderhouden.

CSP en Internationalisering (i18n)

Bij het ontwikkelen van webapplicaties voor een wereldwijd publiek is het belangrijk om rekening te houden met de impact van CSP op internationalisering (i18n). Hier zijn enkele factoren om in gedachten te houden:

• Content Delivery Networks (CDN's): Als u een CDN gebruikt om de assets van uw website te leveren, zorg er dan voor dat u de domeinen van de CDN op de whitelist van uw CSP zet. Overweeg het gebruik van verschillende CDN's voor verschillende regio's om de prestaties te optimaliseren.
• Externe lettertypen: Als u externe lettertypen gebruikt (bijv. Google Fonts), zorg er dan voor dat u de domeinen van de lettertypeproviders op de whitelist zet in uw font-src-richtlijn.
• Gokaliseerde content: Als u verschillende versies van uw website voor verschillende talen of regio's aanbiedt, zorg er dan voor dat uw CSP correct is geconfigureerd voor elke versie.
• Integraties met derden: Als u integreert met diensten van derden die specifiek zijn voor bepaalde regio's, zorg er dan voor dat u de domeinen van die diensten op de whitelist van uw CSP zet.

CSP Best Practices: Een wereldwijd perspectief

Hier zijn enkele algemene best practices voor het implementeren van CSP, rekening houdend met een wereldwijd perspectief:

• Begin met een restrictief beleid: Begin met een beleid dat standaard alles blokkeert en schakel vervolgens selectief vertrouwde bronnen in.
• Gebruik eerst de report-only-modus: Test uw CSP in de report-only-modus voordat u deze afdwingt om mogelijke problemen te identificeren.
• Monitor CSP-rapporten: Controleer regelmatig CSP-rapporten om potentiële beveiligingskwetsbaarheden te identificeren en uw beleid te verfijnen.
• Gebruik nonces of hashes voor inline scripts: Vermijd het gebruik van 'unsafe-inline' en 'unsafe-eval'.
• Wees specifiek met uw bronnenlijsten: Vermijd het gebruik van wildcards (*) tenzij absoluut noodzakelijk.
• Gebruik Subresource Integrity (SRI) voor bronnen van derden: Verifieer de integriteit van bestanden die vanaf CDN's worden geladen.
• Houd uw CSP up-to-date: Controleer en update uw CSP regelmatig om wijzigingen in uw website en afhankelijkheden weer te geven.
• Informeer uw team: Zorg ervoor dat uw ontwikkelaars en beveiligingsteam het belang van CSP begrijpen en weten hoe ze het correct moeten implementeren.
• Overweeg het gebruik van een CSP-generator of -beheertool: Deze tools kunnen u helpen uw CSP gemakkelijker te creëren en te onderhouden.
• Documenteer uw CSP: Documenteer uw CSP-beleid en de redenen achter elke richtlijn om toekomstige ontwikkelaars te helpen het te begrijpen en te onderhouden.

Conclusie

Content Security Policy is een krachtig hulpmiddel om XSS-aanvallen te beperken en de beveiliging van uw webapplicaties te verbeteren. Door zorgvuldig een whitelist van vertrouwde bronnen te definiëren, kunt u het risico op de uitvoering van kwaadaardige code aanzienlijk verminderen en uw gebruikers beschermen. Het implementeren van CSP kan een uitdaging zijn, maar door de best practices in dit artikel te volgen en rekening te houden met de specifieke behoeften van uw applicatie en wereldwijde publiek, kunt u een robuust en effectief beveiligingsbeleid creëren dat uw website en gebruikers wereldwijd beschermt.

Onthoud dat beveiliging een doorlopend proces is en dat CSP slechts één stukje van de puzzel is. Combineer CSP met andere beveiligingsmaatregelen, zoals inputvalidatie, output-encoding en regelmatige beveiligingsaudits, om een uitgebreide 'defense-in-depth'-strategie te creëren.

Verdere bronnen

• Content Security Policy (CSP) - MDN Web Docs
• CSP Evaluator
• Content-Security-Policy.com