Förstå CSRF på djupet

När vi arbetar med webbutveckling, särskilt med cookies, hör vi ofta fraser som "denna inställning hjälper till att förebygga CSRF". Men många människor har bara en vag uppfattning om vad "CSRF" verkligen betyder.

Idag kommer vi att göra en djupdykning i CSRF (Cross-Site Request Forgery), en vanlig säkerhetsbrist på webben. Detta kommer att hjälpa oss att hantera CSRF-relaterade problem mer effektivt.

Vad är CSRF?#

CSRF (Cross-Site Request Forgery) är en typ av webbaserad attack där angripare lurar autentiserade användare att utföra oavsiktliga handlingar. Enkelt uttryckt är det "hackare som låtsas vara användare för att genomföra obehöriga handlingar".

Hur CSRF fungerar#

För att förstå CSRF behöver vi greppa några nyckelbegrepp:

Webbläsarens samma-origin-policy#

Samma-origin-policy är en säkerhetsfunktion i webbläsare som begränsar hur ett dokument eller skript från en origin kan interagera med resurser från en annan origin.

En origin består av ett protokoll (som HTTP eller HTTPS), domännamn och portnummer. Till exempel är https://example.com:443 en origin, medan https://demo.com:80 är en annan.

Samma-origin-policy begränsar dataåtkomst mellan sidor från olika origin, vilket innebär:

• JavaScript från en origin kan inte läsa DOM från en annan origin
• JavaScript från en origin kan inte läsa Cookie, IndexedDB eller localStorage från en annan origin
• JavaScript från en origin kan inte skicka AJAX-förfrågningar till en annan origin (såvida de inte använder CORS)

Men för att upprätthålla webbens öppenhet och interoperabilitet (som att ladda resurser från CDN:er eller skicka förfrågningar till tredjeparts-API:er för loggning), begränsar inte samma-origin-policy nätverksförfrågningar över origins:

• Sidor kan skicka GET- eller POST-förfrågningar till vilken som helst origin (som att ladda bilder eller skicka formulär)
• Resurser från vilken som helst origin kan inkluderas (som <script>, <img>, <link>, <iframe> taggar)

Automatisk cookie-sändningsmekanism#

Den automatiska cookie-sändningsmekanismen är en viktig funktion hos webbläsare. När en webbläsare skickar en förfrågan till en domän bifogar den automatiskt alla cookies för den domänen. Denna process sker automatiskt och kräver ingen JavaScript-kod eller användarinteraktion.

Denna mekanism gör det enkelt för webbplatser att komma ihåg användares inloggningsstatus eftersom varje förfrågan automatiskt bär med sig användarens identitetsinformation. Fetstil Till exempel, när du loggar in på en banksajt (bank.com) och får en identitetscookie, så när du klickar för att visa ditt kontoutdrag hittar webbläsaren automatiskt alla cookies som matchar bank.com och bifogar dem till förfrågan för kontoutdraget. Bankens server kan sedan identifiera dig från backend och returnera din kontoutdragsinformation.

CSRF-attackssteg#

1. Användaren loggar in på målsidan (som en bankwebbsida) och får en autentiseringscookie. Detta steg använder den automatiska cookie-sändningsmekanismen. När banksidan ställer in en identitetsautentiseringscookie kommer webbläsaren automatiskt att bifoga denna cookie till varje förfrågan som skickas till den sidan.

2. Utan att logga ut besöker användaren en skadlig webbplats. Vid denna tidpunkt, på grund av samma-origin-policy, kan den skadliga sidan inte direkt läsa eller ändra banksidans cookie. Detta skyddar användarens identitetsinformation från att bli direkt stulen.

3. Den skadliga sidan inkluderar en förfrågan till målsidan (som en överföringsoperation). Även om samma-origin-policy begränsar åtkomst över olika origins tillåter den dock nätverksförfrågningar över origins, såsom förfrågningar initierade genom <img>, <form> taggar. Angripare utnyttjar denna "lucka".

4. Användarens webbläsare skickar automatiskt denna förfrågan tillsammans med målsidans cookie. Detta är kärnan i CSRF-attacken. Den drar nytta av både samma-origin-policy som tillåter nätverksförfrågningar över origins och den automatiska cookie-sändningsmekanismen (även förfrågningar som triggas av skadliga sidor kommer att ha cookies som matchar domänen).

5. Målsidan tar emot förfrågan, verifierar att cookien är giltig och utför operationen. Servern kan inte avgöra om denna förfrågan kommer från en legitim användaråtgärd eftersom den bifogade cookien är giltig.

Exempel på CSRF-attack#

Låt oss illustrera hur en CSRF-attack sker med ett specifikt exempel. Vi använder en fiktiv bankwebbsida bank.com som exempel.

Först besöker användaren https://bank.com och loggar in på sitt konto.

Efter en lyckad inloggning ställer servern in en autentiseringscookie, till exempel:

Användaren utför en överföringsoperation på banksidan, säg överför $1000 till Alice. Denna operation kan skicka en förfrågan som denna:

Nu, anta att en angripare skapar en skadlig webbsida https://evil.com som innehåller följande HTML:

När användaren klickar på länken https://evil.com utan att logga ut från sitt bankkonto, eftersom de redan är inloggade på bank.com, har webbläsaren en giltig session_id cookie.

