Frontend Sikkerhed: XSS Forebyggelse og Content Security Policy (CSP)

I nutidens webudviklingslandskab er frontend sikkerhed altafgørende. Efterhånden som webapplikationer bliver mere komplekse og interaktive, bliver de også mere sårbare over for forskellige angreb, især Cross-Site Scripting (XSS). Denne artikel giver en omfattende guide til at forstå og afbøde XSS-sårbarheder samt implementere Content Security Policy (CSP) som en robust forsvarsmekanisme.

Forståelse af Cross-Site Scripting (XSS)

Hvad er XSS?

Cross-Site Scripting (XSS) er en type injektionsangreb, hvor ondsindede scripts injiceres i ellers godartede og betroede websteder. XSS-angreb forekommer, 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 tillader disse angreb at lykkes, er ret udbredte og forekommer overalt, hvor en webapplikation bruger input fra en bruger i det output, den genererer, uden at validere eller kode det.

Forestil dig et populært onlineforum, hvor brugere kan sende kommentarer. Hvis forummet ikke korrekt renser brugerinput, kan en angriber injicere et ondsindet JavaScript-udklip i en kommentar. Når andre brugere ser den kommentar, udføres det ondsindede script i deres browsere og kan potentielt stjæle deres cookies, omdirigere dem til phishing-sider eller vanære webstedet.

Typer af XSS-angreb

• Reflekteret XSS: Det ondsindede script injiceres i en enkelt anmodning. Serveren læser de injicerede data fra HTTP-anmodningen og reflekterer dem tilbage til brugeren og udfører scriptet i deres browser. Dette opnås ofte gennem phishing-e-mails, der indeholder ondsindede links.
• Gemt XSS: Det ondsindede script gemmes på målserveren (f.eks. i en database, forumindlæg eller kommentarsektion). Når andre brugere får adgang til de gemte data, udføres scriptet i deres browsere. Denne type XSS er særligt farlig, fordi den kan påvirke et stort antal brugere.
• DOM-baseret XSS: Sårbarheden findes i selve JavaScript-koden på klientsiden. Angrebet manipulerer DOM (Document Object Model) i offerets browser og får det ondsindede script til at blive udført. Dette involverer ofte manipulation af URL'er eller andre data på klientsiden.

Konsekvenserne af XSS

Konsekvenserne af et vellykket XSS-angreb kan være alvorlige:

• Tyveri af cookies: Angribere kan stjæle brugercookies og få adgang til deres konti og følsomme oplysninger.
• Kapring af konti: Med stjålne cookies kan angribere udgive sig for at være brugere og udføre handlinger på deres vegne.
• Webstedets vanhelligelse: Angribere kan ændre udseendet af webstedet og sprede misinformation eller skade mærkets omdømme.
• Omdirigering til phishing-sider: Brugere kan omdirigeres til ondsindede websteder, der stjæler deres loginoplysninger eller installerer malware.
• Dataekspropriering: Følsomme data, der vises på siden, kan stjæles og sendes til angriberens server.

XSS Forebyggelsesteknikker

Forebyggelse af XSS-angreb kræver en flerlags tilgang, der fokuserer på både inputvalidering og outputkodning.

Inputvalidering

Inputvalidering er processen med at verificere, at brugerinput overholder det forventede format og den forventede datatype. Selvom det ikke er en idiotsikker beskyttelse mod XSS, hjælper det med at reducere angrebsoverfladen.

• Whitelist-validering: Definer et strengt sæt af tilladte tegn og mønstre. Afvis ethvert input, der ikke matcher whitelist. Hvis du f.eks. forventer, at en bruger skal indtaste et navn, skal du kun tillade bogstaver, mellemrum og muligvis bindestreger.
• Blacklist-validering: Identificer og bloker kendte ondsindede tegn eller mønstre. Blacklister er imidlertid ofte ufuldstændige og kan omgås af smarte angribere. Whitelist-validering foretrækkes generelt frem for blacklist-validering.
• Datatypevalidering: Sørg for, at inputtet matcher den forventede datatype (f.eks. heltal, e-mailadresse, URL).
• Længdebegrænsninger: Indfør maksimale længdegrænser for inputfelter for at forhindre bufferoverløbssårbarheder.

Eksempel (PHP):

<?php $username = $_POST['username']; // Whitelist validering: Tillad kun alfanumeriske tegn og understregninger if (preg_match('/^[a-zA-Z0-9_]+$/', $username)) { // Gyldigt brugernavn echo "Gyldigt brugernavn: " . htmlspecialchars($username, ENT_QUOTES, 'UTF-8'); } else { // Ugyldigt brugernavn echo "Ugyldigt brugernavn. Kun alfanumeriske tegn og understregninger er tilladt."; } ?>

