Web Security Headers: Content Security Policy (CSP) versus JavaScript-uitvoering

In het voortdurend evoluerende landschap van webbeveiliging is het beschermen van uw webapplicaties tegen kwetsbaarheden zoals cross-site scripting (XSS)-aanvallen van het grootste belang. Twee krachtige hulpmiddelen in uw arsenaal zijn Content Security Policy (CSP) en een grondig begrip van hoe JavaScript wordt uitgevoerd in de browser. Dit blogbericht gaat dieper in op de fijne kneepjes van CSP, onderzoekt de relatie met JavaScript-uitvoering en biedt bruikbare inzichten voor ontwikkelaars en beveiligingsprofessionals wereldwijd.

Content Security Policy (CSP) begrijpen

Content Security Policy (CSP) is een krachtige beveiligingsstandaard die helpt bij het beperken van cross-site scripting (XSS) en andere code-injectieaanvallen. Het werkt door u in staat te stellen de bronnen te beheren die de browser mag laden voor een bepaalde webpagina. Zie het als een witte lijst voor de inhoud van uw website. Door een CSP te definiëren, vertelt u de browser in wezen welke bronnen van inhoud (scripts, stijlen, afbeeldingen, lettertypen, enz.) als veilig worden beschouwd en waar ze vandaan mogen komen. Dit wordt bereikt door het gebruik van HTTP-responseheaders.

Hoe CSP werkt

CSP wordt geïmplementeerd via een HTTP-responseheader genaamd Content-Security-Policy. Deze header bevat een set richtlijnen die bepalen welke bronnen zijn toegestaan. Hier zijn enkele belangrijke richtlijnen en hun functionaliteiten:

• default-src: Dit is de terugvalrichtlijn voor alle andere fetch-richtlijnen. Als er geen specifiekere richtlijn wordt gegeven, bepaalt default-src de toegestane bronnen. Bijvoorbeeld, default-src 'self'; staat bronnen van dezelfde oorsprong toe.
• script-src: Definieert de toegestane bronnen voor JavaScript-code. Dit is misschien wel de meest kritieke richtlijn, omdat deze direct invloed heeft op hoe de uitvoering van JavaScript wordt beheerd.
• style-src: Specificeert de toegestane bronnen voor CSS-stylesheets.
• img-src: Beheert de toegestane bronnen voor afbeeldingen.
• font-src: Definieert de toegestane bronnen voor lettertypen.
• connect-src: Specificeert de toegestane bronnen voor verbindingen (bijv. XMLHttpRequest, fetch, WebSocket).
• media-src: Definieert de toegestane bronnen voor audio en video.
• object-src: Specificeert de toegestane bronnen voor plug-ins zoals Flash.
• frame-src: Definieert de toegestane bronnen voor frames en iframes (verouderd, gebruik child-src).
• child-src: Specificeert de toegestane bronnen voor web workers en ingesloten frame-inhoud.
• base-uri: Beperkt de URL's die kunnen worden gebruikt in het <base>-element van een document.
• form-action: Specificeert geldige eindpunten voor het verzenden van formulieren.
• frame-ancestors: Specificeert de geldige ouders waarin een pagina kan worden ingesloten (bijv. in een <frame> of <iframe>).

Aan elke richtlijn kan een set bronexpressies worden toegewezen. Veelvoorkomende bronexpressies zijn onder andere:

• 'self': Staat bronnen van dezelfde oorsprong toe (schema, host en poort).
• 'none': Blokkeert alle bronnen.
• 'unsafe-inline': Staat inline JavaScript en CSS toe. Dit wordt over het algemeen afgeraden en moet waar mogelijk worden vermeden. Het verzwakt de bescherming die CSP biedt aanzienlijk.
• 'unsafe-eval': Staat het gebruik van functies zoals eval() toe, die vaak worden gebruikt bij XSS-aanvallen. Ook sterk afgeraden.
• data:: Staat data-URL's toe (bijv. base64-gecodeerde afbeeldingen).
• blob:: Staat bronnen met het blob:-schema toe.
• https://example.com: Staat bronnen van het opgegeven domein toe via HTTPS. U kunt ook een specifiek pad opgeven, zoals https://example.com/assets/.
• *.example.com: Staat bronnen van elk subdomein van example.com toe.

Voorbeeld-CSP-headers:

Hier zijn enkele voorbeelden om te illustreren hoe CSP-headers worden gebruikt:

Voorbeeld 1: JavaScript beperken tot dezelfde oorsprong

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

              
                Copy
              
            
          

