Tänk dig att någon lurar en besökare att klicka på en länk medan hen är inloggad i sin internetbank. Länken leder till ett dolt formulär som, utan att besökaren vet om det, skickar en begäran till banken om att överföra pengar. Banken ser en legitim begäran från en inloggad användare och genomför den. Angriparen har nu flyttat pengar från offrets konto utan att någonsin ha känt till lösenordet.
Det här är CSRF (Cross-Site Request Forgery): en attack där en angripare lurar någon att omedvetet skicka ett formulär eller en begäran till en annan webbplats där hen redan är inloggad.
Det här lär du dig: vad CSRF-attacker är och hur de fungerar, varför de är så farliga även när andra säkerhetsåtgärder finns på plats, hur CSRF-token förhindrar dem och hur du inför skydd i dina formulär.
Vad är CSRF?
CSRF (uttalas "sea-surf") står för Cross-Site Request Forgery. Det är en attack där angriparen utnyttjar att webbläsaren, när du är inloggad på en webbplats, automatiskt litar på din session och skickar med den i varje begäran till den webbplatsen, även om begäran kommer från en annan webbplats.
Attacken går ut på att lura en inloggad besökare att omedvetet skicka ett formulär till en webbplats där hen har ett konto. Angriparen kan inte se offrets lösenord. Det behövs inte. Offret behöver bara redan vara inloggat, och sedan luras hen att göra en begäran (som att skicka ett dolt formulär) som gör något som angriparen vill.
CSRF skiljer sig från andra attacker eftersom den inte kräver att någon stjäl inloggningsuppgifter eller knäcker kryptering. Den utnyttjar offrets förtroende för webbplatsen. Offret är redan inloggat, så webbplatsen litar på begäranden som verkar komma från hen.
Så fungerar CSRF-attacker
En CSRF-attack sker i tre steg.
Steg 1: Offret är inloggat på din webbplats
Någon besöker din webbplats och loggar in på sitt konto. Webbläsaren har nu en aktiv sessionscookie som bevisar att personen är inloggad. Sessionen förblir aktiv så länge personen fortsätter använda webbplatsen.
Steg 2: Angriparen lockar offret till en skadlig sida
Medan offret fortfarande är inloggat på din webbplats besöker hen en sida som angriparen kontrollerar (kanske en länk från sociala medier, en vilseledande annons eller en webbplats som ser seriös ut). På den sidan finns dold kod som skickar ett formulär tillbaka till din webbplats.
Steg 3: Formuläret skickas automatiskt med offrets session
Det dolda formuläret skickas till din webbplats. Eftersom offret redan är inloggat skickar webbläsaren automatiskt med sessionscookien. Ur formulärets perspektiv är det här en legitim begäran från en inloggad användare. Formuläret behandlar den som om offret skickat den med avsikt.
Angriparen har nu gjort något på din webbplats med offrets konto utan att offret vet om det. Hen kan ha ändrat lösenordet, överfört pengar, uppdaterat profilen eller skickat in uppgifter.
Därför fungerar attacken trots andra säkerhetsåtgärder
CSRF-attacker kringgår flera vanliga säkerhetsfunktioner:
HTTPS stoppar inte CSRF. Uppgifterna krypteras under överföringen, men angriparen behöver inte avlyssna dem. Hen skickar bara begäran från offrets webbläsare, som webbplatsen redan litar på.
Lösenordsskydd stoppar inte CSRF. Angriparen behöver aldrig offrets lösenord. Hen utnyttjar bara att offret redan är inloggat.
Ett starkt inloggningssystem stoppar inte CSRF. Även om inloggningen är perfekt fungerar attacken så länge offret är inloggat.
Därför är CSRF-skydd ett eget lager. Det förhindras inte av andra säkerhetsåtgärder. Du måste utforma dina formulär särskilt för att stå emot CSRF-attacker.
CSRF-token: så stoppas attacken
Lösningen är en CSRF-token. Det är en unik, oförutsägbar sträng som din server skapar för varje formulär. Så här fungerar det:
Din server skapar en unik token för varje besökare
När någon laddar en sida med ett formulär skapar servern en slumpmässig token och kopplar den till användarens session. Token är olika varje gång och unik för just den användaren.
Token bäddas in i formuläret
Token läggs in som ett dolt fält i HTML-formuläret. När besökaren skickar formuläret följer token med.
Din server kontrollerar token innan inskicket behandlas
När formuläret skickas kontrollerar servern om token i inskicket stämmer med den token du skapade för användarens session. Om den gör det behandlas formuläret. Om den inte gör det (eller om token saknas) avvisas formuläret.
Angriparens dolda formulär kan inte innehålla en giltig token, eftersom token är oförutsägbara och unika för varje session. En angripare på en annan domän kan varken se eller gissa token. Därför misslyckas attacken. Det dolda formuläret skickas, men din server avvisar det eftersom token inte stämmer.
Så ser en CSRF-token ut i praktiken
I HTML ser ett formulär med CSRF-skydd ut så här:
<form method="POST" action="/submit-form"> <input type="hidden" name="csrf_token" value="a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6"> <input type="email" name="email" placeholder="Your email"> <button type="submit">Submit</button> </form>Fältet `csrf_token` är dolt. Besökaren ser det inte, men det skickas med formulärets övriga data. Din server kontrollerar det innan e-postadressen eller andra uppgifter behandlas.
CSRF-skydd för olika typer av formulär
Traditionella HTML-formulär
Vanliga HTML-formulär (de som POST:ar data till din server) behöver CSRF-token. Det gäller kontaktformulär, inloggningsformulär, formulär för återställning av lösenord och alla formulär som ändrar data på din server.
AJAX- och JavaScript-formulär
Formulär som skickas via JavaScript till en API-slutpunkt behöver också CSRF-skydd. Token kan bäddas in i själva formuläret, lagras i en cookie eller hämtas från en metataggen innan begäran skickas.
API-begäranden utan sessioner
Om ditt API använder tokenbaserad autentisering (som JWT) fungerar CSRF-skyddet annorlunda. Webbläsaren kan inte automatiskt bifoga en JWT-token på samma sätt som en sessionscookie, så traditionell CSRF är ett mindre hot. Ändå är bästa praxis att lägga till en extra CSRF-token för ett starkare skydd.
Andra skydd som fungerar tillsammans med CSRF-token
CSRF-token är det främsta försvaret, men de fungerar bäst tillsammans med andra säkerhetsrutiner.
SameSite-cookies
När du skapar en sessionscookie kan du lägga till attributet `SameSite`, som säger åt webbläsaren att inte skicka med cookien när begäran kommer från en annan domän. Då kan angriparens dolda formulär inte använda offrets session alls.
Kontroll av Referer-huvudet
Din server kan kontrollera Referer-huvudet för att se var begäran kom ifrån. Om ett inskick påstår sig komma från din domän men Referer visar en annan domän är det troligen en attack. (Referer-huvuden kan dock förfalskas, så det är inget fullständigt skydd.)
Double-submit cookie-mönstret
I den här metoden lagras CSRF-token både i en cookie och i ett formulärfält. Din server kontrollerar att de stämmer överens innan inskicket behandlas. Det är mindre vanligt än traditionella token men fungerar bra för applikationer utan sessioner.
Så inför du CSRF-skydd
Detaljerna beror på din teknikstack, men mönstret är detsamma:
- Skapa en unik token per session. När en användare startar en session eller laddar en formulärsida skapar din backend en ny token.
- Lagra token på serversidan. Spara den kopplad till användarens session.
- Lägg in token i formuläret. Lägg till den som ett dolt fält i HTML eller som en metatagg som JavaScript kan läsa.
- Validera vid inskick. Innan någon formulärdata behandlas ska du kontrollera att den skickade token stämmer med den lagrade token för sessionen.
- Skapa en ny token efter känsliga åtgärder. När en användare byter lösenord eller gör något kritiskt skapar du en ny token.
De flesta moderna ramverk (Django, Rails, Laravel, ASP.NET) hanterar skapande och validering av CSRF-token automatiskt. Om du använder ett ramverk är CSRF-skyddet oftast påslaget som standard. Se bara till att du inte råkar stänga av det.
Vanliga misstag som lämnar formulär sårbara
Att stänga av CSRF-skyddet för bekvämlighets skull. Vissa utvecklare stänger av CSRF-kontrollerna för att göra API-testning enklare eller koden kortare. Gör inte det. Det skapar en verklig sårbarhet.
Att använda en statisk token för alla användare. Token måste vara unik för varje användares session. En token som är densamma för alla (eller densamma alla dagar) skyddar inte mot CSRF.
Att inte skapa nya token. Om du använder samma token i flera veckor har en angripare mer tid att utnyttja den. Skapa nya token regelbundet och alltid efter känsliga åtgärder.
Att bara förlita sig på SameSite-cookies. SameSite hjälper men räcker inte. Använd CSRF-token som främsta försvar och SameSite som reserv.
Att glömma token i vissa formulär. Skyddar du vissa formulär med token men inte andra kommer angripare att använda de oskyddade. Varje formulär som ändrar data behöver skydd.
Så skyddar WEMASY mot CSRF
WEMASY:s formulär har automatiskt CSRF-tokenskydd i varje formulär du skapar. Du behöver inte ställa in något eller tänka på det. När en besökare skickar ett formulär validerar WEMASY token innan inskicket sparas. Skyddet är inbyggt och påslaget som standard.
Läs mer om säkerhetsalternativ för formulär på prissidan.