Content Security Policy (CSP): En omfattende guide til forebyggelse af XSS

I nutidens digitale landskab er websikkerhed af afgørende betydning. Cross-Site Scripting (XSS) angreb er fortsat en udbredt og farlig trussel mod webapplikationer globalt. Content Security Policy (CSP) er en kraftfuld HTTP-response header, der giver et ekstra lag af sikkerhed, som hjælper med at mindske risikoen for XSS-sårbarheder. Denne guide giver et omfattende overblik over CSP, dens implementering og bedste praksis til at beskytte dine webapplikationer mod XSS-angreb.

Hvad er Cross-Site Scripting (XSS)?

Cross-Site Scripting (XSS) er en type injektionsangreb, hvor ondsindede scripts injiceres i ellers godartede og pålidelige websteder. XSS-angreb opstår, når en angriber bruger en webapplikation til at sende ondsindet kode, generelt i form af et browser-side script, til en anden slutbruger. Fejl, der gør det muligt for disse angreb at lykkes, er ret udbredte og forekommer overalt, hvor en webapplikation bruger input fra en bruger i den output, den genererer, uden at validere eller kode den.

Der er tre hovedtyper af XSS-angreb:

• Stored (Persistent) XSS: Det ondsindede script gemmes permanent på målserveren (f.eks. i en database, et debatforum, en besøgende log, et kommentarfelt osv.). Når en bruger besøger den berørte side, udføres det gemte script.
• Reflected (Non-Persistent) XSS: Det ondsindede script reflekteres af webserveren, f.eks. i en fejlmeddelelse, et søgeresultat eller et andet svar, der inkluderer noget eller hele inputtet, der sendes til serveren som en del af anmodningen. Brugeren skal lokkes til at klikke på et ondsindet link eller indsende en formular, der indeholder det ondsindede script.
• DOM-based XSS: Sårbarheden findes i selve klient-side koden. Det ondsindede script udføres, fordi browserens DOM-miljø manipuleres til at inkludere angriberens script.

XSS-angreb kan have alvorlige konsekvenser, herunder:

• Stjæle brugeroplysninger (cookies, sessionstokens).
• Ødelægge websteder.
• Omdirigere brugere til ondsindede websteder.
• Installere malware.
• Få uautoriseret adgang til følsomme data.

Hvad er Content Security Policy (CSP)?

Content Security Policy (CSP) er et ekstra lag af sikkerhed, der hjælper med at detektere og afbøde visse typer angreb, herunder Cross-Site Scripting (XSS) og datainjektionsangreb. CSP implementeres ved hjælp af en HTTP-response header, der giver dig mulighed for at kontrollere de ressourcer (f.eks. scripts, stylesheets, billeder, skrifttyper, frames), som browseren har tilladelse til at indlæse for en bestemt side. Ved at definere en streng CSP kan du reducere angrebsoverfladen for din webapplikation betydeligt og gøre det vanskeligere for angribere at injicere ondsindet kode.

CSP fungerer ved at definere en hvidliste over kilder, hvorfra browseren har tilladelse til at indlæse ressourcer. Enhver ressource, der indlæses fra en kilde, der ikke udtrykkeligt er tilladt i CSP, vil blive blokeret af browseren. Dette forhindrer udførelse af uautoriserede scripts og reducerer risikoen for XSS-angreb.

Sådan fungerer CSP: Direktiver og kilder

CSP konfigureres ved hjælp af en række direktiver, der hver især specificerer en politik for en bestemt type ressource. Hvert direktiv består af et navn efterfulgt af en liste over tilladte kilder. Her er nogle af de mest almindeligt anvendte CSP-direktiver:

• `default-src`: Angiver standardpolitikken for hentning af ressourcer, hvis andre ressourcespecifikke direktiver ikke er til stede.
• `script-src`: Angiver de tilladte kilder til JavaScript-kode.
• `style-src`: Angiver de tilladte kilder til stylesheets (CSS).
• `img-src`: Angiver de tilladte kilder til billeder.
• `font-src`: Angiver de tilladte kilder til skrifttyper.
• `connect-src`: Angiver de tilladte kilder til at foretage netværksanmodninger (f.eks. AJAX, WebSockets).
• `media-src`: Angiver de tilladte kilder til indlæsning af video- og lydressourcer.
• `object-src`: Angiver de tilladte kilder til plugins, såsom Flash.
• `frame-src`: Angiver de tilladte kilder til indlejring af frames (iframes).
• `base-uri`: Begrænser de URL'er, der kan bruges i et dokuments <base> element.
• `form-action`: Begrænser de URL'er, som formularer kan indsendes til.
• `upgrade-insecure-requests`: Instruerer browsere til automatisk at opgradere usikre (HTTP) anmodninger til sikre (HTTPS) anmodninger.
• `block-all-mixed-content`: Forhindrer browseren i at indlæse ressourcer ved hjælp af HTTP, når siden indlæses over HTTPS.
• `report-uri`: Angiver en URL, som browseren skal sende rapporter om CSP-overtrædelser til. Udgået til fordel for `report-to`.
• `report-to`: Angiver et navngivet endpoint, som browseren skal sende rapporter om CSP-overtrædelser til.