Dit beleid staat de browser toe om alleen JavaScript uit te voeren van dezelfde oorsprong als de pagina. Dit voorkomt effectief de uitvoering van JavaScript dat vanuit externe bronnen is geïnjecteerd. Dit is een goed uitgangspunt voor veel websites.

Voorbeeld 2: JavaScript toestaan van dezelfde oorsprong en een specifieke CDN

            Content-Security-Policy: script-src 'self' cdn.example.com;
            

              
                Copy
              
            
          

Dit beleid staat JavaScript toe van dezelfde oorsprong en van het domein cdn.example.com. Dit is gebruikelijk voor websites die een CDN (Content Delivery Network) gebruiken om hun JavaScript-bestanden aan te bieden.

Voorbeeld 3: Stylesheets beperken tot dezelfde oorsprong en een specifieke CDN

            Content-Security-Policy: style-src 'self' cdn.example.com;
            

              
                Copy
              
            
          

Dit beleid beperkt het laden van CSS tot de oorsprong en cdn.example.com, waardoor het laden van kwaadaardige stylesheets van andere bronnen wordt voorkomen.

Voorbeeld 4: Een uitgebreider beleid

            Content-Security-Policy: default-src 'self'; script-src 'self' cdn.example.com; style-src 'self' fonts.googleapis.com; img-src 'self' data:; font-src fonts.gstatic.com;
            

              
                Copy
              
            
          

Dit is een complexer voorbeeld dat inhoud van dezelfde oorsprong toestaat, JavaScript van dezelfde oorsprong en een CDN, CSS van dezelfde oorsprong en Google Fonts, afbeeldingen van dezelfde oorsprong en data-URL's, en lettertypen van Google Fonts. Merk op dat u externe bronnen expliciet moet toestaan als uw site ze gebruikt.

CSP afdwingen

CSP kan op twee manieren worden afgedwongen:

• Alleen-rapporteren-modus: U kunt de Content-Security-Policy-Report-Only-header instellen. Deze header blokkeert geen bronnen, maar rapporteert overtredingen naar een opgegeven eindpunt (bijv. een server die u beheert). Dit is handig voor het testen van een CSP-beleid voordat u het afdwingt, zodat u potentiële problemen kunt identificeren en kunt voorkomen dat uw website kapotgaat. De browser probeert nog steeds de bronnen te laden, maar geeft een waarschuwing in de ontwikkelaarsconsole en stuurt een rapport naar uw opgegeven eindpunt. Het rapport bevat details over de overtreding, zoals de bron van de geblokkeerde resource en de overtredende richtlijn.
• Afdwingmodus: Wanneer u de Content-Security-Policy-header gebruikt, dwingt de browser het beleid actief af. Als een bron het beleid schendt (bijv. een script wordt geladen van een niet-geautoriseerde bron), zal de browser deze blokkeren. Dit is de bedoelde en meest effectieve manier om CSP voor beveiliging te gebruiken.

JavaScript-uitvoering en CSP

De interactie tussen CSP en JavaScript-uitvoering is cruciaal. De script-src-richtlijn van CSP is het primaire controlepunt voor hoe JavaScript wordt behandeld. Wanneer een browser JavaScript tegenkomt, controleert deze de script-src-richtlijn van de CSP-header. Als de JavaScript-bron is toegestaan, voert de browser deze uit. Als de bron niet is toegestaan, wordt het script geblokkeerd en wordt er een overtredingsrapport gegenereerd als rapportage is ingeschakeld.

Impact op JavaScript-uitvoering

CSP heeft een aanzienlijke impact op hoe u uw JavaScript-code schrijft en structureert. Specifiek kan het invloed hebben op:

• Inline JavaScript: JavaScript dat rechtstreeks in <script>-tags in uw HTML is geschreven, wordt vaak beperkt. Het gebruik van 'unsafe-inline' in script-src versoepelt deze beperking, maar wordt sterk afgeraden. Een betere aanpak is om inline JavaScript naar externe JavaScript-bestanden te verplaatsen.
• eval() en andere dynamische code-uitvoering: Functies zoals eval(), setTimeout() met een string-argument en new Function() worden vaak beperkt. De bronexpressie 'unsafe-eval' is beschikbaar, maar moet worden vermeden. Herstructureer in plaats daarvan uw code om deze praktijken te vermijden of gebruik alternatieve methoden.
• Externe JavaScript-bestanden: CSP bepaalt welke externe JavaScript-bestanden kunnen worden geladen. Dit is een belangrijke verdediging tegen XSS-aanvallen die proberen kwaadaardige scripts te injecteren.
• Event Handlers: Inline event handlers (bijv. <button onclick="myFunction()"></button>) worden vaak geblokkeerd tenzij 'unsafe-inline' is toegestaan. Het is een betere praktijk om event listeners in JavaScript-bestanden te koppelen.

