Frontend Content Security Policy: Avanceret XSS-beskyttelse

I nutidens forbundne verden er sikkerheden i webapplikationer altafgørende. Cross-Site Scripting (XSS)-angreb er fortsat en vedvarende trussel, der giver angribere mulighed for at injicere ondsindede scripts på websteder, som andre brugere ser. Et af de mest effektive våben i dit arsenal mod XSS er Content Security Policy (CSP). Denne guide dykker ned i avancerede CSP-teknikker for at give robust beskyttelse til dine frontend-applikationer og sikre en mere sikker browsingoplevelse for brugere over hele verden.

Forståelse af Content Security Policy (CSP)

Content Security Policy (CSP) er en HTTP-response-header, der giver dig mulighed for at kontrollere, hvilke ressourcer en webside må indlæse. Ved at definere en CSP fortæller du browseren, hvilke oprindelser (domæner, protokoller og porte) der betragtes som sikre kilder til indhold, såsom scripts, stylesheets, billeder og skrifttyper. Når browseren støder på en ressource, der overtræder CSP'en, blokerer den ressourcen, hvilket mindsker risikoen for XSS og andre kodeinjektionsangreb.

Nøgledirektiver i CSP

CSP fungerer gennem et sæt direktiver, hvor hvert direktiv styrer et forskelligt aspekt af ressourceindlæsning. Forståelse af disse direktiver er afgørende for at implementere en effektiv CSP. Her er nogle af de vigtigste:

• default-src: Dette er fallback-direktivet for alle ressourcetyper, der ikke har et specifikt direktiv tildelt. Det er generelt god praksis at sætte dette til 'none' for at blokere alt som standard og derefter eksplicit tillade specifikke kilder.
• script-src: Dette direktiv kontrollerer de kilder, hvorfra JavaScript kan eksekveres. Dette er uden tvivl det vigtigste direktiv for at forhindre XSS-angreb.
• style-src: Dette direktiv kontrollerer de kilder, hvorfra stylesheets (CSS) kan indlæses.
• img-src: Dette direktiv kontrollerer de kilder, hvorfra billeder kan indlæses.
• font-src: Dette direktiv kontrollerer de kilder, hvorfra skrifttyper kan indlæses.
• connect-src: Dette direktiv kontrollerer de destinationer, som websiden kan foretage netværksanmodninger til (f.eks. AJAX-kald, WebSockets).
• media-src: Dette direktiv kontrollerer de kilder, hvorfra medier (lyd og video) kan indlæses.
• object-src: Dette direktiv kontrollerer de kilder, hvorfra plugins (f.eks. Flash) kan indlæses.
• frame-src / child-src: (child-src foretrækkes) Disse direktiver kontrollerer de kilder, hvorfra frames (<iframe>) kan indlæses. frame-src er forældet til fordel for child-src.
• form-action: Dette direktiv kontrollerer de URL'er, som formularindsendelser er tilladt til.

Almindelige CSP-værdier

Inden for hvert direktiv specificerer du tilladte kilder ved hjælp af forskellige værdier:

• 'none': Blokerer alle ressourcer af den pågældende type. Dette er ofte udgangspunktet for en sikker CSP.
• 'self': Tillader ressourcer fra samme oprindelse (skema, domæne og port) som siden.
• 'unsafe-inline': Tillader inline JavaScript (f.eks. hændelseshandlere som onclick) og inline CSS. Dette frarådes generelt på grund af sikkerhedsrisiciene.
• 'unsafe-eval': Tillader brug af usikre JavaScript-funktioner som eval(), new Function() og setTimeout() med et strengargument. Dette frarådes kraftigt.
• data:: Tillader indlæsning af ressourcer fra data-URI'er (f.eks. billeder indlejret direkte i HTML).
• *: Tillader alle kilder. Brug dette sparsomt, hvis overhovedet, da det alvorligt begrænser effektiviteten af CSP.
• URL'er (f.eks. https://example.com, https://*.example.com): Tillader ressourcer fra specificerede URL'er. Wildcards (*) kan bruges til underdomæner.
• nonce-value: Tillader inline scripts eller styles med et specifikt nonce-attribut. Dette er den anbefalede tilgang til at tillade inline JavaScript, når det er absolut nødvendigt. (Se afsnittet 'Nonces og Hashes').
• sha256-hashvalue, sha384-hashvalue, sha512-hashvalue: Tillader inline scripts eller styles, hvis indhold matcher et specifikt kryptografisk hash. (Se afsnittet 'Nonces og Hashes').

