Hvad er Cross-Site Scripting (XSS) og hvordan forhindrer du det?

Question

Accepted Answer

**Cross-Site Scripting (XSS)** er en sårbarhed, hvor en angriber injicerer ondsindede **JavaScript** på en webside, som andre brugere ser — kørt i deres browsere for at stjæle data, kapre sessioner eller udføre handlinger som dem. Det er en almindelig, farlig webudbyder-sårbarhed, der kan forhindres med korrekt output-håndtering. ## Hvordan XSS fungerer ```text When user input is rendered into a page WITHOUT proper escaping, injected SCRIPTS run: ``` ```html

Welcome, <%= userInput %>

``` Det injicerede script køres i ofres browsers **som om det kom fra det pålidelige site** — hvilket lader angribere stjæle sessionscookies/tokens, kapre konti, opfange tastetryk eller udføre handlinger som brugeren. ## Typer af XSS ```text STORED → malicious script SAVED on the server (e.g. in a comment) → served to all viewers REFLECTED → script in a request (e.g. a URL parameter) reflected back in the response DOM-based → client-side JS unsafely puts untrusted data into the DOM ``` ## Forebyggelse ```text ✓ ESCAPE/ENCODE output → render user data as TEXT, not HTML (the key defense): → frameworks (React, Angular, Vue) auto-escape by default → use them properly → escape based on context (HTML, attribute, JS, URL) ✓ AVOID dangerous APIs → innerHTML, dangerouslySetInnerHTML, eval with untrusted data ✓ SANITIZE HTML if you must allow it (e.g. DOMPurify for rich text) ✓ Content Security Policy (CSP) → restricts what scripts can run (defense in depth) ✓ HttpOnly cookies → JS can't read them (limits cookie theft via XSS) ``` ## Hvorfor det betyder noget At forstå XSS og hvordan man forhindrer det er vigtig, fordi det er en **almindelig, farlig webudbyder-sårbarhed**, der lader angribere køre ondsindede scripts i brugeres browsere, så det er vigtig sikkerhedsviden for webudviklere. At forstå **hvordan det fungerer** — at rendering af brugerinput på en side uden korrekt escaping lader injiceret **JavaScript køre i andre brugeres browsere i det pålidelige sites sammenhæng**, hvilket gør det muligt for angribere at stjæle sessionscookies og tokens, kapre konti og handle som brugeren — er nødvendig for at genkende og forhindre sårbarheden. XSS er farligt, fordi det kompromitterer brugernes sessioner og data, og det er almindeligt i webapps, der viser brugergeneret indhold. At forstå **typerne** (lagret XSS — ondsindede scripts gemt på serveren og serveret til alle seere, den mest farlige; reflekteret XSS — scripts reflekteret fra en forespørgsel; DOM-baseret XSS — usikker DOM-manipulation på klientsiden) hjælper med at genkende de forskellige angrebsvektorer. At forstå **forebyggelsen** er vigtig: **escaping/kodning af output** (rendering af brugerdata som tekst, ikke HTML — nøgleforsvaret, som moderne frameworks som React gør automatisk som standard når det bruges korrekt), **undgå farlige APIs** (innerHTML, dangerouslySetInnerHTML, eval med uårvåget data — almindelige XSS-kilder), **sanitering af HTML**, når rigt indhold skal tillades (f.eks. DOMPurify), **Content Security Policy** (begrænsning af scriptudførelse som forsvarsdybde) og **HttpOnly cookies** (forhindring af JS fra at læse dem). At forstå, at frameworks auto-escaper (så korrekt brug af dem forhindrer mest XSS, mens omgåelse af deres escaping genintroducerer det) er praktisk vigtig. Da XSS er en almindelig, farlig sårbarhed, der kompromitterer brugernes sessioner og data, især i apps, der viser brugerindhold, og da det at forstå, hvordan det fungerer og hvordan man forhindrer det (output escaping, undgåelse af farlige APIs, CSP, framework-standarder) er vigtig for webudviklere, er det at forstå XSS og dets forebyggelse vigtig, vigtig sikkerhedsviden — en fundamental webudbyder-sårbarhed at forsvare sig mod, hvor korrekt output-håndtering (escaping, brug af framework-standarder, undgåelse af farlige APIs) er kritisk viden for at beskytte brugere mod en udbredt klasse af angreb.