Best practices voor JavaScript-uitvoering met CSP

Om CSP effectief te gebruiken en uw JavaScript-uitvoering te beveiligen, overweeg deze best practices:

• Vermijd inline JavaScript: Verplaats alle JavaScript-code naar externe .js-bestanden. Dit is het meest impactvolle wat u kunt doen.
• Vermijd eval() en andere dynamische code-uitvoering: Herstructureer uw code om het gebruik van eval(), setTimeout() met string-argumenten en new Function() te vermijden. Dit zijn veelvoorkomende aanvalsvectoren.
• Gebruik nonces of hashes voor inline scripts (indien nodig): Als u absoluut inline scripts moet gebruiken (bijv. voor verouderde code), overweeg dan het gebruik van een nonce (een unieke, willekeurig gegenereerde tekenreeks) of een hash (een cryptografische samenvatting van de inhoud van het script). U voegt de nonce of hash toe aan uw CSP-header en de script-tag. Dit stelt de browser in staat om het script uit te voeren als het overeenkomt met de opgegeven criteria. Dit is een veiliger alternatief dan 'unsafe-inline', maar het voegt complexiteit toe.
• Gebruik een strikt CSP-beleid: Begin met een restrictief CSP-beleid (bijv. script-src 'self';) en versoepel het geleidelijk indien nodig. Monitor op overtredingen met de Content-Security-Policy-Report-Only-header voordat u het beleid afdwingt.
• Controleer en update uw CSP-beleid regelmatig: Uw webapplicatie zal in de loop van de tijd evolueren, net als uw CSP-beleid. Controleer en update uw beleid regelmatig om ervoor te zorgen dat het adequate bescherming blijft bieden. Dit omvat wanneer u nieuwe functies toevoegt, bibliotheken van derden integreert of uw CDN-configuratie wijzigt.
• Gebruik een Web Application Firewall (WAF): Een WAF kan helpen bij het detecteren en beperken van aanvallen die uw CSP mogelijk omzeilen. Een WAF fungeert als een extra verdedigingslaag.
• Houd rekening met beveiliging in het ontwerp: Implementeer beveiligingsprincipes vanaf het begin van uw project, inclusief veilige codeerpraktijken en regelmatige beveiligingsaudits.

CSP in actie: voorbeelden uit de praktijk

Laten we enkele praktijkscenario's bekijken en hoe CSP helpt om kwetsbaarheden te beperken:

Scenario 1: XSS-aanvallen van externe bronnen voorkomen

Een website staat gebruikers toe om opmerkingen te plaatsen. Een aanvaller injecteert kwaadaardig JavaScript in een opmerking. Zonder CSP zou de browser het geïnjecteerde script uitvoeren. Met een CSP die alleen scripts van dezelfde oorsprong toestaat (script-src 'self';), zal de browser het kwaadaardige script blokkeren omdat het afkomstig is van een andere bron.

Scenario 2: XSS-aanvallen door een gecompromitteerde vertrouwde CDN voorkomen

Een website gebruikt een CDN (Content Delivery Network) om zijn JavaScript-bestanden aan te bieden. Een aanvaller compromitteert de CDN en vervangt legitieme JavaScript-bestanden door kwaadaardige. Met een CSP die het domein van de CDN specificeert (bijv. script-src 'self' cdn.example.com;), is de website beschermd, omdat het de uitvoering beperkt tot alleen bestanden die op het specifieke CDN-domein worden gehost. Als de gecompromitteerde CDN een ander domein gebruikt, zou de browser de kwaadaardige scripts blokkeren.

Scenario 3: Risico's beperken met bibliotheken van derden

Een website integreert een JavaScript-bibliotheek van een derde partij. Als die bibliotheek wordt gecompromitteerd, kan een aanvaller kwaadaardige code injecteren. Door een strikte CSP te gebruiken, kunnen ontwikkelaars de uitvoering van JavaScript van de bibliotheek van derden beperken door bronrichtlijnen in hun CSP-beleid te specificeren. Door bijvoorbeeld de specifieke oorsprongen van de bibliotheek van derden op te geven, kan de website zichzelf beschermen tegen mogelijke exploits. Dit is met name belangrijk voor open-sourcebibliotheken, die vaak wereldwijd in veel projecten worden gebruikt.

Wereldwijde voorbeelden:

