Cross site request forgery (XSRF/CSRF)

CSRF eller Cross site request forgery blandas ibland ihop med xss, jag vill i detta inlägg klargöra skillnaderna och vad man som utvecklare kan göra för att förhindra CSRF. Jag vill också poängtera att detta inte är ett nytt säkerhetshål. I detta dokument från 2001 beskriver de redan problemet.

Cross site request forgery – förklarat med ett exempel

CSRF går ut på att en användare besöker en manipulerad sida som utför något på en annan sida. Om vi tänker oss användarna A och B, där användare B är hacker. Sedan har vi två sidor, en bloggsida och en banksida där båda användarna är kunder.

  • Användare A loggar in på sin bank
  • Användare B manipulerar bloggsidan med följande kod.
    <img src="http://www.minbank.se/Overforpengar.aspx?fran=A&till=B&belopp=10000" />
    
  • Användare A öppnar ett nytt fönster och besöker bloggsidan.

Det som händer i ovanstående scenario är att användare B utnyttjar banksidans tillit till användare A. Notera alltså att användare B (hackern) aldrig loggar in som användare A. Ur bankens perspektiv är det användare A som har flyttat pengarna, det är hans dator som har anropat sidan och eftersom han är inloggad så genomförs transaktionen. Andra vanliga saker en hacker kan göra via csrf är att byta lösenord eller e-postadress på ett konto eller skicka spam.

Till skillnad från xss där man utnyttjar användarens tillit till sidan och hackern försöker skicka hemlig information som bara tillhör den användaren till sig själv (exempelvis sessionsid), så utnyttjar man i csrf en sidas tillit till användaren.

Hur man skyddar sig

Precis som för xss så har microsoft släppt en produkt på codeplex som heter AntiCSRF. Det är en modul som man helt enkelt pluggar in i asp.net och får därmed ett skydd.
AntiCSRF fungerar på följande sätt

  • När användaren loggar in på sidan som skall skyddas från csrf skapas en hemlig nyckel som sparas i sessionen
  • I alla formulär på sidan läggs det till ett dolt fält (<input type=”hidden”>) där man skickar in den hemliga nyckeln
  • På sidan som tar emot formuläret kontrollerar man om värdet från det dolda fältet är samma som det som finns i sessionen

Ovanstående nyckelhantering bygger också på att den hemliga nyckeln med jämna mellanrum byts ut och att den endast är giltig i ett antal minuter.

iSEC Partners har släppt ett dokument där de går igenom mer i detalj hur detta skydd fungerar.

Problemet är att ovanstående skydd inte alltid fungerar. Exempelvis kan man använda xss för att hämta den hemliga nyckeln och sedan skicka med den nyckeln när man gör csrf. Därför är det viktigt att skydda sin sajt både från xss och csrf.

Andra metoder än ovanstående som försvårar men inte skyddar helt och hållet är

Kontrollera referer header
Det räcker inte att kontrollera referer eftersom det är relativt enkelt att manipulera referer. Därför kan det inte anses som en säker metod.

Tillåt endast POST
Det går utmärkt att genomföra csrf-attacker via POST, även om vårt exempel använde GET. Exempelvis genom att skapa en sida med ett förifyllt formulär som sedan skickas iväg automatiskt (form.submit()).

Kommentarer inaktiverade.

%d bloggare gillar detta: