Den här bloggposten går igenom CSRF-attacker (Cross-Site Request Forgery) – ett av de mest kritiska hoten mot webbplatsers säkerhet – och presenterar effektiva försvarsmetoder. Du får veta vad CSRF innebär, hur attacker går till och vilka konsekvenser de kan få. Vi ger praktiska råd om hur du skyddar dig mot CSRF, vilka verktyg och metoder som finns, och lyfter fram aktuella statistik för att visa varför detta är en angelägen fråga för alla som driver eller utvecklar webbapplikationer. Artikeln avslutas med handlingsplaner och de mest effektiva strategierna för att motverka CSRF, så att du får en komplett guide för att hålla din webb säker.
Vad är CSRF (Cross-Site Request Forgery)?
CSRF (Cross-Site Request Forgery) är en säkerhetsbrist som gör det möjligt för en illasinnad webbplats att få en användares webbläsare att utföra otillåtna handlingar på en annan webbplats där användaren redan är inloggad. Angriparen kan, utan att användaren märker det, skicka förfrågningar med användarens identitet och därmed exempelvis ändra lösenord, genomföra banktransaktioner eller uppdatera e-postadressen.
CSRF-attacker sker ofta via social ingenjörskonst – angriparen får offret att klicka på en länk eller besöka en manipulerad sida. Då skickas automatiskt förfrågningar från användarens webbläsare till målsidan, och den tror att det är användaren själv som utför handlingarna.
| Egenskap | Beskrivning | Försvar |
|---|---|---|
| Definition | Skickar förfrågningar utan användarens tillåtelse | CSRF-token, SameSite-cookies |
| Mål | Inloggade användare | Stärk autentiseringsmekanismer |
| Konsekvenser | Datastöld, otillåtna transaktioner | Filtrera in- och utdata |
| Förekomst | Vanlig säkerhetsbrist i webbappar | Regelbundna säkerhetstester |
För att skydda mot CSRF kan du använda CSRF-token, SameSite-cookies och begära extra verifiering vid viktiga handlingar. Webbutvecklare bör implementera dessa skydd för att minska risken.
CSRF – Grunder
- CSRF gör det möjligt att utföra otillåtna handlingar utan användarens vetskap.
- Angriparen använder användarens identitet för att skicka förfrågningar.
- Social ingenjörskonst är vanligt.
- CSRF-token och SameSite-cookies är centrala försvar.
- Utvecklare måste ta ansvar för att skydda sina applikationer.
- Säkerhetstester avslöjar brister.
CSRF är ett allvarligt hot mot webbapplikationer och det är viktigt att både utvecklare och användare är medvetna om riskerna. Som användare bör du undvika misstänkta länkar och använda pålitliga sidor för att minska risken.
CSRF – Översikt över attacker
CSRF (Cross-Site Request Forgery) innebär att en illvillig webbplats skickar otillåtna kommandon till en annan webbplats där användaren är inloggad – utan att användaren är medveten om det. Ofta sker attacken via förtroende för en webbplats; angriparen skickar förfrågningar som ser ut att komma från användaren. Exempelvis kan en banktransaktion triggas eller ett inlägg läggas upp på sociala medier.
- CSRF – typiska egenskaper
- Kan ske med ett enda klick
- Kräver att användaren är inloggad
- Angriparen får inte tillgång till användarens autentiseringsuppgifter
- Innehåller ofta social ingenjörskonst
- Förfrågningar skickas från offrets webbläsare
- Utnyttjar svag sessionhantering hos målsidan
CSRF-attacker utnyttjar säkerhetsbrister i webbapplikationer. Angriparen placerar en manipulativ länk eller script i offrets webbläsare, och förfrågningarna verkar komma från användaren själv. Servern godkänner dem som legitima – och angriparen kan då ändra kontouppgifter eller få tillgång till känslig information.
| Attacktyp | Beskrivning | Skydd |
|---|---|---|
| GET-baserad CSRF | Angriparen skickar förfrågningar via länkar | AntiForgeryToken, kontroll av Referer-header |
| POST-baserad CSRF | Angriparen skickar förfrågningar via formulär | AntiForgeryToken, CAPTCHA |
| JSON-baserad CSRF | Förfrågningar med JSON-data mot API:er | Kontroll av specialheaders, CORS-policy |
| Flash-baserad CSRF | Förfrågningar via Flash-applikationer | Avaktivera Flash, säkerhetsuppdateringar |
Vanliga försvar är AntiForgeryToken (unik token för varje formulär), SameSite-cookies (begränsar cookies till egen domän) och kontroll av Referer-header. Dessa skyddar mot att attacker skickar förfrågningar från fel källa.
CSRF är ett allvarligt hot – både för användare och utvecklare. Att implementera robusta skydd och utbilda användare är avgörande för att minska riskerna. Utvecklare bör alltid designa med säkerhet i åtanke och testa sina applikationer regelbundet.
Hur utförs CSRF-attacker?
CSRF (Cross-Site Request Forgery) utförs genom att angriparen får en auktoriserad användares webbläsare att skicka förfrågningar till en applikation där användaren är inloggad – utan att användaren är medveten om det. Angriparen lägger in skadlig kod i webbläsaren och triggar handlingar som lösenordsändring, pengaöverföring eller profiluppdatering. Det kan drabba både privatpersoner och stora företag.
Grunden till CSRF är att webbapplikationen inte verifierar förfrågningar ordentligt. Angriparen skapar falska förfrågningar som ser ut att komma från den legitima användaren, och servern godkänner dem. Exempel: en länk som ändrar lösenord eller ett formulär som skickar pengar till angriparen.
| Attacktyp | Beskrivning | Exempel |
|---|---|---|
| URL-baserad CSRF | Angriparen skapar en länk som offret klickar på | <a href=http://example.com/transfer?to=attacker&amount=1000>Du har vunnit!</a> |
| Formulärbaserad CSRF | Angriparen skapar ett formulär som automatiskt skickas | <form action=http://example.com/transfer method=POST><input type=hidden name=to value=attacker><input type=hidden name=amount value=1000><input type=submit value=Skicka></form> |
| JSON-baserad CSRF | Utnyttjar brister i API-säkerhet | fetch('http://example.com/api/transfer', { method: 'POST', body: JSON.stringify({ to: 'attacker', amount: 1000 ) ) |
| CSRF via bild-taggar | Angriparen skickar förfrågning via img-tag | <img src=http://example.com/transfer?to=attacker&amount=1000> |
För att CSRF ska lyckas måste användaren vara inloggad på målsidan och angriparen måste kunna trigga en förfrågan från offrets webbläsare. Oftast sker det via e-post, webbplatser eller forum. När användaren klickar på en länk skickas förfrågan automatiskt, tillsammans med användarens autentisering – därför är skydd mot CSRF absolut nödvändigt.
Attackscenarier
Typiska CSRF-scenarier är e-post med manipulerad länk, eller scripts/bilder på betrodda sidor. När användaren klickar triggas en attack som utförs i bakgrunden – utan att offret märker det.
Verktyg för CSRF
För att testa eller utföra CSRF används verktyg som Burp Suite, OWASP ZAP och skript. Dessa hjälper angripare att skapa falska förfrågningar och analysera HTTP-trafik. Säkerhetsexperter använder dem för att hitta och åtgärda CSRF-brister.
Steg för CSRF-attack
- Identifiera säkerhetsbrister i målapplikationen.
- Skapa skadlig förfrågan mot webbplatsen där användaren är inloggad.
- Använd social ingenjörskonst för att få offret att trigga förfrågan.
- Offrets webbläsare skickar den falska förfrågan.
- Webbservern godkänner förfrågan som legitim.
- Angriparen utför otillåtna handlingar via offrets konto.
Hur skyddar man sig?
Skydd mot CSRF innefattar CSRF-token, SameSite-cookies och double submit cookies. CSRF-token är unika för varje förfrågan och gör det svårt för angriparen att gissa. SameSite-cookies skickas bara med egna domänens förfrågningar. Double submit cookies kräver att värdet skickas både i en cookie och som formdata – så servern kan verifiera att förfrågan är legitim.
Regelbundna säkerhetstester och borttagning av brister är viktigt. Utvecklare måste förstå CSRF och implementera robusta skydd. Även användarna bör utbildas så att de undviker misstänkta länkar och säkerställer att webbplatsen är trygg.
Så kan CSRF förebyggas
Att förebygga CSRF kräver både tekniska och utbildande insatser. Utvecklare bör använda CSRF-token, SameSite-cookies och double submit cookies. Användarna måste informeras om risker och hur de undviker misstänkta länkar.
Skydd ska införas både på server och klient. Servern verifierar förfrågningar med token och cookies; klienten måste undvika osäkra länkar och ha rätt säkerhetsinställningar i webbläsaren.
Rekommenderade skydd
- CSRF-token: Skapa unika token för varje session och kontrollera förfrågningar.
- SameSite-cookies: Begränsa cookies till egna domänen.
- Double submit cookies: Kräv att samma värde skickas både som cookie och formdata.
- Origin-header: Kontrollera ursprung för förfrågningar.
- Användarutbildning: Informera om risker och misstänkta länkar.
- Säkerhetsheaders: Använd X-Frame-Options och Content-Security-Policy som extra skydd.
Tabellen nedan sammanfattar vilka skydd som fungerar mot olika attacktyper:
| Skydd | Beskrivning | Effektivt mot |
|---|---|---|
| CSRF-token | Unik token för varje förfrågan | Grundläggande CSRF-attacker |
| SameSite-cookies | Cookies skickas bara med egna förfrågningar | Cross-site-förfrågningar |
| Double submit cookies | Värdet krävs både som cookie och formdata | Manipulation/kapning av token |
| Origin-kontroll | Verifierar förfrågans ursprung | Domänförfalskning |
För att uppnå heltäckande skydd bör flera metoder kombineras. Ett lager av skydd är alltid bäst – och säkerhetspolicys och rutiner måste uppdateras regelbundet för att hantera nya hot.
Konsekvenser av CSRF
CSRF kan få allvarliga konsekvenser för både användare och webbapplikationer. Otillåtna handlingar kan utföras utan att användaren märker det – och angriparen kan stjäla, manipulera eller radera data. Företag riskerar både ekonomiska förluster och förlorat förtroende, och ibland juridiska problem.
Att förstå CSRF:s potentiella effekter är avgörande för att bygga effektiva försvarsmetoder. Attacken kan innebära allt från lösenordsändring och pengaöverföringar, till att publicera skadligt innehåll eller beställa varor. Det skadar både användarens tillit och webbplatsens rykte.
Negativa effekter av CSRF
- Kontoövertagande och otillåten åtkomst
- Manipulation eller radering av användardata
- Ekonomiska förluster (t.ex. otillåtna transaktioner)
- Förlorat förtroende och dåligt rykte
- Missbruk av webbapplikationens resurser
- Juridiska problem
Nedan visas olika scenarier och deras konsekvenser:
| Scenario | Konsekvens | Påverkad part |
|---|---|---|
| Lösenordsändring | Kontoförlust, stöld av personuppgifter | Användaren |
| Pengaöverföring från bankkonto | Otillåtna transaktioner och ekonomiska förluster | Användaren, banken |
| Inlägg på sociala medier | Spridning av skadligt innehåll, förlorat rykte | Användaren, plattformen |
| Beställning på e-handel | Otillåtna köp och ekonomiska förluster | Användaren, e-handeln |
CSRF är alltså ett mycket allvarligt hot. Utvecklare och administratörer måste vidta proaktiva åtgärder och utbilda användare. Tekniska skydd är nödvändiga, men medvetenhet är också avgörande för att minska risken.
Kombinera tekniska försvar med användarutbildning och rutiner – till exempel att inte klicka på okända länkar och att byta lösenord regelbundet – så minskar du risken betydligt.
CSRF-försvarsverktyg och metoder

För att skydda mot CSRF krävs en mångsidig och lagerbaserad strategi. Synkroniserad token-modell (Synchronizer Token Pattern – STP) är en av de viktigaste säkerhetsmetoderna – servern skapar en unik token för varje session och verifierar alla kritiska förfrågningar mot denna token. Falska förfrågningar från andra webbplatser blockeras effektivt.
Försvarsverktyg
- Synchronizer Token Pattern (STP): Skapar unika token för varje formulär och verifierar förfrågan.
- Double Submit Cookies: Samma värde skickas både som cookie och formdata – servern kontrollerar att de matchar.
- SameSite-cookies: Cookies skickas bara med egna domänens förfrågningar.
- CSRF-bibliotek och ramverk: Många programmeringsspråk har färdiga CSRF-skydd.
- Header-kontroller (Referer/Origin): Kontroll av förfrågans ursprung för att blockera otillåtna källor.
Se tabellen för jämförelse av olika försvarsmetoder:
| Försvarsmetod | Beskrivning | Fördelar | Nackdelar |
|---|---|---|---|
| Synchronizer Token Pattern (STP) | Unik token per formulär | Hög säkerhet, standardlösning | Mer serverlast, tokenhantering |
| Double Submit Cookies | Samma värde i cookie och formdata | Enkel implementation, fungerar med stateless-applikationer | Problem med subdomäner, vissa webbläsare |
| SameSite-cookies | Cookies skickas bara med egna förfrågningar | Enkelt, klientbaserat skydd | Fungerar inte i äldre webbläsare, kan påverka cross-origin-funktioner |
| Header-kontroller | Referer och Origin-verifiering | Enkelt, ingen serverlast | Headers kan manipuleras, låg tillförlitlighet |
Double Submit Cookies är särskilt effektivt för stateless-appar och API:er – då behövs ingen sessionhantering på servern. Servern genererar ett slumpvärde och skickar det både som cookie och i formulärdata – och verifierar att de matchar.
SameSite-cookies är ett enkelt skydd mot CSRF – cookies skickas endast med egna domänens förfrågningar. Men eftersom inte alla webbläsare stöder detta bör du kombinera med andra metoder.
Tips för att undvika CSRF
CSRF-skydd är avgörande för webbplatsens säkerhet. Här är de viktigaste tipsen för utvecklare och administratörer:
Använd Synchronizer Token Pattern (STP) för att skapa unika token för varje session och kontrollera alla kritiska förfrågningar. Double Submit Cookie är effektivt för API:er och AJAX – servern verifierar att värdet skickas både som cookie och i formdata.
Tabellen visar för- och nackdelar med olika metoder:
| Försvarsmetod | Beskrivning | Fördelar | Nackdelar |
|---|---|---|---|
| Synchronizer Token Pattern (STP) | Unik token per session – verifieras | Hög säkerhet, standardlösning | Kräver tokenhantering, kan vara komplext |
| Double Submit Cookie | Samma värde som cookie och i formdata | Enkelt, passar API:er | Kräver JavaScript, beror på cookie-säkerhet |
| SameSite-cookies | Cookies skickas endast med egna förfrågningar | Lätt att implementera, extra skydd | Fungerar inte i äldre webbläsare |
| Referer-kontroll | Verifierar förfrågans ursprung | Enkelt och snabbt | Referer kan manipuleras, låg tillförlitlighet |
Konkreta tips:
- Använd STP: Skapa unika CSRF-token för varje session och kontrollera dem vid varje formulär.
- Double Submit Cookie: Kontrollera att värdet matchar både som cookie och i formdata – särskilt i API/AJAX.
- SameSite-cookie: Aktivera SameSite (Strict eller Lax) för cookies.
- HTTP-header: Använd X-Frame-Options för att skydda mot clickjacking.
- Referer-kontroll: Kontrollera ursprung, men använd inte som enda skydd.
- Validera och sanera indata: Kontrollera och rensa all användardata (skyddar även mot XSS).
- Regelbundna säkerhetstester: Testa och åtgärda brister regelbundet.
Utbilda användarna så att de undviker okända länkar och använder säkra webbplatser. Skydd mot CSRF består av flera lager – varje åtgärd stärker den totala säkerheten.
Aktuell statistik om CSRF-attacker
CSRF är fortfarande ett av de vanligaste hoten mot webbapplikationer. Statistik visar att e-handel, bank och sociala medier är särskilt utsatta. Utvecklare och säkerhetsexperter måste vara proaktiva och implementera robusta skydd.
Statistik
- 2023 utgjorde CSRF 15% av alla attacker mot webbapplikationer.
- CSRF-attacker mot e-handel ökade med 20% senaste året.
- Dataintrång på grund av CSRF i finanssektorn steg med 12%.
- Mobilappar med CSRF-brister ökade med 18%.
- De genomsnittliga kostnaderna för CSRF-skador ökade med 10% jämfört med året innan.
- Finans, retail och hälsa är mest drabbade.
Nedan visas CSRF-attacker per bransch:
| Bransch | Attackandel (%) | Genomsnittlig kostnad (SEK) | Antal dataintrång |
|---|---|---|---|
| Finans | 25 | 500,000 | 15 |
| E-handel | 20 | 350,000 | 12 |
| Hälsa | 15 | 250,000 | 8 |
| Sociala medier | 10 | 150,000 | 5 |
För att minska CSRF-riskerna måste utvecklare testa säkerheten, patcha brister och utbilda användare. Rätt implementering av Synchronizer Tokens och Double Submit Cookies minskar attackmöjligheterna kraftigt.
CSRF-evolutionen visar att nya varianter dyker upp hela tiden, och säkerhetsstrategier måste uppdateras. Proaktiv bristhantering är avgörande för att minimera effekterna av CSRF.
CSRF – varför det är viktigt och handlingsplan
CSRF (Cross-Site Request Forgery) är ett mycket allvarligt hot – användaren kan omedvetet få sitt konto kapat, data stulen eller pengar överförda. Ett proaktivt angreppssätt och en tydlig handlingsplan är viktigt.
| Risknivå | Effekter | Förebyggande åtgärder |
|---|---|---|
| Hög | Kontoövertagande, dataintrång, ekonomiska förluster | CSRF-token, SameSite-cookies, tvåfaktorsautentisering |
| Medel | Oönskad profiländring, otillåtna inlägg | Referer-kontroll, användarinteraktion |
| Låg | Mindre datamanipulering | Enkla verifieringsmetoder, rate limiting |
| Osäker | Effekter beroende på brist, oförutsägbara konsekvenser | Kontinuerliga säkerhetsanalyser, kodgranskning |
Handlingsplan – steg för att skydda mot CSRF:
- Riskanalys: Identifiera CSRF-brister i din webbapplikation.
- CSRF-token: Implementera unika token för alla formulär och API-förfrågningar.
- SameSite-cookies: Begränsa cookies till egen domän med SameSite.
- Referer-kontroll: Verifiera ursprung för inkommande förfrågningar.
- Användarutbildning: Informera om phishing och social ingenjörskonst.
- Säkerhetstest: Utför penetrationstester och säkerhetsanalyser regelbundet.
- Kontinuerlig övervakning: Identifiera och agera på avvikande aktivitet.
CSRF-skydd måste vara dynamiskt och uppdateras efter nya hot. Utbilda utvecklare och användare – det är lika viktigt som tekniska åtgärder. Säker webbutveckling kräver att du är förberedd och medveten om CSRF.
De mest effektiva metoderna mot CSRF
CSRF är ett av de största hoten mot webbapplikationer. Genom att implementera rätt försvar kan du minska risken avsevärt. Nedan listas de mest effektiva metoderna:
| Metod | Beskrivning | Svårighetsgrad |
|---|---|---|
| Synchronizer Token Pattern (STP) | Unik token per session och kontroll vid varje formulär | Medel |