Denk aan het diverse digitale landschap van de wereld. Landen zoals India, met hun grote bevolking en wijdverbreide internettoegang, staan vaak voor unieke beveiligingsuitdagingen vanwege het toenemende aantal verbonden apparaten. Evenzo is in regio's als Europa, met de strenge AVG (Algemene Verordening Gegevensbescherming)-naleving, de ontwikkeling van veilige webapplicaties van het grootste belang. Het gebruik van een CSP en het toepassen van veilige JavaScript-praktijken kunnen organisaties in al deze regio's helpen om aan hun beveiligings- en nalevingsverplichtingen te voldoen. In landen als Brazilië, waar e-commerce snel groeit, is het beveiligen van online transacties met CSP cruciaal om zowel het bedrijf als de consument te beschermen. Hetzelfde geldt voor Nigeria, Indonesië en elk ander land.

Geavanceerde CSP-technieken

Naast de basis zijn er verschillende geavanceerde technieken die uw CSP-implementatie kunnen verbeteren:

• Nonce-gebaseerde CSP: Bij het werken met inline scripts bieden nonces een veiliger alternatief voor 'unsafe-inline'. Een nonce is een unieke, willekeurig gegenereerde tekenreeks die u voor elke aanvraag genereert en opneemt in zowel uw CSP-header (script-src 'nonce-UW_NONCE';) als de <script>-tag (<script nonce="UW_NONCE">). Dit vertelt de browser om alleen scripts uit te voeren die de overeenkomende nonce hebben. Deze aanpak beperkt de mogelijkheden voor aanvallers om kwaadaardige code te injecteren aanzienlijk.
• Hash-gebaseerde CSP (SRI - Subresource Integrity): Hiermee kunt u de cryptografische hash van de inhoud van het script specificeren (bijv. met het SHA-256-algoritme). De browser zal het script alleen uitvoeren als de hash overeenkomt met die in de CSP-header. Dit is een andere manier om inline scripts (minder gebruikelijk) of externe scripts te behandelen. Subresource Integrity wordt over het algemeen gebruikt voor externe bronnen zoals CSS en JavaScript-bibliotheken, en het beschermt tegen het risico van een gecompromitteerde CDN die kwaadaardige code levert die anders is dan de bedoelde bibliotheek.
• CSP Reporting API: De CSP Reporting API stelt u in staat om gedetailleerde informatie te verzamelen over CSP-overtredingen, inclusief de overtredende richtlijn, de bron van de geblokkeerde resource en de URL van de pagina waar de overtreding plaatsvond. Deze informatie is essentieel voor het monitoren, oplossen van problemen en verbeteren van uw CSP-beleid. Er zijn verschillende tools en diensten die u kunnen helpen bij het verwerken van deze rapporten.
• CSP Builder Tools: Tools kunnen u helpen bij het genereren en testen van CSP-beleid, zoals CSP Evaluator en online CSP-bouwers. Deze kunnen het proces van het maken en beheren van uw beleid stroomlijnen.

JavaScript-uitvoering en best practices voor beveiliging

Naast CSP, overweeg de volgende algemene best practices voor beveiliging met betrekking tot JavaScript:

• Invoervalidatie en -sanering: Valideer en saneer gebruikersinvoer altijd aan de server- en clientzijde om XSS en andere injectieaanvallen te voorkomen. Saneer data om potentieel gevaarlijke tekens te verwijderen of te coderen, zoals die worden gebruikt om een script te initiëren.
• Veilige codeerpraktijken: Volg veilige codeerprincipes, zoals het gebruik van geparametriseerde query's om SQL-injectie te voorkomen, en vermijd het opslaan van gevoelige gegevens in client-side code. Wees u bewust van hoe de code omgaat met potentieel gevoelige gegevens.
• Regelmatige beveiligingsaudits: Voer regelmatig beveiligingsaudits uit, inclusief penetratietesten, om kwetsbaarheden in uw webapplicaties te identificeren en aan te pakken. Een beveiligingsaudit, ook wel een penetratietest genoemd, is een gesimuleerde aanval op een systeem. Deze audits zijn essentieel voor het detecteren van kwetsbaarheden die aanvallers kunnen uitbuiten.
• Houd afhankelijkheden up-to-date: Werk uw JavaScript-bibliotheken en -frameworks regelmatig bij naar de nieuwste versies om bekende kwetsbaarheden te patchen. Kwetsbare bibliotheken zijn een belangrijke bron van beveiligingsproblemen. Gebruik tools voor afhankelijkheidsbeheer om updates te automatiseren.
• Implementeer HTTP Strict Transport Security (HSTS): Zorg ervoor dat uw webapplicatie HTTPS gebruikt en HSTS implementeert om browsers te dwingen altijd via HTTPS met uw site te verbinden. Dit helpt man-in-the-middle-aanvallen te voorkomen.
• Gebruik een Web Application Firewall (WAF): Een WAF voegt een extra beveiligingslaag toe door kwaadaardig verkeer te filteren en aanvallen te voorkomen die andere beveiligingsmaatregelen omzeilen. Een WAF kan kwaadaardige verzoeken, zoals SQL-injecties of XSS-pogingen, detecteren en beperken.
• Onderwijs uw ontwikkelingsteam: Zorg ervoor dat uw ontwikkelingsteam de best practices voor webbeveiliging begrijpt, inclusief CSP, XSS-preventie en veilige codeerprincipes. Het trainen van uw team is een cruciale investering in beveiliging.
• Monitor op beveiligingsrisico's: Zet monitoring- en waarschuwingssystemen op om beveiligingsincidenten snel te detecteren en erop te reageren. Effectieve monitoring helpt bij het identificeren en reageren op potentiële beveiligingsrisico's.