Outputkodning (Escaping)

Outputkodning, også kendt som escaping, er processen med at konvertere specialtegn til deres HTML-enheder eller URL-kodede ækvivalenter. Dette forhindrer browseren i at fortolke tegnene som kode.

• HTML-kodning: Escape-tegn, der har særlig betydning i HTML, såsom <, >, &, " og '. Brug funktioner som htmlspecialchars() i PHP eller tilsvarende metoder i andre sprog.
• URL-kodning: Kod tegn, der har særlig betydning i URL'er, såsom mellemrum, skråstreger og spørgsmålstegn. Brug funktioner som urlencode() i PHP eller tilsvarende metoder i andre sprog.
• JavaScript-kodning: Escape-tegn, der har særlig betydning i JavaScript, såsom enkelt anførselstegn, dobbelte anførselstegn og bagudskråstreger. Brug funktioner som JSON.stringify() eller biblioteker som ESAPI (Encoder).

Eksempel (JavaScript - HTML-kodning):

function escapeHTML(str) { let div = document.createElement('div'); div.appendChild(document.createTextNode(str)); return div.innerHTML; } let userInput = '<script>alert("XSS");</script>'; let encodedInput = escapeHTML(userInput); // Output det kodede input til DOM document.getElementById('output').innerHTML = encodedInput; // Output: &lt;script&gt;alert("XSS");&lt;/script&gt;

Eksempel (Python - HTML-kodning):

import html user_input = '<script>alert("XSS");</script>' encoded_input = html.escape(user_input) print(encoded_input) # Output: &lt;script&gt;alert("XSS");&lt;/script&gt;

Kontekstafhængig kodning

Den type kodning, du bruger, afhænger af den kontekst, hvor dataene vises. Hvis du f.eks. viser data i et HTML-attribut, skal du bruge HTML-attributkodning. Hvis du viser data i en JavaScript-streng, skal du bruge JavaScript-strengkodning.

Eksempel:

<input type="text" value="<?php echo htmlspecialchars($_GET['name'], ENT_QUOTES, 'UTF-8'); ?>">

I dette eksempel vises værdien af name-parameteren fra URL'en i value-attributten for et inputfelt. Funktionen htmlspecialchars() sikrer, at alle specialtegn i name-parameteren kodes korrekt, hvilket forhindrer XSS-angreb.

Brug af en skabelonmotor

Mange moderne webframeworks og skabelonmotorer (f.eks. React, Angular, Vue.js, Twig, Jinja2) leverer automatiske outputkodningsmekanismer. Disse motorer undslipper automatisk variabler, når de gengives i skabeloner, hvilket reducerer risikoen for XSS-sårbarheder. Brug altid de indbyggede escaping-funktioner i din skabelonmotor.

Content Security Policy (CSP)

Hvad er CSP?

Content Security Policy (CSP) er et ekstra sikkerhedslag, der hjælper med at opdage og afbøde visse typer angreb, herunder Cross-Site Scripting (XSS) og datainjektionsangreb. CSP fungerer ved at lade dig definere en whitelist over kilder, som browseren må indlæse ressourcer fra. Denne whitelist kan indeholde domæner, protokoller og endda specifikke URL'er.

Som standard tillader browsere websider at indlæse ressourcer fra enhver kilde. CSP ændrer denne standardadfærd ved at begrænse de kilder, hvorfra ressourcer kan indlæses. Hvis et websted forsøger at indlæse en ressource fra en kilde, der ikke er på whitelisten, blokerer browseren anmodningen.

Hvordan CSP fungerer

CSP implementeres ved at sende en HTTP-svarhoved fra serveren til browseren. Headet indeholder en liste over direktiver, som hver især specificerer en politik for en bestemt type ressource.

Eksempel CSP-hoved:

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

Dette header definerer følgende politikker:

• default-src 'self': Tillader, at ressourcer kun indlæses fra samme oprindelse (domæne) som websiden.
• script-src 'self' https://example.com: Tillader, at JavaScript indlæses fra samme oprindelse og fra https://example.com.
• style-src 'self' https://cdn.example.com: Tillader, at CSS indlæses fra samme oprindelse og fra https://cdn.example.com.
• img-src 'self' data:: Tillader, at billeder indlæses fra samme oprindelse og fra data-URI'er (base64-kodede billeder).
• font-src 'self': Tillader, at skrifttyper indlæses fra samme oprindelse.

CSP-direktiver

Her er nogle af de mest almindeligt anvendte CSP-direktiver:

• default-src: Indstiller standardpolitikken for alle ressourcetyper.
• script-src: Definerer de kilder, hvorfra JavaScript kan indlæses.
• style-src: Definerer de kilder, hvorfra CSS kan indlæses.
• img-src: Definerer de kilder, hvorfra billeder kan indlæses.
• font-src: Definerer de kilder, hvorfra skrifttyper kan indlæses.
• connect-src: Definerer de oprindelser, som klienten kan oprette forbindelse til (f.eks. via WebSockets, XMLHttpRequest).
• media-src: Definerer de kilder, hvorfra lyd og video kan indlæses.
• object-src: Definerer de kilder, hvorfra plugins (f.eks. Flash) kan indlæses.
• frame-src: Definerer de oprindelser, der kan integreres som frames (<frame>, <iframe>).
• 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 sendes til.
• upgrade-insecure-requests: Instruerer browseren til automatisk at opgradere usikre anmodninger (HTTP) til sikre anmodninger (HTTPS).
• block-all-mixed-content: Forhindrer browseren i at indlæse blandet indhold (HTTP-indhold indlæst via HTTPS).
• report-uri: Specificerer en URL, som browseren skal sende overtrædelsesrapporter til, når en CSP-politik overtrædes.
• report-to: Specificerer et gruppenavn defineret i et `Report-To`-header, som indeholder slutpunkter til afsendelse af overtrædelsesrapporter. Mere moderne og fleksibel erstatning for `report-uri`.

CSP-kildelisteværdier

Hvert CSP-direktiv accepterer en liste over kildeværdier, der specificerer de tilladte oprindelser eller nøgleord.

• 'self': Tillader ressourcer fra samme oprindelse som websiden.
• 'none': Tillader ikke ressourcer fra alle oprindelser.
• 'unsafe-inline': Tillader inline JavaScript og CSS. Dette bør undgås, når det er muligt, da det svækker beskyttelsen mod XSS.
• 'unsafe-eval': Tillader brugen af eval() og relaterede funktioner. Dette bør også undgås, da det kan introducere sikkerhedssårbarheder.
• 'strict-dynamic': Specificerer, at den tillid, der udtrykkeligt gives til et script i markeringen, via en ledsagende nonce eller hash, skal spredes til alle scripts, der indlæses af det rodbaserede script.
• https://example.com: Tillader ressourcer fra et specifikt domæne.
• *.example.com: Tillader ressourcer fra et hvilket som helst underdomæne af et specifikt domæne.
• data:: Tillader data-URI'er (base64-kodede billeder).
• mediastream:: Tillader `mediastream:` URI'er for `media-src`.
• blob:: Tillader `blob:` URI'er (bruges til binære data, der er gemt i browserens hukommelse).
• filesystem:: Tillader `filesystem:` URI'er (bruges til at få adgang til filer, der er gemt i browserens sandkasserede filsystem).
• nonce-{random-value}: Tillader inline-scripts eller -typografier, der har et matchende nonce-attribut.
• sha256-{hash-value}: Tillader inline-scripts eller -typografier, der har en matchende sha256-hash.

Implementering af CSP

Der er flere måder at implementere CSP på:

• HTTP-header: Den mest almindelige måde at implementere CSP på er ved at indstille Content-Security-Policy HTTP-headeren i serverens svar.
• Meta-tag: CSP kan også defineres ved hjælp af et <meta>-tag i HTML-dokumentet. Denne metode er imidlertid mindre fleksibel og har nogle begrænsninger (f.eks. kan den ikke bruges til at definere frame-ancestors-direktivet).

Eksempel (Indstilling af CSP via HTTP-header - Apache):

I din Apache-konfigurationsfil (f.eks. .htaccess eller httpd.conf) skal du tilføje følgende linje:

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

Eksempel (Indstilling af CSP via HTTP-header - Nginx):

I din Nginx-konfigurationsfil (f.eks. nginx.conf) skal du tilføje følgende linje til server-blokken:

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

Eksempel (Indstilling af CSP via Meta-tag):

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

Test af CSP

Det er afgørende at teste din CSP-implementering for at sikre, at den fungerer som forventet. Du kan bruge browserudviklerværktøjer til at inspicere Content-Security-Policy-headeren og kontrollere for overtrædelser.

CSP-rapportering

Brug direktiverne `report-uri` eller `report-to` til at konfigurere CSP-rapportering. Dette giver din server mulighed for at modtage rapporter, når CSP-politikken overtrædes. Disse oplysninger kan være uvurderlige til at identificere og løse sikkerhedssårbarheder.

Eksempel (CSP med report-uri):

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

Eksempel (CSP med report-to - mere moderne):

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

