Ger en djupgående utforskning av Cross-Site Request Forgery (CSRF) attacker, förklarar deras mekanik, demonstrerar exempel och beskriver olika förebyggande metoder för att förbättra webbapplikationssäkerhet.
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.
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".
För att förstå CSRF behöver vi greppa några nyckelbegrepp:
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:
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:
<script>, <img>, <link>, <iframe> taggar)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.
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.
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.
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".
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).
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.
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.
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:
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:
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:
Referer-headernReferer-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:
SameSite cookie-attributSameSite ä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:
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 ä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.
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:
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.