Efter att den skadliga sidan har laddats skickar den automatiskt det dolda formuläret och skickar en överföringsförfrågan till https://bank.com/transfer.

Användarens webbläsare bifogar automatiskt <bank.com> cookien till denna förfrågan. <bank.com> servern mottar förfrågan, verifierar att cookien är giltig och utför sedan denna obehöriga överföringsoperation.

Vanliga metoder för att förhindra CSRF-attacker#

Här är flera vanliga CSRF-försvarsmetoder. Vi kommer att förklara i detalj principen för varje metod och hur den effektivt förhindrar CSRF-attacker:

Använda CSRF-tokens#

CSRF-tokens är en av de vanligaste och mest effektiva metoderna för att försvara sig mot CSRF-attacker. Så här fungerar det:

1. Servern genererar en unik, oförutsägbar token för varje session.
2. Denna token är inbäddad i alla formulär för känsliga operationer.
3. När användaren skickar ett formulär verifierar servern tokenens giltighet.

Eftersom CSRF-token är ett unikt värde bundet till användarens session, och angriparen inte kan känna till eller gissa detta värde (eftersom det är olika för varje session), även om angriparen lurar användaren att skicka en förfrågan, kommer förfrågan att avvisas av servern på grund av avsaknaden av en giltig CSRF-token.

Implementeringsexempel:

På serversidan (med Node.js och Express):

I frontend JavaScript:

Kontrollera Referer-headern#

Referer-headern innehåller URL:en för sidan som initierade förfrågan. Genom att kontrollera Referer-headern kan servern avgöra om förfrågan kommer från en legitim källa.

Eftersom CSRF-attacker vanligtvis kommer från olika domäner, kommer Referer-headern att visa angriparens domännamn. Genom att verifiera om Referer är det förväntade värdet kan förfrågningar från okända källor blockeras.

Det är dock värt att notera att denna metod inte är helt tillförlitlig, eftersom vissa webbläsare kanske inte skickar Referer-headern och användare kan inaktivera Referer-headern genom webbläsarinställningar eller pluginer.

Implementeringsexempel:

Använda SameSite cookie-attribut#

SameSite är ett cookie-attribut som används för att kontrollera om cookies skickas med cross-site-förfrågningar. Det har tre möjliga värden:

• Strict: Cookies skickas bara i same-site-förfrågningar.
• Lax: Cookies skickas i same-site-förfrågningar och toppnivånavigering.
• None: Cookies skickas i alla cross-site-förfrågningar (måste användas med Secure-attributet).

När SameSite är inställt på Strict kan det helt förhindra att tredjepartswebbplatser skickar cookies och därmed effektivt förhindra CSRF-attacker. Om SameSite är inställt på Lax skyddar det känsliga operationer medan det tillåter vissa vanliga cross-site-use-cases (som att gå in på en webbplats från externa länkar).

Implementeringsexempel:

Använda skräddarsydda förfrågningsrubriker#

För AJAX-förfrågningar kan skräddarsydda förfrågningsrubriker läggas till. På grund av begränsningarna i samma-origin-policy kan angripare inte ställa in skräddarsydda rubriker i cross-origin-förfrågningar. Servern kan kontrollera om denna skräddarsydda rubrik finns för att verifiera förfrågans legitimitet.

Implementeringsexempel:

På frontend:

På serversidan:

Dubbel cookie-verifikation#

Dubbel cookie-verifikation är en effektiv CSRF-försvarsteknik. Dess kärnprincip är att servern genererar en slumpmässig token, sätter den som både en cookie och bäddar in den på sidan (vanligtvis som ett dolt formulärfält). När webbläsaren skickar en förfrågan inkluderas cookien automatiskt, medan sidans JavaScript skickar token som en förfrågningsparameter. Servern verifierar sedan om token i cookien matchar token i förfrågningsparametrarna.

Även om angripare kan inkludera målsidans cookie i cross-site-förfrågningar kan de inte läsa eller ändra cookie-värdet, inte heller kan de komma åt eller ändra token-värdet på sidan. Genom att kräva att förfrågan inkluderar tokenvärden från både cookien och parametrarna säkerställer det att förfrågan kommer från en källa med behörighet att läsa cookien, vilket effektivt försvarar mot CSRF-attacker.

Använda återsäkerhet för känsliga operationer#

För särskilt känsliga operationer (som att byta lösenord eller göra stora överföringar) kan användare krävas att vara återsäkrade. Detta ger användare en ytterligare säkerhetskontrollpunkt. Även om en användare framgångsrikt initierar en CSRF-attack kan de inte passera återsäkerhetssteget.

Implementeringsförslag:

• Innan känsliga operationer utförs, omdirigera till en separat autentiseringssida.
• På denna sida, kräva att användaren anger sitt lösenord eller annan identitetsverifieringsinformation.
• Efter att verifieringen passerar generera en engångstoken och använd denna token i efterföljande känsliga operationer.

Sammanfattning#

Genom denna djupgående diskussion hoppas vi att du nu har en mer omfattande förståelse av CSRF-attacker. Vi har inte bara lärt oss om hur CSRF fungerar utan också utforskat olika effektiva försvarsmetoder. Alla dessa metoder kan effektivt förbättra säkerheten för webbapplikationer.

Hoppas denna kunskap kommer att hjälpa dig att bättre hantera CSRF-relaterade problem i din dagliga utveckling och bygga säkrare webbapplikationer.