Almindeligt anvendte kildeværdier inkluderer:

• `*`: Tillader ressourcer fra enhver kilde (anbefales ikke til produktionsmiljøer).
• `'self'`: Tillader ressourcer fra samme oprindelse (skema, host og port) som det beskyttede dokument.
• `'none'`: Forbyder indlæsning af ressourcer fra enhver kilde.
• `data:`: Tillader indlæsning af ressourcer via `data:` skemaet (f.eks. inline billeder).
• `'unsafe-inline'`: Tillader brugen af inline JavaScript og CSS (stærkt frarådet).
• `'unsafe-eval'`: Tillader brugen af `eval()` og lignende funktioner (stærkt frarådet).
• `'strict-dynamic'`: Angiver, at den tillid, der udtrykkeligt er givet til et script, der er til stede i markup, ved at ledsage det med en nonce eller hash, skal videregives til alle de scripts, der er indlæst af det root script.
• `'nonce-'`: Tillader scripts eller styles med et matchende nonce-attribut.
• `'sha256-'`, `'sha384-'`, `'sha512-'`: Tillader scripts eller styles med en matchende SHA hash.
• `https://example.com`: Tillader ressourcer fra et specifikt domæne.

Implementering af CSP

CSP kan implementeres på to primære måder:

1. HTTP Header: Den foretrukne metode er at konfigurere din webserver til at sende `Content-Security-Policy` HTTP-response headeren. Dette giver dig mulighed for at definere CSP for hver side eller ressource på dit websted.
2. <meta> Tag: CSP kan også defineres ved hjælp af et <meta> tag i <head> sektionen af dit HTML-dokument. Denne metode er dog mindre fleksibel og har begrænsninger sammenlignet med brugen af HTTP-headeren. For eksempel kan direktiverne `frame-ancestors`, `sandbox` og `report-uri` ikke bruges i HTML meta tags.

Brug af HTTP Headeren

For at implementere CSP ved hjælp af HTTP-headeren skal du konfigurere din webserver til at inkludere `Content-Security-Policy` headeren i sine responses. De specifikke konfigurationstrin vil variere afhængigt af den webserver, du bruger.

Her er eksempler for almindelige webservere:

• Apache: Tilføj følgende linje til din `.htaccess` fil eller virtuelle host konfiguration:

            Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://example.com; style-src 'self' https://example.com; img-src 'self' data:;"
            

              
                Copy
              
            
          

• Nginx: Tilføj følgende linje til din server blok konfiguration:

            add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://example.com; style-src 'self' https://example.com; img-src 'self' data:;";
            

              
                Copy
              
            
          

• Node.js (Express): Brug middleware til at indstille headeren:

            app.use(function(req, res, next) {
  res.setHeader("Content-Security-Policy", "default-src 'self'; script-src 'self' https://example.com; style-src 'self' https://example.com; img-src 'self' data:;");
  next();
});
            

              
                Copy
              
            
          

Brug af <meta> Tag

For at implementere CSP ved hjælp af <meta> tagget, tilføj følgende tag til <head> sektionen af dit HTML-dokument:

            <meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' https://example.com; style-src 'self' https://example.com; img-src 'self' data:;">
            

              
                Copy
              
            
          

Vigtige overvejelser:

• `http-equiv` attributten skal være indstillet til "Content-Security-Policy".
• `content` attributten indeholder CSP-direktiverne.
• Husk begrænsningerne ved at bruge <meta> tags som nævnt tidligere.

CSP Eksempler

Her er adskillige CSP-eksempler med forklaringer:

1. Grundlæggende CSP:

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

              
                Copy
              
            
          

Denne politik tillader kun ressourcer fra samme oprindelse.

2. Tilladelse af scripts fra et specifikt domæne:

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

              
                Copy
              
            
          

Denne politik tillader ressourcer fra samme oprindelse og scripts fra `https://example.com`.

