Cross-Site Request-förfalskning

Cross-Site Request Forgery (CSRF, ibland kallad XSRF eller "sea-surf") utnyttjar en webbplatss förtroende för användarens webbläsare. Angriparen kan inte se dina cookies, men webbläsaren skickar dem automatiskt med varje begäran till ursprunget de tillhör. Om angriparen kan få din webbläsare att göra en begäran till en webbplats där du är inloggad, ser den webbplatsen en autentiserad begäran – även om angriparen initierade den.

Den klassiska attacken

Föreställ dig en bank som bearbetar överföringar via en enkel GET-förfrågan: https://bank.example/transfer?to=Bob&amount=1000. Du är inloggad på banken. En angripare skickar en länk till dig via e-post eller är värd för en sida med en bildtagg som pekar på https://bank.example/transfer?to=Attacker&amount=10000. Din webbläsare laddar bilden; banken ser en autentiserad begäran från din session; överföringen går igenom.

TDet specifika exemplet är mestadels historiskt — banker behandlar inte överföringar via GET längre — men mönstret är generellt. Varje tillståndsändringsbegäran som autentiseras enbart via sessionscookies är potentiellt CSRF-sårbar.

Vad gör CSRF möjlig

Ttre grunder:

• Cookies skickas automatiskt. frågar inte om tillåtelse; cookies tillhör ursprunget och reser med varje begäran till det ursprunget, oavsett var förfrågan initierades.
• HTML kan utlösa förfrågningar med flera ursprung. Bildtaggar, formulärinlämningar, skripttaggar och olika andra element kan alla riktas mot vilken URL som helst.
XZPLZ27XXerPLZ26XXPLZ27SPLZ26ZPLZ27SPLS intent. Servern ser en autentiserad begäran; utan explicita CSRF-skydd bearbetar den åtgärden.

Standardförsvaren

• CSRF-tokens (synkroniseringstokens). Servern inkluderar en slumpmässig token i alla former. Bidragen måste innehålla token. Angriparens skadliga sida kan inte läsa token (same-origin policy), så falska förfrågningar misslyckas. Moderna webbramverk genererar och verifierar tokens automatiskt.
• SameSite cookies. Cookies märkta SameSite=Lax (standard i moderna webbläsare sedan 2020) skickas inte på förfrågningar över webbplatser förutom navigering på toppnivå. SameSite=Strikt är ännu tightare. Detta är den enskilt största förändringen som minskat CSRF-risken under de senaste fem åren.
• Origin- och referensrubrikvalidering.-servrar kan kontrollera att Origin-rubriken matchar det förväntade ursprunget. Cross-site-begäranden har ett annat ursprung, vilket tillåter avvisning.
• Double-submit cookie. Server anger ett värde i både en cookie och en separat begäranparameter; verifieraren kontrollerar att de matchar. Fungerar utan sessionstillstånd på serversidan.
• Re-autentisering för känsliga åtgärder. Lösenordsbekräftelse, MFA-utmaning eller stegvis autentisering vid högvärdiga operationer. Besegrar CSRF och flera andra attackklasser samtidigt.

The SameSite-cookiesrevolution

Före 2020 bar varje cross-site-förfrågan destinationswebbplatsens cookies – inklusive tillståndsändrande begäranden från skadliga sidor. SameSite=Lax gjorde cookies för flera webbplatser till undantaget snarare än regeln. Stora webbläsare använde Lax som standard 2020-2021, och effekterna var dramatiska: de flesta tillfälliga CSRF-sårbarheter blev oexploaterbara över en natt.

Fångsten: SameSite=Lax tillåter fortfarande cookies på toppnivånavigering (helsidasomdirigeringar). Tillståndsförändrande operationer som utlöses genom att klicka på en länk kan fortfarande innehålla cookies. Försvaret är bra men inte komplett.

SameSite=Strict förhindrar detta helt. Avvägningen: det bryter inloggningsflöden som är beroende av navigering över platsen (Single Sign-On, post-OAuth-omdirigeringar). De flesta större webbplatser använder Lax som standard och strikt endast på de mest känsliga cookies.

CSRF och APIs

Modern API:er autentiseras ofta via auktoriseringsrubriker (Bearer-tokens) istället för cookies. CSRF gäller inte eftersom webbläsaren inte automatiskt inkluderar godtyckliga rubriker på förfrågningar med flera ursprung. CSRF-problemet tillhör till stor del cookie-autentiserade system.

Men API:er som blandar cookies för vissa flöden och tokens för andra kan ha subtila CSRF-ytor. Använd det ena eller det andra konsekvent.

CSRF och CORS

CORS (Cross-Origin Resource Sharing) definierar när en webbläsare tillåter att en korsorigin-begäran läses av JavaScript. CSRF handlar om huruvida begäran överhuvudtaget är sent, med cookies. De är relaterade men distinkta:

• CSRF förhindrar den skadliga sidan från att orsaka begäran
• CORS hindrar den skadliga sidan från att läsa svaret

A CSRF-attacken behöver inte läsa svaret – den behöver bara åtgärden för att utföra åtgärden. Webbläsaren avfyrar plikttroget begäran och får ett svar; den skadliga sidan kanske inte ser den, men skadan är skedd. CORS fixar inte CSRF.

Kända CSRF-incidenter

• Netflix-kömanipulation (2006). Forskare fann att tillverkade IMG-taggar kunde lägga till filmer i din Netflix-kö utan din inblandning. Korrigeringen var de första CSRF-tokenen i utbredd användning.
• YouTube-kontoövertagandevarianter i slutet av 2000-talet.
• GitHub radering av arkiv via CS2RF (fixad i 20) snabbt).
• Många WordPress-plugin CSRF-sårbarheter rapporteras varje år; plugin-ekosystemet producerar dem fortfarande i skala.

För utvecklare i 2026

• Använd ett ramverk med inbyggt CSRF-skydd (Django, Rails, Spring, Laravel har det alla)
XPLZCSRF38XVerifierar på varje tillstånd request
• Set SameSite=Lax (eller strikt) på sessionscookies
• För API:er, använd bärartokens snarare än cookies när det är möjligt
• Kräv omautentisering för operationer med hög insats
• Doit enbart om ursprung/Referer dessa klienter på vissa klienter. headers

För användare

Du kan inte försvara dig direkt mot CSRF – det är ett fel på serversidan. De moderna webbläsarnas standardinställningar (SameSite=Lax) hjälper avsevärt, men du är beroende av att varje webbplats du loggar in på har implementerat skydd. Håll dig bara inloggad så länge du behöver; logga ut från känsliga konton när de inte används; och lita på moderna stora webbplatser — de har alla hanterat CSRF i sina hotmodeller.