Alles samenbrengen: een praktische gids

Laten we een vereenvoudigd voorbeeld bouwen om te illustreren hoe u deze concepten kunt toepassen.

Scenario: Een eenvoudige website met een contactformulier dat JavaScript gebruikt om formulierinzendingen te verwerken.

1. Stap 1: Analyseer de afhankelijkheden van de applicatie: Bepaal alle JavaScript-bestanden, externe bronnen (zoals CDN's) en inline scripts die uw applicatie gebruikt. Identificeer alle scripts die nodig zijn voor een goede functionaliteit.
2. Stap 2: Verplaats JavaScript naar externe bestanden: Verplaats alle inline JavaScript naar afzonderlijke .js-bestanden. Dit is fundamenteel.
3. Stap 3: Definieer een basis-CSP-header: Begin met een restrictieve CSP. Als u bijvoorbeeld dezelfde oorsprong gebruikt, kunt u beginnen met het volgende:

               Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:;
               
   
                 
                   Copy
                 
               
             

4. Stap 4: Test de CSP in de alleen-rapporteren-modus: Implementeer aanvankelijk de Content-Security-Policy-Report-Only-header om eventuele conflicten te identificeren. Verzamel de rapporten en analyseer ze.
5. Stap 5: Pak eventuele overtredingen aan: Pas op basis van de rapporten de CSP-header aan om de benodigde bronnen toe te staan. Dit kan het op een witte lijst plaatsen van specifieke CDN-domeinen inhouden of, indien absoluut noodzakelijk, het gebruik van nonces of hashes voor inline scripts (hoewel dit zelden nodig is als best practices worden gevolgd).
6. Stap 6: Implementeer en monitor: Zodra u er zeker van bent dat de CSP correct functioneert, schakelt u over naar de Content-Security-Policy-header. Monitor uw applicatie continu op overtredingen en pas uw CSP-beleid aan waar nodig.
7. Stap 7: Implementeer invoervalidatie en -sanering: Zorg ervoor dat de server- en client-side code de invoer van gebruikers valideert en saneert om kwetsbaarheden te voorkomen. Dit is cruciaal om te beschermen tegen XSS-aanvallen.
8. Stap 8: Regelmatige audits en updates: Controleer en update uw CSP-beleid regelmatig, rekening houdend met nieuwe functies, integraties en eventuele wijzigingen in de architectuur van de applicatie of de afhankelijkheden waarop deze vertrouwt. Implementeer regelmatige beveiligingsaudits om onvoorziene problemen op te sporen.

Conclusie

Content Security Policy (CSP) is een cruciaal onderdeel van moderne webbeveiliging, dat samenwerkt met JavaScript-uitvoeringspraktijken om uw webapplicaties te beschermen tegen een breed scala aan bedreigingen. Door te begrijpen hoe CSP-richtlijnen de uitvoering van JavaScript beheersen en door u te houden aan best practices voor beveiliging, kunt u het risico op XSS-aanvallen aanzienlijk verminderen en de algehele beveiliging van uw webapplicaties verbeteren. Onthoud dat u een gelaagde benadering van beveiliging moet hanteren, waarbij u CSP integreert met andere beveiligingsmaatregelen zoals invoervalidatie, Web Application Firewalls (WAF's) en regelmatige beveiligingsaudits. Door deze principes consequent toe te passen, kunt u een veiligere en betrouwbaardere webervaring voor uw gebruikers creëren, ongeacht hun locatie of de technologie die ze gebruiken. Het beveiligen van uw webapplicaties beschermt niet alleen uw gegevens, maar bouwt ook vertrouwen op bij uw wereldwijde publiek en creëert een reputatie van betrouwbaarheid en veiligheid.