3. Tilladelse af styles fra en CDN:

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

              
                Copy
              
            
          

Denne politik tillader ressourcer fra samme oprindelse og styles fra `https://cdn.example.com`.

4. Tilladelse af billeder fra enhver kilde:

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

              
                Copy
              
            
          

Denne politik tillader ressourcer fra samme oprindelse og billeder fra enhver kilde (anbefales ikke til produktion).

5. Rapportering af CSP-overtrædelser:

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

              
                Copy
              
            
          

Denne politik tillader ressourcer fra samme oprindelse og sender overtrædelsesrapporter til `/csp-report-endpoint`. Det anbefales at bruge `report-to` i stedet for `report-uri`.

6. Brug af `report-to` og `report-uri` sammen for kompatibilitet:

            Content-Security-Policy: default-src 'self'; report-uri /csp-report-endpoint; report-to csp-endpoint;
Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report-endpoint; report-to csp-endpoint;
Report-To: {"group":"csp-endpoint","max_age":10886400,"endpoints":[{"url":"/csp-report-endpoint"}]}
            

              
                Copy
              
            
          

Dette eksempel demonstrerer opsætning af både en `report-uri` (til ældre browsere) og et `report-to` endpoint, sammen med konfiguration af selve `Report-To` headeren. Sørg for, at din server håndterer `Report-To` headeren korrekt og indstiller `group`, `max_age` og `endpoints` korrekt.

7. Brug af Nonces til Inline Scripts:

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

              
                Copy
              
            
          

Denne politik tillader ressourcer fra samme oprindelse og inline scripts med det matchende nonce-attribut.

            <script nonce="rAnd0mN0nc3Str1nG">
  // Your inline script code here
</script>
            

              
                Copy
              
            
          

CSP i Report-Only Tilstand

CSP kan implementeres i to tilstande:

• Enforce Mode: Browseren blokerer ressourcer, der overtræder CSP.
• Report-Only Mode: Browseren rapporterer CSP-overtrædelser til et specificeret endpoint uden at blokere nogen ressourcer.

Report-Only tilstand er nyttig til test og forfining af din CSP, før du håndhæver den. For at aktivere Report-Only tilstand skal du bruge `Content-Security-Policy-Report-Only` HTTP-headeren i stedet for `Content-Security-Policy` headeren.

Eksempel:

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

              
                Copy
              
            
          

Denne konfiguration sender rapporter til `/csp-report-endpoint` uden at blokere nogen ressourcer.

Bedste praksis for implementering af CSP

Her er nogle bedste praksisser for implementering af CSP effektivt:

1. Start med en streng politik: Start med en restriktiv politik, der kun tillader ressourcer fra samme oprindelse, og lemp den gradvist efter behov.
2. Brug Nonces eller Hashes til Inline Scripts og Styles: Undgå at bruge `'unsafe-inline'` og brug nonces eller hashes til at tillade specifikke inline scripts og styles.
3. Undgå `'unsafe-eval'`: Hvis det er muligt, undgå at bruge `'unsafe-eval'`, da det kan introducere sikkerhedsrisici. Overvej alternative tilgange til dynamisk kodeudførelse.
4. Brug HTTPS: Sørg for, at alle ressourcer indlæses over HTTPS for at forhindre man-in-the-middle angreb. Brug `upgrade-insecure-requests` direktivet til automatisk at opgradere usikre anmodninger.
5. Overvåg CSP-overtrædelser: Opsæt et rapporteringsendpoint til at overvåge CSP-overtrædelser og identificere potentielle sikkerhedsproblemer.
6. Test din CSP grundigt: Test din CSP i forskellige browsere og miljøer for at sikre, at den fungerer som forventet.
7. Iterer og forfin: CSP-implementering er en iterativ proces. Overvåg og forfin løbende din CSP, efterhånden som din applikation udvikler sig.
8. Overvej `strict-dynamic` direktivet: Brug `strict-dynamic` til at reducere kompleksiteten af din CSP ved at videregive tillid til scripts, der er indlæst af pålidelige scripts.

Værktøjer til CSP

Adskillige værktøjer kan hjælpe dig med at generere, teste og overvåge CSP:

• CSP Generatorer: Online værktøjer, der genererer CSP-direktiver baseret på dit websteds ressourcer.
• Browser Developer Tools: De fleste moderne browsere leverer udviklerværktøjer, der kan hjælpe dig med at analysere CSP-overtrædelser.
• CSP Monitoring Services: Tjenester, der indsamler og analyserer CSP-overtrædelsesrapporter.

