Implementering af Web Security Headers: JavaScript Content Security Policy (CSP)

I nutidens digitale landskab er websikkerhed altafgørende. At beskytte dit website og dets brugere mod ondsindede angreb er ikke længere valgfrit, men en nødvendighed. Cross-Site Scripting (XSS) er fortsat en udbredt trussel, og et af de mest effektive forsvar er at implementere en stærk Content Security Policy (CSP). Denne guide fokuserer på at udnytte JavaScript til at administrere og implementere CSP, hvilket giver en dynamisk og fleksibel tilgang til at sikre dine webapplikationer globalt.

Hvad er Content Security Policy (CSP)?

Content Security Policy (CSP) er en HTTP response header, der giver dig mulighed for at kontrollere de ressourcer, som brugeragenten (browseren) har tilladelse til at indlæse for en given side. I bund og grund fungerer det som en hvidliste, der definerer de oprindelser, hvorfra scripts, stylesheets, billeder, skrifttyper og andre ressourcer kan indlæses. Ved eksplicit at definere disse kilder kan du markant reducere dit websites angrebsflade, hvilket gør det meget sværere for angribere at injicere ondsindet kode og udføre XSS-angreb. Det er et vigtigt lag i et dybdegående forsvar.

Hvorfor bruge JavaScript til implementering af CSP?

Selvom CSP kan konfigureres direkte i din webservers konfiguration (f.eks. Apaches .htaccess eller Nginxs konfigurationsfil), giver brugen af JavaScript flere fordele, især i komplekse eller dynamiske applikationer:

• Dynamisk generering af politikker: JavaScript giver dig mulighed for dynamisk at generere CSP-politikker baseret på brugerroller, applikationens tilstand eller andre runtime-betingelser. Dette er især nyttigt i single-page applications (SPA'er) eller applikationer, der i høj grad er afhængige af client-side rendering.
• Nonce-baseret CSP: Brugen af nonces (kryptografisk tilfældige engangstokens) er en yderst effektiv måde at sikre inline scripts og styles på. JavaScript kan generere disse nonces og tilføje dem til både CSP-headeren og de inline script/style-tags.
• Hash-baseret CSP: For statiske inline scripts eller styles kan du bruge hashes til at hvidliste specifikke kodestykker. JavaScript kan beregne disse hashes og inkludere dem i CSP-headeren.
• Fleksibilitet og kontrol: JavaScript giver dig finkornet kontrol over CSP-headeren, så du kan ændre den løbende baseret på specifikke applikationsbehov.
• Debugging og rapportering: JavaScript kan bruges til at opfange rapporter om CSP-overtrædelser og sende dem til en central logningsserver for analyse, hvilket hjælper dig med at identificere og rette sikkerhedsproblemer.

Opsætning af din JavaScript CSP

Den generelle tilgang involverer at generere en CSP-header-streng i JavaScript og derefter sætte den relevante HTTP response header på serversiden (normalt via dit backend-framework). Vi vil se på specifikke eksempler for forskellige scenarier.

1. Generering af Nonces

En nonce (number used once) er en tilfældigt genereret, unik værdi, der bruges til at hvidliste specifikke inline scripts eller styles. Sådan kan du generere en nonce i JavaScript:

            function generateNonce() {
  const crypto = window.crypto || window.msCrypto; // Til IE-understøttelse
  if (!crypto || !crypto.getRandomValues) {
    // Fallback for ældre browsere uden crypto API
    return Math.random().toString(36).substring(2, 15) + Math.random().toString(36).substring(2, 15);
  }
  const arr = new Uint32Array(1);
  crypto.getRandomValues(arr);
  return btoa(String.fromCharCode.apply(null, new Uint8Array(arr.buffer)));
}

const nonce = generateNonce();
console.log("Generated Nonce:", nonce);

            

              
                Copy
              
            
          

Dette kodestykke genererer en kryptografisk sikker nonce ved hjælp af browserens indbyggede crypto API (hvis tilgængelig) og falder tilbage på en mindre sikker metode, hvis API'en ikke understøttes. Den genererede nonce bliver derefter base64-kodet til brug i CSP-headeren.

2. Indsættelse af Nonces i Inline Scripts

Når du har en nonce, skal du indsætte den i både CSP-headeren og <script>-tagget:

HTML:

            <script nonce="DIN_NONCE_HER">
  // Din inline script-kode her
  console.log("Hej fra inline script!");
</script>
            

              
                Copy
              
            
          

JavaScript (Backend):

            const nonce = generateNonce();
const cspHeader = `default-src 'self'; script-src 'self' 'nonce-${nonce}' 'strict-dynamic' 'unsafe-inline'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests;`;

// Eksempel med Node.js og Express:
app.use((req, res, next) => {
  res.setHeader('Content-Security-Policy', cspHeader);
  // Send nonce til view- eller template-motoren
  res.locals.nonce = nonce;
  next();
});

            

              
                Copy
              
            
          

Vigtige bemærkninger:

• Erstat DIN_NONCE_HER i HTML'en med den faktisk genererede nonce. Dette gøres ofte på serversiden ved hjælp af en templating-motor. Eksemplet ovenfor illustrerer, hvordan nonce sendes til templating-motoren.
• script-src-direktivet i CSP-headeren indeholder nu 'nonce-${nonce}', hvilket tillader scripts med den matchende nonce at blive eksekveret.
• 'strict-dynamic' er tilføjet til `script-src`-direktivet. Dette direktiv fortæller browseren, at den skal stole på scripts, der indlæses af betroede scripts. Hvis et script-tag har en gyldig nonce, vil ethvert script, det indlæser dynamisk (f.eks. ved hjælp af `document.createElement('script')`), også blive betroet. Dette reducerer behovet for at hvidliste adskillige individuelle domæner og CDN-URL'er og forenkler i høj grad vedligeholdelsen af CSP.
• 'unsafe-inline' frarådes generelt, når man bruger nonces, da det svækker CSP'en. Det er dog inkluderet her til demonstrationsformål og bør fjernes i produktion. Fjern dette, så snart du kan.

3. Generering af Hashes for Inline Scripts

For statiske inline scripts, der sjældent ændres, kan du bruge hashes i stedet for nonces. En hash er en kryptografisk digest af scriptets indhold. Hvis scriptets indhold ændres, vil hashen ændre sig, og browseren vil blokere scriptet.

Beregning af Hash:

Du kan bruge online-værktøjer eller kommandolinjeværktøjer som OpenSSL til at generere SHA256-hashen af dit inline script. For eksempel:

            openssl dgst -sha256 -binary your_script.js | openssl base64
            

              
                Copy
              
            
          

Eksempel:

Lad os sige, at dit inline script er:

            <script>
  console.log("Hej fra inline script!");
</script>
            

              
                Copy
              
            
          

SHA256-hashen af dette script (uden <script>-tags) kunne være:

            sha256-DIN_HASH_HER
            

              
                Copy
              
            
          

CSP Header:

            const cspHeader = `default-src 'self'; script-src 'self' 'sha256-DIN_HASH_HER'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests;`;
            

              
                Copy
              
            
          

Erstat DIN_HASH_HER med den faktiske SHA256-hash af dit script-indhold.

Vigtige overvejelser for Hashes:

• Hashen skal beregnes på det præcise indhold af scriptet, inklusive whitespace. Enhver ændring i scriptet, selv et enkelt tegn, vil ugyldiggøre hashen.
• Hashes er bedst egnet til statiske scripts, der sjældent ændres. For dynamiske scripts er nonces en bedre mulighed.

4. Sætning af CSP Header på Serveren

Det sidste trin er at sætte Content-Security-Policy HTTP response headeren på din server. Den nøjagtige metode afhænger af din server-side-teknologi.

Node.js med Express:

            app.use((req, res, next) => {
  const nonce = generateNonce();
  const cspHeader = `default-src 'self'; script-src 'self' 'nonce-${nonce}' 'strict-dynamic' 'unsafe-inline'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests;`;
  res.setHeader('Content-Security-Policy', cspHeader);
  res.locals.nonce = nonce; // Gør nonce tilgængelig for templates
  next();
});
            

              
                Copy
              
            
          

Python med Flask:

            from flask import Flask, make_response, render_template, g
import os
import base64

app = Flask(__name__)

def generate_nonce():
    return base64.b64encode(os.urandom(16)).decode('utf-8')

@app.before_request
def before_request():
    g.nonce = generate_nonce()

@app.after_request
def after_request(response):
    csp = "default-src 'self'; script-src 'self' 'nonce-{nonce}' 'strict-dynamic' 'unsafe-inline'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests".format(nonce=g.nonce)
    response.headers['Content-Security-Policy'] = csp
    return response

@app.route('/')
def index():
    return render_template('index.html', nonce=g.nonce)

            

              
                Copy
              
            
          

PHP:

            <?php
function generateNonce() {
  return base64_encode(random_bytes(16));
}

$nonce = generateNonce();
header("Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-" . $nonce . "' 'strict-dynamic' 'unsafe-inline'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests");
?>
<!DOCTYPE html>
<html>
<head>
  <title>CSP Eksempel</title>
</head>
<body>
  <script nonce="<?php echo htmlspecialchars($nonce, ENT_QUOTES, 'UTF-8'); ?>">
    console.log("Hej fra inline script!");
  </script>
</body>
</html>
            

              
                Copy
              
            
          

Apache (.htaccess):

Selvom det ikke anbefales til dynamisk CSP, *kan* du sætte en statisk CSP ved hjælp af .htaccess:

            <IfModule mod_headers.c>
  Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests;"
</IfModule>
            

              
                Copy
              
            
          

Nginx:

            add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests;";
            

              
                Copy
              
            
          

Vigtige bemærkninger:

• Erstat 'self' med det/de faktiske domæne(r), hvorfra du vil tillade, at ressourcer indlæses.
• Vær yderst forsigtig, når du bruger 'unsafe-inline' og 'unsafe-eval'. Disse direktiver svækker CSP markant og bør undgås, når det er muligt.
• Brug upgrade-insecure-requests til automatisk at opgradere alle HTTP-anmodninger til HTTPS.
• Overvej at bruge report-uri eller report-to til at specificere et endepunkt for modtagelse af rapporter om CSP-overtrædelser.

CSP-direktiver forklaret

CSP bruger direktiver til at specificere de tilladte kilder for forskellige typer ressourcer. Her er en kort oversigt over nogle af de mest almindelige direktiver:

• default-src: Angiver standardkilden for alle ressourcer, der ikke eksplicit er dækket af andre direktiver.
• script-src: Angiver de tilladte kilder for JavaScript.
• style-src: Angiver de tilladte kilder for stylesheets.
• img-src: Angiver de tilladte kilder for billeder.
• font-src: Angiver de tilladte kilder for skrifttyper.
• media-src: Angiver de tilladte kilder for lyd og video.
• object-src: Angiver de tilladte kilder for plugins (f.eks. Flash). Generelt bør du sætte dette til 'none' for at deaktivere plugins.
• frame-src: Angiver de tilladte kilder for frames og iframes.
• connect-src: Angiver de tilladte kilder for XMLHttpRequest, WebSocket og EventSource-forbindelser.
• base-uri: Angiver de tilladte base-URI'er for dokumentet.
• form-action: Angiver de tilladte endepunkter for formularafsendelser.
• upgrade-insecure-requests: Instruerer brugeragenten om at behandle alle et sites usikre URL'er (dem, der serveres over HTTP), som om de var blevet erstattet med sikre URL'er (dem, der serveres over HTTPS). Dette direktiv er beregnet til websites, der er fuldt migreret til HTTPS.
• report-uri: Angiver en URI, som browseren skal sende rapporter om CSP-overtrædelser til. Dette direktiv er forældet til fordel for `report-to`.
• report-to: Angiver et navngivet endepunkt, som browseren skal sende rapporter om CSP-overtrædelser til.

Nøgleord for CSP-kildelister

Hvert direktiv bruger en kildeliste til at specificere de tilladte kilder. Kildelisten kan indeholde følgende nøgleord:

• 'self': Tillader ressourcer fra samme oprindelse (skema, vært og port).
• 'none': Tillader ikke ressourcer fra nogen oprindelse.
• 'unsafe-inline': Tillader inline scripts og styles. Undgå dette, når det er muligt.
• 'unsafe-eval': Tillader brugen af eval() og relaterede funktioner. Undgå dette, når det er muligt.
• 'strict-dynamic': Specificerer, at den tillid, browseren giver et script på siden på grund af en ledsagende nonce eller hash, skal udbredes til de scripts, der indlæses af det script.
• 'data:': Tillader ressourcer indlæst via data:-skemaet (f.eks. inline billeder). Brug med forsigtighed.
• 'mediastream:': Tillader ressourcer indlæst via mediastream:-skemaet.
• https:: Tillader ressourcer indlæst over HTTPS.
• http:: Tillader ressourcer indlæst over HTTP. Generelt frarådet.
• *: Tillader ressourcer fra enhver oprindelse. Undgå dette; det modvirker formålet med CSP.

Rapportering af CSP-overtrædelser

Rapportering af CSP-overtrædelser er afgørende for at overvåge og debugge din CSP. Når en ressource overtræder CSP'en, kan browseren sende en rapport til en specificeret URI.

Opsætning af et Rapportendepunkt:

Du skal bruge et server-side endepunkt til at modtage og behandle rapporter om CSP-overtrædelser. Rapporten sendes som en JSON-payload.

Eksempel (Node.js med Express):

            app.post('/csp-report', (req, res) => {
  console.log('Rapport om CSP-overtrædelse:', req.body);
  // Behandl rapporten (f.eks. log til en fil eller database)
  res.status(204).end(); // Svar med en 204 No Content-status
});
            

              
                Copy
              
            
          

Konfiguration af report-uri eller report-to-direktivet:

Tilføj report-uri eller `report-to`-direktivet til din CSP-header. `report-uri` er forældet, så foretræk at bruge `report-to`.

            const cspHeader = `default-src 'self'; script-src 'self' 'nonce-${nonce}' 'strict-dynamic'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests; report-to csp-endpoint;`;
            

              
                Copy
              
            
          

Du skal også konfigurere et Reporting API-endepunkt ved hjælp af `Report-To`-headeren.

            Report-To: { "group": "csp-endpoint", "max_age": 10886400, "endpoints": [{"url": "/csp-report"}], "include_subdomains": true }
            

              
                Copy
              
            
          

Bemærk:

• `Report-To`-headeren skal sættes på hver anmodning til din server, ellers kan browseren kassere konfigurationen.
• `report-uri` er mindre sikker end `report-to`, fordi den ikke tillader TLS-kryptering af rapporten, og den er forældet, så foretræk at bruge `report-to`.

Eksempel på rapport om CSP-overtrædelse (JSON):

            {
  "csp-report": {
    "document-uri": "https://example.com/page.html",
    "referrer": "",
    "violated-directive": "script-src 'self' 'nonce-DIN_NONCE_HER'",
    "effective-directive": "script-src",
    "original-policy": "default-src 'self'; script-src 'self' 'nonce-DIN_NONCE_HER'; object-src 'none'; base-uri 'self'; upgrade-insecure-requests; report-uri /csp-report;",
    "blocked-uri": "https://evil.com/malicious.js",
    "status-code": 200,
    "script-sample": ""
  }
}
            

              
                Copy
              
            
          

Ved at analysere disse rapporter kan du identificere og rette CSP-overtrædelser, hvilket sikrer, at dit website forbliver sikkert.

Bedste praksis for implementering af CSP

• Start med en restriktiv politik: Begynd med en politik, der kun tillader ressourcer fra din egen oprindelse, og løsn den gradvist efter behov.
• Brug nonces eller hashes til inline scripts og styles: Undgå at bruge 'unsafe-inline', når det er muligt.
• Brug 'strict-dynamic' for at forenkle vedligeholdelsen af CSP.
• Undgå at bruge 'unsafe-eval': Hvis du har brug for at bruge eval(), overvej alternative tilgange.
• Brug upgrade-insecure-requests: Opgrader automatisk alle HTTP-anmodninger til HTTPS.
• Implementer rapportering af CSP-overtrædelser: Overvåg din CSP for overtrædelser og ret dem hurtigt.
• Test din CSP grundigt: Brug browserens udviklerværktøjer til at identificere og løse eventuelle CSP-problemer.
• Brug en CSP-validator: Online-værktøjer kan hjælpe dig med at validere din CSP-headersyntaks og identificere potentielle problemer.
• Overvej at bruge et CSP-framework eller -bibliotek: Flere frameworks og biblioteker kan hjælpe dig med at forenkle implementering og administration af CSP.
• Gennemgå din CSP regelmæssigt: I takt med at din applikation udvikler sig, kan din CSP have brug for at blive opdateret.
• Uddan dit team: Sørg for, at dine udviklere forstår CSP og dens betydning.
• Implementer CSP i etaper: Start med at implementere CSP i report-only-tilstand for at overvåge overtrædelser uden at blokere ressourcer. Når du er sikker på, at din politik er korrekt, kan du aktivere den i håndhævelsestilstand.
• Dokumenter din CSP: Før en optegnelse over din CSP-politik og begrundelserne bag hvert direktiv.
• Vær opmærksom på browserkompatibilitet: Understøttelse af CSP varierer på tværs af forskellige browsere. Test din CSP på forskellige browsere for at sikre, at den fungerer som forventet.
• Prioriter sikkerhed: CSP er et stærkt værktøj til at forbedre websikkerhed, men det er ikke en mirakelkur. Brug det i kombination med andre bedste praksisser for sikkerhed for at beskytte dit website mod angreb.
• Overvej at bruge en Web Application Firewall (WAF): En WAF kan hjælpe dig med at håndhæve CSP-politikker og beskytte dit website mod andre typer angreb.

Almindelige udfordringer ved implementering af CSP

• Tredjeparts-scripts: At identificere og hvidliste alle de domæner, der kræves af tredjeparts-scripts, kan være en udfordring. Brug `strict-dynamic`, hvor det er muligt.
• Inline styles og event handlers: Konvertering af inline styles og event handlers til eksterne stylesheets og JavaScript-filer kan være tidskrævende.
• Browserkompatibilitetsproblemer: Understøttelse af CSP varierer på tværs af forskellige browsere. Test din CSP på forskellige browsere for at sikre, at den fungerer som forventet.
• Vedligeholdelsesomkostninger: At holde din CSP opdateret, efterhånden som din applikation udvikler sig, kan være en udfordring.
• Ydelsespåvirkning: CSP kan introducere en lille ydelsesomkostning på grund af behovet for at validere ressourcer mod politikken.

Globale overvejelser for CSP

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

• CDN-udbydere: Hvis du bruger CDN'er, skal du sørge for at hvidliste de relevante CDN-domæner. Mange CDN'er tilbyder regionale endepunkter; brugen af disse kan forbedre ydeevnen for brugere i forskellige geografiske placeringer.
• Sprogspecifikke ressourcer: Hvis dit website understøtter flere sprog, skal du sikre, at du hvidlister de nødvendige ressourcer for hvert sprog.
• Regionale regulativer: Vær opmærksom på eventuelle regionale regulativer, der kan påvirke dine CSP-krav.
• Tilgængelighed: Sørg for, at din CSP ikke utilsigtet blokerer ressourcer, der er nødvendige for tilgængelighedsfunktioner.
• Test på tværs af regioner: Test din CSP i forskellige geografiske regioner for at sikre, at den fungerer som forventet for alle brugere.

Konklusion

Implementering af en robust Content Security Policy (CSP) er et afgørende skridt i at sikre dine webapplikationer mod XSS-angreb og andre trusler. Ved at udnytte JavaScript til dynamisk at generere og administrere din CSP kan du opnå en højere grad af fleksibilitet og kontrol, hvilket sikrer, at dit website forbliver sikkert og beskyttet i nutidens konstant udviklende trusselslandskab. Husk at følge bedste praksis, teste din CSP grundigt og løbende overvåge den for overtrædelser. Sikker kodning, dybdegående forsvar og en velimplementeret CSP er nøglen til at levere sikker browsing for et globalt publikum.