Implementering af en robust CSP

Implementering af en stærk CSP involverer omhyggelig planlægning og udførelse. Her er en trin-for-trin guide:

1. Vurdering og planlægning

Før du begynder, skal du forstå, hvordan din applikation fungerer. Identificer alle de ressourcer, din applikation indlæser, herunder scripts, stylesheets, billeder, skrifttyper og eventuelle eksterne tjenester, den interagerer med. Overvej din applikations arkitektur, og hvordan data flyder igennem den. En grundig dokumentation af din applikations ressourceindlæsningsadfærd er afgørende.

Eksempel: En global e-handelsplatform kan indlæse scripts fra sit eget domæne (f.eks. www.example.com), content delivery networks (CDN'er) som Cloudflare eller Akamai og potentielt tredjepartstjenester til analyse eller betalingsbehandling. Planen skal tage højde for alle disse kilder, også dem der stammer fra forskellige lande eller regioner.

2. Start med en restriktiv politik (Standard 'none')

Den bedste praksis er at starte med en meget restriktiv politik og gradvist lempe den efter behov. Begynd med default-src 'none'; script-src 'self'; style-src 'self'; img-src 'self';. Denne politik blokerer alt som standard og tillader kun, at scripts, styles og billeder indlæses fra samme oprindelse. Dette giver øjeblikkeligt et stærkt grundlæggende beskyttelsesniveau.

Eksempel:

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

              
                Copy
              
            
          

3. Identificering af eksterne ressourcer

Identificer derefter alle eksterne ressourcer, din applikation bruger. Dette inkluderer CDN'er, tredjeparts-API'er og alle andre domæner, hvorfra din applikation indlæser aktiver. Gennemgå din HTML-kildekode og netværkstrafik for at afdække alle eksterne afhængigheder.

Eksempel: Din applikation bruger måske Google Fonts, et JavaScript-bibliotek hostet på et CDN og et API fra en betalingsgateway. Dokumenter disse eksterne kilder sammen med de specifikke protokoller og porte, der bruges.

4. Lempelse af politikken trinvist

For hver ekstern ressource skal du tilføje det passende direktiv og kilde til din CSP. Hvis du f.eks. bruger et CDN, skal du tillade det CDN i dine script-src og/eller style-src direktiver. Vær så specifik som muligt. Undgå at bruge wildcards, medmindre det er nødvendigt. Test din applikation grundigt efter hver ændring for at sikre, at den fortsat fungerer korrekt, og at CSP'en effektivt blokerer ondsindede ressourcer.

Eksempel: Hvis din applikation bruger Google Fonts, kan du tilføje font-src https://fonts.gstatic.com; og style-src https://fonts.googleapis.com; til din CSP. Hvis du bruger et CDN, som cdn.example.com, så tilføj script-src cdn.example.com; style-src cdn.example.com;.

5. Implementering og testning

Når du har etableret din CSP, skal du implementere den i dit produktionsmiljø. Test den grundigt i forskellige browsere og på forskellige enheder. Brug browserudviklerværktøjer og sikkerhedstestværktøjer til at identificere eventuelle overtrædelser. Revider og opdater regelmæssigt din CSP, efterhånden som din applikation udvikler sig.

6. Overvågning for overtrædelser

Implementer en mekanisme til at overvåge CSP-overtrædelser. Når en browser blokerer en ressource på grund af en CSP-overtrædelse, sender den en rapport, som du kan analysere. Du kan konfigurere denne rapportering ved hjælp af direktiverne report-uri eller report-to.

report-uri: Dette direktiv specificerer en URL, som browseren skal sende rapporter til, når en CSP-overtrædelse opstår. Dette direktiv er nu forældet til fordel for report-to.

report-to: Dette direktiv specificerer en liste over rapporteringsendepunkter, som browseren skal sende rapporter til. Dette giver mere fleksibilitet i håndteringen af rapporter og er den moderne anbefalede tilgang.

Eksempel (report-to):

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

<?php
  $nonce = bin2hex(random_bytes(16)); // Generate a random nonce
  header("Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{$nonce}'; style-src 'self' 'nonce-{$nonce}';");
?>
<script nonce="">
  // Your inline JavaScript code
</script>

            

              
                Copy
              
            
          

2. Strict-Dynamic

Kildeværdien 'strict-dynamic' er en mere avanceret tilgang. Den tillader scripts at indlæse andre scripts dynamisk, så længe det oprindelige script, der indlæser de andre scripts, er tilladt. Dette kan være nyttigt for frameworks og biblioteker, der indlæser scripts dynamisk. Brug dette med forsigtighed og kun hvis du fuldt ud forstår dets implikationer.

Sådan fungerer det: Når 'strict-dynamic' bruges med script-src, stoler browseren på scripts, der indlæses via et betroet script. Ethvert script, der tilføjes dynamisk af et betroet script, vil også blive tilladt. Det oprindelige betroede script skal indlæses via en anden mekanisme, såsom en nonce eller hash.

Eksempel:

            Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{{ nonce }}' 'strict-dynamic';
            

              
                Copy
              
            
          

I dette eksempel er det kun scriptet med noncen, der oprindeligt er betroet. Men alle scripts, som dette script indlæser dynamisk, vil også blive betroet.

3. Trusted Types

Trusted Types er en browserfunktion, der giver dig mulighed for at forhindre DOM-baserede XSS-angreb ved at håndhæve en streng API til oprettelse og håndtering af potentielt farlige data. Den erstatter muligheden for direkte at oprette HTML fra strenge. Det kræver, at du omdanner usikre strenge til 'betroede' objekter ved hjælp af 'sanitizers'. Dette beskytter mod DOM-baserede XSS-sårbarheder i frameworks og biblioteker.

Sådan fungerer Trusted Types:

1. Definer en politik.
2. Registrer politikker for specifikke handlinger (f.eks. `innerHTML`).
3. Brug en sanitizer til at rense data, før det tildeles til en DOM-egenskab.

Eksempel (Konceptuelt):

            // Create a TrustedType policy
const policy = trustedTypes.createPolicy('myPolicy', {
    createHTML: (string) => { //Sanitizer. Return a trustedHTML object.
        // Sanitize the HTML string before returning a trusted type
        return string;
    }
});

// Use the policy to set the innerHTML
document.body.innerHTML = policy.createHTML("<img src='x' onerror='alert(1)'>");

            

              
                Copy
              
            
          

I øjeblikket er browserunderstøttelsen for Trusted Types relativt begrænset, men det er en effektiv defensiv foranstaltning mod DOM-baserede XSS, når den bruges korrekt. Implementering af trusted types kan reducere angrebsfladen betydeligt.

4. Rapportering af overtrædelser (report-to / report-uri)

Opsætning af korrekt overtrædelsesrapportering er afgørende for at overvåge og vedligeholde din CSP. Brug report-to (foretrukket) eller report-uri til at sende overtrædelsesrapporter til et endepunkt, som du kontrollerer. Disse rapporter giver værdifuld indsigt i potentielle XSS-angreb og fejlkonfigurationer.

Sådan bruges rapportering:

1. Indstil report-to- eller report-uri-direktivet.
   • report-to: er den foretrukne tilgang. Specificer det endepunkt, hvor overtrædelsesrapporter vil blive sendt.
   • report-uri: er en forældet metode, der specificerer URL'en for rapporteringsendepunktet.
2. Indstil HTTP-headeren Content-Security-Policy-Report-Only (eller det tilsvarende meta-tag): Brug denne header i starten til at overvåge overtrædelser uden at blokere ressourcer. Dette giver dig mulighed for at identificere og rette problemer, før du håndhæver CSP'en i dit produktionsmiljø.
3. Opret et rapporteringsendepunkt. Du kan bygge en simpel server-side-applikation (f.eks. ved hjælp af Node.js, Python eller PHP) til at modtage og behandle rapporterne. Eller brug en tredjepartstjeneste til overvågning.
4. Analyser rapporterne. Undersøg overtrædelsesdetaljerne, herunder den blokerede URI, det overtrådte direktiv og kilden til scriptet. Disse oplysninger kan hjælpe dig med at identificere og rette XSS-sårbarheder og fejlkonfigurationer.

5. CSP i Meta-tags (Kun rapportering og håndhævelse)

CSP kan leveres på to måder: som en HTTP-header eller som et <meta>-tag i din HTML.

• HTTP-header: Den anbefalede metode, at levere CSP som en HTTP-header, er generelt mere sikker, fordi den anvendes, før sidens indhold parses. Dette forhindrer potentielle omgåelser, der er mulige med <meta>-tags.
• <meta>-tag: Du kan også inkludere CSP ved hjælp af et <meta>-tag i din HTML's <head>-sektion. Attributten http-equiv specificerer typen af politik. For eksempel: <meta http-equiv="Content-Security-Policy" content="...">.

<meta>-tagget tilbyder attributten `Content-Security-Policy-Report-Only` til at implementere CSP'en i kun-rapporteringstilstand. Dette giver dig mulighed for at overvåge overtrædelser uden at blokere noget.

Kun-rapporteringstilstand (Anbefales til indledende implementering):

            <meta http-equiv="Content-Security-Policy-Report-Only" content="default-src 'self'; script-src 'self' https://example.com; report-to csp-reports;">
            

              
                Copy
              
            
          

Denne tilstand giver dig mulighed for at indsamle overtrædelsesrapporter uden at påvirke din hjemmesides funktionalitet. Du kan bruge den til at teste din CSP og identificere eventuelle problemer, før du håndhæver den i produktion. Gennemgå overtrædelsesrapporter, juster din CSP efter behov, og skift derefter til `Content-Security-Policy`-headeren for håndhævelse.

6. CSP med Web Application Firewalls (WAF'er)

En Web Application Firewall (WAF) giver et ekstra lag af sikkerhed for dine webapplikationer. WAF'er kan bruges til at opdage og blokere ondsindet trafik, herunder XSS-angreb. Du kan konfigurere din WAF til at arbejde sammen med din CSP for at forbedre din sikkerhedsposition.

Hvordan WAF'er og CSP kan arbejde sammen:

1. WAF som første forsvarslinje: En WAF kan filtrere ondsindede anmodninger, før de når din applikation. Den kan identificere og blokere kendte XSS-angrebsmønstre.
2. CSP som anden forsvarslinje: CSP giver et ekstra lag af beskyttelse ved at begrænse, hvilke ressourcer en side kan indlæse, selv hvis ondsindet indhold formår at omgå WAF'en.
3. Integration med CSP-rapporter: Nogle WAF'er kan integreres med CSP-overtrædelsesrapporter. De kan advare dig om potentielle angreb og give detaljerede oplysninger om angrebets art.

Bedste praksis og handlingsorienterede indsigter

• Start restriktivt: Begynd med en meget restriktiv CSP (f.eks. default-src 'none';). Dette minimerer angrebsfladen.
• Test grundigt: Test din CSP omhyggeligt i alle større browsere og på forskellige enheder, før du implementerer i produktion. Brug både manuel test og automatiserede testværktøjer.
• Overvåg overtrædelser: Overvåg og analyser regelmæssigt CSP-overtrædelsesrapporter for at identificere og håndtere sikkerhedsproblemer. Opsæt automatiske alarmer for at blive underrettet om eventuelle potentielle angreb.
• Hold den opdateret: Efterhånden som din applikation udvikler sig, skal du opdatere din CSP for at afspejle ændringer i dine ressourceindlæsningsmønstre. Hold dig ajour med bedste praksis for sikkerhed.
• Undgå 'unsafe-inline' og 'unsafe-eval': Disse værdier svækker din CSP betydeligt og bør undgås. Brug altid nonces eller hashes til inline scripts/styles.
• Brug kun-rapporteringstilstand i starten: Når du implementerer en ny CSP eller foretager betydelige ændringer, skal du bruge kun-rapporteringstilstand til at teste politikken og identificere potentielle problemer, før du håndhæver den.
• Overvej tredjepartstjenester: Brug tjenester (såsom Sentry, Report URI eller Cloudflare) til at hjælpe med CSP-rapportering og -analyse. Dette kan forenkle processen og give værdifuld indsigt.
• Uddan dit team: Sørg for, at dit udviklingsteam forstår vigtigheden af CSP og følger sikre kodningspraksisser for at minimere risikoen for XSS-sårbarheder. Træn dine udviklere i bedste praksis for sikker kodning og XSS-forebyggelsesteknikker.
• Implementer sikkerhedsrevisioner: Udfør regelmæssigt sikkerhedsrevisioner for at identificere sårbarheder og vurdere effektiviteten af din CSP.
• Brug automatisering: Automatiser processen med at generere nonces og hashes. Integrer CSP-testning i din CI/CD-pipeline.

Globale overvejelser

Når du implementerer CSP for et globalt publikum, skal du overveje følgende:

• Ydeevne: Minimer virkningen af CSP på webstedets ydeevne. Brug effektive ressourceindlæsningsteknikker og optimer din CSP for at undgå unødvendige restriktioner. Vælg geografisk distribuerede CDN'er for aktiver.
• Lokalisering: Sørg for, at din CSP ikke forstyrrer lokaliseret indhold eller ressourcer. Hvis du f.eks. bruger et CDN til oversat indhold, skal du sørge for at inkludere det CDN i din CSP.
• Tilgængelighed: Test din CSP for at sikre, at den ikke påvirker tilgængeligheden negativt for brugere med handicap.
• Regionale reguleringer: Vær opmærksom på databeskyttelsesregler i forskellige regioner. For eksempel kan den generelle forordning om databeskyttelse (GDPR) i Den Europæiske Union og California Consumer Privacy Act (CCPA) i USA påvirke, hvordan du indsamler og behandler brugerdata, hvilket kan påvirke din CSP-konfiguration.
• Mobile brugere: Test din CSP på mobile enheder og i browsere for at sikre, at den giver tilstrækkelig beskyttelse og ikke hæmmer den mobile brugeroplevelse. Mobile enheder og browsere håndterer ofte CSP lidt forskelligt, så grundig test er afgørende.

Konklusion

Implementering af en avanceret Content Security Policy er et afgørende skridt i at beskytte dine webapplikationer mod XSS-angreb. Ved at starte med en restriktiv politik, omhyggeligt konfigurere direktiver og bruge teknikker som nonces, hashes og rapportering kan du reducere din angrebsflade betydeligt og forbedre sikkerheden for din globale webtilstedeværelse. Husk at teste din CSP grundigt, overvåge for overtrædelser og løbende opdatere din politik, efterhånden som din applikation udvikler sig. Ved at vedtage disse bedste praksisser kan du beskytte dine brugere og bevare tilliden til dit brand, uanset deres placering eller baggrund.