CSP og Frameworks/Biblioteker

Når du bruger frameworks og biblioteker, er det vigtigt at konfigurere CSP korrekt for at sikre kompatibilitet og forhindre sikkerhedsproblemer. Her er nogle overvejelser:

• JavaScript Frameworks (f.eks. React, Angular, Vue.js): Disse frameworks bruger ofte inline styles eller dynamisk kodegenerering, hvilket kan kræve specielle CSP-konfigurationer (f.eks. nonces, hashes, `'unsafe-eval'`).
• CSS Frameworks (f.eks. Bootstrap, Tailwind CSS): Disse frameworks kan bruge inline styles eller eksterne stylesheets, som skal tillades i din CSP.
• Tredjepartsbiblioteker: Sørg for, at alle tredjepartsbiblioteker, du bruger, er kompatible med din CSP og ikke introducerer sikkerhedssårbarheder.

CSP og CDNs (Content Delivery Networks)

CDNs bruges almindeligvis til at hoste statiske aktiver såsom JavaScript-filer, CSS-stylesheets og billeder. For at tillade ressourcer fra CDN'er i din CSP skal du udtrykkeligt hvidliste CDN-domænerne.

Eksempel:

            Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.jsdelivr.net; style-src 'self' https://cdnjs.cloudflare.com;
            

              
                Copy
              
            
          

Denne politik tillader scripts fra jsDelivr og styles fra Cloudflares cdnjs.

Almindelige CSP-fejl at undgå

Her er nogle almindelige CSP-fejl at undgå:

• Brug af `*` som kilde: Tilladelse af ressourcer fra enhver kilde kan ophæve fordelene ved CSP.
• Brug af `'unsafe-inline'` og `'unsafe-eval'` uden begrundelse: Disse direktiver kan introducere sikkerhedsrisici og bør undgås, hvis det er muligt.
• Manglende overvågning af CSP-overtrædelser: Manglende overvågning af CSP-overtrædelser kan forhindre dig i at identificere og adressere sikkerhedsproblemer.
• Manglende grundig test af CSP: Utilstrækkelig test kan føre til uventet adfærd og sikkerhedssårbarheder.
• Forkert konfiguration af Nonces og Hashes: Forkert konfigurerede nonces og hashes kan forhindre legitime scripts og styles i at blive indlæst.

Avancerede CSP-koncepter

Ud over det grundlæggende kan adskillige avancerede CSP-koncepter yderligere forbedre din websikkerhed:

• `frame-ancestors` Direktiv: Angiver de tilladte forældre, der kan indlejre en frame (iframe) på din side. Beskytter mod clickjacking-angreb.
• `sandbox` Direktiv: Aktiverer en sandbox for den anmodede ressource og anvender begrænsninger på dens muligheder (f.eks. forhindrer scriptudførelse, formularindsendelse).
• `require-sri-for` Direktiv: Kræver Subresource Integrity (SRI) for scripts eller styles, der er indlæst fra eksterne kilder. SRI sikrer, at filerne ikke er blevet manipuleret.
• Trusted Types API: Hjælper med at forhindre DOM-baseret XSS ved at håndhæve typesikkerhed på DOM-sinks.

Fremtiden for CSP

CSP er i konstant udvikling for at imødegå nye sikkerhedsudfordringer. Fremtidige udviklinger kan omfatte:

• Forbedret Browsersupport: Fortsatte forbedringer i browsersupport for CSP-funktioner.
• Nye Direktiver og Funktioner: Introduktion af nye direktiver og funktioner til at imødegå nye sikkerhedstrusler.
• Integration med Sikkerhedsværktøjer: Dybere integration med sikkerhedsværktøjer og platforme til at automatisere CSP-styring og overvågning.

Konklusion

Content Security Policy (CSP) er et kraftfuldt værktøj til at afbøde XSS-angreb og forbedre websikkerheden. Ved at definere en streng CSP kan du reducere angrebsoverfladen for din webapplikation betydeligt og beskytte dine brugere mod ondsindet kode. Effektiv implementering af CSP kræver omhyggelig planlægning, grundig test og løbende overvågning. Ved at følge de bedste praksisser, der er beskrevet i denne guide, kan du udnytte CSP til at forbedre sikkerhedspositionen for dine webapplikationer og beskytte din online tilstedeværelse i det globale digitale økosystem.

Husk regelmæssigt at gennemgå og opdatere din CSP for at tilpasse dig udviklende sikkerhedstrusler og sikre, at dine webapplikationer forbliver beskyttede.