CSRF ( engelsk cross-site request forgery - "cross- site request forgery", även känd som XSRF) är en typ av attack mot webbplatsbesökare som använder bristerna i HTTP-protokollet . Om ett offer besöker en webbplats som skapats av en angripare, skickas en begäran i hemlighet på uppdrag av offret till en annan server (till exempel till en betalningssystemserver) som utför någon form av skadlig operation (till exempel överföra pengar till en angripares server). konto). För att utföra denna attack måste offret autentiseras på servern som begäran skickas till, och denna begäran får inte kräva någon bekräftelse från användaren., som inte kan ignoreras eller förfalskas av ett attackerande skript .
Denna typ av attack, i motsats till populär missuppfattning, dök upp för ganska länge sedan: de första teoretiska övervägandena dök upp 1988 [1] , och de första sårbarheterna upptäcktes 2000 . Och själva termen introducerades av Peter Watkins 2001 .
Den huvudsakliga användningen av CSRF är att tvinga utförande av någon åtgärd på en sårbar webbplats på uppdrag av offret ( byte av lösenord , hemlig fråga för lösenordsåterställning, e-post, lägga till en administratör, etc.). Det är också möjligt att utnyttja reflekterad XSS som upptäckts på en annan server med CSRF .
Attacken utförs genom att en länk eller ett skript placeras på en webbsida som försöker komma åt en webbplats där den attackerade användaren är känd (eller antagligen) redan är autentiserad. Användaren Alice kan till exempel surfa på ett forum där en annan användare, Bob , postade ett meddelande. Låt Bob skapa en <img>-tagg , där han angav webbadressen som källan till bilden , när han klickade på den utförs en åtgärd på Alices banks webbplats, till exempel:
Bob: Hej Alice! Titta så söt den här katten är: <img src="http://bank.example.com/?account=Alice&amount=1000000&for=Bob">Om Alices bank lagrar Alices autentiseringsinformation i en cookie , och om cookien ännu inte har upphört att gälla, när man försöker ladda ner bilden , skickar Alices webbläsare en cookie i begäran om att överföra pengar till Bobs konto, vilket kommer att bekräfta Alices autentisering. Således kommer transaktionen att slutföras framgångsrikt, även om dess bekräftelse kommer att ske utan Alices vetskap.
Alla förfrågningar som ändrar data på servern, såväl som förfrågningar som returnerar personliga eller andra känsliga uppgifter, måste skyddas.
Det enklaste sättet att skydda sig mot denna typ av attack är att kräva att webbplatser kräver bekräftelse av de flesta användaråtgärder och kontrollera HTTP_REFERER- fältet om det anges i begäran. Denna metod kan dock vara osäker och rekommenderas inte [2] .
En annan vanlig metod för skydd är en mekanism där ytterligare en hemlig unik nyckel associeras med varje användarsession, utformad för att uppfylla förfrågningar. Den hemliga nyckeln ska inte skickas i klartext, till exempel för POST- förfrågningar ska nyckeln skickas i förfrågans brödtext, inte i sidadressen. Användarens webbläsare skickar denna nyckel som en del av parametrarna för varje begäran, och servern kontrollerar denna nyckel innan någon åtgärd vidtas. Fördelen med denna mekanism, jämfört med referenskontrollen, är garanterat skydd mot CSRF-attacker. Nackdelarna är kravet på möjligheten att organisera användarsessioner, kravet på dynamisk generering av HTML-kod för webbplatssidor, samt behovet av att skydda mot XSS och andra attacker som gör att en angripare kan få en unik nyckel.
HTTP/1.1-protokollspecifikationen [3] definierar säkra begäransmetoder som GET, HEAD, som inte ska ändra data på servern. För sådana förfrågningar, så länge som servern överensstämmer med specifikationen, finns det inget behov av att tillämpa CSRF-skydd.
Du kanske vill spela säkert och lägga till en nyckel till varje begäran, men tänk på att HTTP/1.1-specifikationen [3] tillåter närvaron av ett organ för alla förfrågningar, men för vissa förfrågningsmetoder (GET, HEAD, DELETE) semantiken för begärandekroppen är inte definierad och bör ignoreras. Därför kan nyckeln bara skickas i själva URL:en eller i HTTP-begärans huvud. Du måste skydda användaren från att oavsiktligt distribuera nyckeln som en del av en URL, till exempel i ett forum där nyckeln kan göras tillgänglig för en angripare. Därför bör förfrågningar med en nyckel i URL:en inte användas som adress att gå till, det vill säga undvika att gå till en sådan adress med klientskript, serveromdirigering, formuläråtgärd, hyperlänk på sidan, etc. för att dölja nyckeln som ingår i URL:en. De kan endast användas som interna förfrågningar av ett skript som använder XMLHttpRequest eller en wrapper som AJAX .
Det är viktigt att nyckeln (CSRF-token) inte är avsedd för en specifik begäran eller form, utan för alla användarförfrågningar i allmänhet. Därför räcker det med att läcka en CSRF-token från en URL som utför en enkel åtgärd eller ingen åtgärd alls, så att varje åtgärd, inte bara den som den nu kända URL:en är associerad med, förlorar skyddet mot begärandeförfalskning.
Det finns en mer stel version av den tidigare mekanismen, där en unik engångsnyckel är associerad med varje åtgärd. Denna metod är svårare att implementera och resurskrävande. Metoden används av vissa sajter och portaler, som Livejournal , Rambler , etc. För 2016 fanns det ingen information om fördelen med ett stelare alternativ jämfört med alternativet som använder en enda hemlig nyckel för varje session [4] .