Server-side-slutpunktet (`/csp-report-endpoint` i disse eksempler) skal konfigureres til at modtage og behandle disse JSON-rapporter og logge dem til senere analyse.

CSP bedste praksis

• Start med en streng politik: Begynd med en restriktiv politik, der kun tillader ressourcer fra samme oprindelse (default-src 'self'). Løsn gradvist politikken efter behov, og tilføj specifikke kilder efter behov.
• Undgå 'unsafe-inline' og 'unsafe-eval': Disse direktiver svækker beskyttelsen mod XSS markant. Prøv at undgå dem, når det er muligt. Brug noncer eller hashes til inline-scripts og -typografier, og undgå at bruge eval().
• Brug noncer eller hashes til inline-scripts og -typografier: Hvis du skal bruge inline-scripts eller -typografier, skal du bruge noncer eller hashes til at hvidliste dem.
• Brug CSP-rapportering: Konfigurer CSP-rapportering for at modtage meddelelser, når politikken overtrædes. Dette vil hjælpe dig med at identificere og rette sikkerhedssårbarheder.
• Test din CSP-implementering grundigt: Brug browserudviklerværktøjer til at inspicere Content-Security-Policy-headeren og kontrollere for eventuelle overtrædelser.
• Brug en CSP-generator: Flere onlineværktøjer kan hjælpe dig med at generere CSP-headere baseret på dine specifikke krav.
• Overvåg CSP-rapporter: Gennemgå regelmæssigt CSP-rapporter for at identificere potentielle sikkerhedsproblemer og forfine din politik.
• Hold din CSP opdateret: Efterhånden som dit websted udvikler sig, skal du sørge for at opdatere din CSP for at afspejle eventuelle ændringer i ressourceafhængigheder.
• Overvej at bruge en Content Security Policy (CSP) linter: Værktøjer som `csp-html-webpack-plugin` eller browserudvidelser kan hjælpe med at validere og optimere din CSP-konfiguration.
• Gennemfør CSP gradvist (kun rapporttilstand): Implementer oprindeligt CSP i "kun rapport"-tilstand ved hjælp af Content-Security-Policy-Report-Only-headeren. Dette giver dig mulighed for at overvåge potentielle politiske overtrædelser uden faktisk at blokere ressourcer. Analysér rapporterne for at finjustere din CSP, før du håndhæver den.

Eksempel (Nonce-implementering):

Server-side (Generer Nonce):

<?php $nonce = base64_encode(random_bytes(16)); ?>

HTML:

<script nonce="<?php echo $nonce; ?>"> // Din inline-script her console.log('Inline script med nonce'); </script>

CSP-header:

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-<?php echo $nonce; ?>';

CSP og tredjepartsbiblioteker

Når du bruger tredjepartsbiblioteker eller CDN'er, skal du sørge for at inkludere deres domæner i din CSP-politik. Hvis du f.eks. bruger jQuery fra en CDN, skal du tilføje CDN's domæne til script-src-direktivet.

Imidlertid kan det introducere sikkerhedsrisici at hvidliste hele CDN'er blindt. Overvej at bruge Subresource Integrity (SRI) til at verificere integriteten af de filer, der indlæses fra CDN'er.

Subresource Integrity (SRI)

SRI er en sikkerhedsfunktion, der gør det muligt for browsere at verificere, at filer, der hentes fra CDN'er eller andre tredjepartskilder, ikke er blevet manipuleret med. SRI fungerer ved at sammenligne en kryptografisk hash af den hentede fil med en kendt hash. Hvis hash'erne ikke stemmer overens, vil browseren blokere filen fra at indlæses.

Eksempel:

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

integrity-attributten indeholder den kryptografiske hash af jquery.min.js-filen. crossorigin-attributten er påkrævet, for at SRI kan arbejde med filer, der betjenes fra forskellige oprindelser.

Konklusion

Frontend sikkerhed er et kritisk aspekt af webudvikling. Ved at forstå og implementere XSS-forebyggelsesteknikker og Content Security Policy (CSP) kan du reducere risikoen for angreb og beskytte dine brugeres data betydeligt. Husk at anvende en flerlags tilgang, der kombinerer inputvalidering, outputkodning, CSP og andre bedste sikkerhedspraksisser. Bliv ved med at lære, og hold dig opdateret med de seneste sikkerhedstrusler og afbødningsteknikker for at opbygge sikre og robuste webapplikationer.

Denne guide giver en grundlæggende forståelse af XSS-forebyggelse og CSP. Husk, at sikkerhed er en løbende proces, og kontinuerlig læring er afgørende for at være foran potentielle trusler. Ved at implementere disse bedste praksisser kan du skabe en mere sikker og pålidelig weboplevelse for dine brugere.