Sårbarheter på webben är utbredda och ökar ständigt. Det är viktigare än någonsin att upprätthålla användarnas säkerhet och integritet. Att inte åtgärda webbsårbarheter kan leda till ett förstört rykte och höga böter från tillsynsmyndigheter. Du kommer dessutom att förlora användarnas förtroende.

Webbplatser och webb-applikationer är sårbara för skadlig kod, skräppost och andra attacker – den här artikeln fokuserar på en sådan angreppsvektor – CSRF-attacker (Cross-Site Request Forgery). CSRF-attacker är särskilt bekymmersamma eftersom de kan ske utan användarens vetskap. De är även svåra för en utvecklare eller webbplats-ägare att upptäcka. De skadliga begärandena är nämligen väldigt lika äkta begäranden.

I den här artikeln så beskrivs en CSRF-attack, hur den fungerar och vilka åtgärder som du kan vidta för att förbereda dig för en sådan.

Kolla in vår videoguide för att förstå allt om CSRF-attacker

Vad är en CSRF-attack?

En Cross-Site Request Forgery-attack, även känd som en CSRF-attack, lurar en autentiserad användare att utföra oavsiktliga åtgärder. Detta sker genom inskickandet av skadliga begäranden som ser normala ut.

Hur CSRF-attacker fungerar. (Bildkälla: Okta)
Hur CSRF-attacker fungerar. (Bildkälla: Okta)

Typiskt sett så innebär en CSRF-attack tillståndsändrande begäranden. Angriparen får ju exempelvis inte något svar. Exempel på sådana begäranden är att radera en post, ändra ett lösenord, köpa en produkt eller skicka ett meddelande. Dessa kan alla ske utan användarens vetskap.

Den illvilliga angriparen använder vanligtvis social ingenjörskonst för att skicka en intet ont anande användare en länk via chatt eller e-post.

När användaren klickar på länken så utförs sedan de kommandon som angriparen har ställt in.

Om man exempelvis klickar på en länk så kan man överföra pengar från en användares konto. Den kan dessutom ändra en användares e-postadress så att denne inte kan få tillgång till kontot igen.

Hur fungerar en CSRF-attack?

Det första och mest avgörande steget i en CSRF-attack är att få användaren att initiera en begäran om att ändra status medan han eller hon är inloggad. Med CSRF-attacker så försöker angriparen få en autentiserad användare att omedvetet skicka in en skadlig webb-begäran till en webbplats eller en webb-applikation. Dessa begäranden kan exempelvis bestå av cookies, URL-parametrar och andra datatyper som verkar normala för användaren.

För att en CSRF-attack ska lyckas så måste följande villkor uppfyllas:

  • En autentiserad användare måste vara inloggad i en webb-applikation som använder cookies för sessions-hantering.
  • En angripare måste skapa en förfalskad begäran som ändrar tillstånd.
  • Äkta begäranden som hanteras av målservern får inte innehålla oförutsägbara parametrar. Begärandet bör exempelvis inte förvänta sig ett lösenord som en parameter för verifiering innan det tillstånds-förändrande begärandet inleds.

Den vanligaste metoden för att genomföra CSRF-attacker är att använda cookies i applikationer med en svag SameSite-cookiepolicy. Webbläsare inkluderar cookies automatiskt och ofta anonymt. De sparar dessutom cookies som används av en domän i alla webb-begäranden som en användare skickar till den domänen.

SameSite-cookiepolicy definierar hur webbläsaren behandlar cookien i sammanhang med surfning mellan olika webbplatser. Om den är inställd på strikt så delas cookien inte i sammanhang där man surfar från olika webbplatser. Som ett resultat så förhindras CSRF-attacker. Webbläsaren bifogar cookien i alla sammanhang mellan olika webbplatser om den är inställd på none. Detta gör applikationen sårbar för CSRF-attacker.

När en användare omedvetet skickar in en skadlig begäran via en webbläsare så får varje sparad cookie en begäran om att verka legitim för servern. Servern svarar sedan på begärandet genom att exempelvis ändra användarens konto, ändra sessions-läget eller returnera de begärda uppgifterna.

Låt oss titta närmare på två exempel på CSRF-attacker, den ena med en GET-begäran och den andra med en POST-begäran.

CSRF för en GET-begäran

Vi ska först titta på en GET-begäran som används av en webb-applikation för finansiella bankärenden. Här utnyttjar attacken en GET-begäran och leverans av hyperlänkar.

Anta att GET-begärandet för överföring av pengar ser ut ungefär så här:

GET https://xymbank.com/online/transfer?amount=1000&accountNumber=547895 HTTP/1.1

I det äkta begärandet ovan så begär användaren att få överföra 1 000 dollar till ett konto hos 547895 som betalning för köpta produkter.

Även om denna begäran är tydlig, enkel och praktisk, så utsätter den kontoinnehavaren för en CSRF-attack. Detta beror exempelvis på att begärandet inte kräver några detaljer som en angripare kanske inte känner till. För att inleda en attack så behöver en angripare bara ändra parametrarna i denna begäran (beloppet och kontonumret) för att skapa en utförbar förfalskad begäran.

Det skadliga begärandet skulle vara effektivt för alla användare på banken så länge som de har pågående sessioner som hanteras av cookies.

Så här skulle en förfalskad begäran om att överföra 500 dollar till en hackers konto (här nummer 654585) se ut. Observera att exemplet nedan är en starkt förenklad version av de steg som ingår i en CSRF-attack.

GET https://xymbank.com/online/transfer?amount=500&accountNumber=654585 HTTP/1.1

När detta är klart så måste angriparen komma på ett sätt att lura användaren att skicka denna begäran medan han är inloggad i sin nätbanksapplikation. Ett sätt att göra detta på är exempelvis att skapa en harmlös hyperlänk som får användarens uppmärksamhet. Länken kan se ut så här:

<a
href="https://xymbank.com/online/transfer?amount=500&accountNumber=654585">Click here to get more information</a>.

Eftersom angriparen har hittat de korrekta e-postadresserna till sina mål så kan de skicka detta via e-post till många bankkunder. De som klickar på länken medan de är inloggade skulle utlösa begärandet om att skicka 500 dollar till angriparen från det inloggade kontot.

CSRF för en POST-begäran

Låt oss se hur samma finansinstitut skulle uppleva en CSRF om de endast accepterade POST-begäranden. I det här fallet så skulle den hyperlänk som användes i exemplet med GET-begärandet inte fungera. Därför skulle en lyckad CSRF-attack kräva att en angripare skapar ett HTML-formulär. Det äkta begärandet om att skicka 1 000 dollar för en köpt produkt skulle se ut så här:

POST /online/transfer HTTP/1.1
Host: xymbank.com
Content-Type: application/x-www-form-urlencoded
Cookie: session=FRyhityeQkAPzeQ5gHgTvlyxHJYhg
amount=1000
account=547895

Det här POST-begärandet kräver en cookie för att fastställa användarens identitet, det belopp som han/hon vill skicka och det konto som han/hon vill skicka. Angripare kan ändra det här begärandet för att utföra en CSRF-attack.

Det krävs bara att man lägger till en äkta cookie i en förfalskad begäran för att få servern att bearbeta överföringen. Man kan exempelvis göra detta genom att skapa en ofarlig hyperlänk som tar användaren till en utlösande webbsida som ser ut så här:

<html>
<body>
<form action="https://xymbank.com/online/transfer" method="POST">
<input type="hidden" name="amount" value="500"/>
<input type="hidden" name="account" value="654585" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>

Vi har redan ställt in parametrarna för belopp och konto i formuläret ovan. När en autentiserad användare sedan besöker sidan så lägger webbläsaren till sessions-cookien innan den vidarebefordrar begärandet till servern. Servern vidarebefordrar sedan 500 dollar till hackarens konto.

3 sätt att minska CSRF-attacker

Det finns flera metoder för att förhindra och drastiskt mildra potentiella CSRF-attacker på din webbplats eller webb-applikation, bland annat:

  • Användning av CSRF-token
  • Man kan även nyttja referrer-huvudet
  • Genom att exempelvis välja en säkerhetsfokuserad hosting-lösning, som Kinsta

Så här förhindrar du CSRF-attacker med hjälp av CSRF-token

En CSRF-säker webbplats tilldelar varje session en unik token och delar den med servern och klientens webbläsare. När en webbläsare skickar en känslig begäran så förväntar sig servern att den innehåller denna tilldelade CSRF-token. Om den har fel token så släpper servern den. Denna CSRF-token lagras inte i sessions-cookies i klientens webbläsare av säkerhetsskäl.

Potentiella sårbarheter med CSRF-token

Även om CSRF-token är en utmärkt säkerhetsåtgärd så är den här metoden inte säker mot angrepp. Några av de sårbarheter som följer med en CSRF-token är följande:

  • Valideringsomgång – Vissa applikationer hoppar över verifieringssteget om de inte hittar någon token. Om en angripare får tillgång till kod som innehåller en token så kan han eller hon ta bort denna token och utföra en CSRF-attack. Om en giltig begäran till en server ser ut så här:
POST /change_password
POST body:
password=pass123&csrf_token=93j9d8eckke20d433

En angripare behöver bara ta bort denna token och skicka den så här för att utföra attacken:

POST /change_password
POST body:
password=pass123
  • Vissa applikationer har en pool av tokens för att validera användarsessioner i stället för att tilldela en specifik token till en session. En angripare behöver endast få tag på en av dessa tokens som redan finns i poolen för att kunna utge sig för att vara en av webbplatsens användare.

Efter detta så kan en angripare sedan logga in i en applikation med sitt konto för att få en token, exempelvis:

[application_url].com?csrf_token=93j9d8eckke20d433

Och eftersom dessa tokens är poolade så kan angriparen kopiera och använda samma token för att logga in på ett annat användarkonto, eftersom du kommer att använda den igen:

  • CSRFs kan vara tokens som kopieras till en cookie– Vissa applikationer kopierar parametrarna för en token till en användares cookie. Om en angripare får tillgång till en sådan cookie så kan han eller hon enkelt skapa en annan cookie, placera den i en webbläsare och utföra en CSRF-attack.

En angripare kan alltså logga in i en applikation med sitt konto och öppna cookie-filen för att se följande:

Csrf_token:93j9d8eckke20d433

De kan sedan använda denna information för att skapa en annan cookie för att slutföra attacken

  • Ogiltiga tokens – Vissa applikationer matchar inte CSRF-tokens till en användarsession. I sådana fall så kan en angripare verkligen logga in i en session, få en CSRF-token liknande de som nämndes ovan och använda den för att iscensätta en CSRF-attack mot ett offers session.

Så här förhindrar du CSRF-attacker med Referrer-huvudet

En annan strategi för att förhindra CSRF-attacker är att använda referrer-huvudet. I HTTP så anger referrer-huvudet begärandenas ursprung. De används exempelvis för att utföra analyser, optimering och loggning.

Du kan dessutom aktivera kontroll av referrer-huvuden på serversidan för att förhindra CSRF-attacker. Serverns sida kontrollerar källursprunget för begärandet och fastställer mål-ursprunget för begärandet. Om de stämmer överens så tillåts begärandet. Vid tillfällen då de inte stämmer överens så släpper servern begärandet.

Det är mycket enklare att använda referrer-huvudet än att använda tokens eftersom det exempelvis inte kräver en individuell användaridentifiering.

Potentiella sårbarheter med referrer-huvudet

Liksom CSRF-tokens så har referrer-huvudet några betydande sårbarheter.

För det första så är referrer-huvuden inte obligatoriska. Som ett resultat så skickar vissa webbplatser begäranden utan dem. Om CSRF inte har en policy för att hantera begäranden utan huvudet så kan angripare använda begäranden utan huvudet för att utföra tillståndsändrings-attacker.

Dessutom så har den här metoden blivit mindre effektiv i och med det senaste införandet av referrer-policyn. Denna specifikation förhindrar webbadress-läckage till andra domäner och ger användarna större kontroll över informationen i referrer-huvudet. De kan exempelvis välja att exponera en del av informationen i referrer-huvudet eller att inaktivera den genom att lägga till en metadata-tagg på HTML-sidan, som visas nedan:

<meta name="referrer" content="no-referrer">

Ovanstående kod tar bort referrer-huvudet för alla begäranden från den här sidan. Som ett resultat så blir det svårt för applikationer som förlitar sig på referrer-huvuden att förhindra CSRF-attacker från en sådan sida.

Hur Kinsta skyddar mot CSRF-attacker

Förutom att använda referrer-huvudet och CSRF-tokens så finns det ett tredje och mycket enklare alternativ: att välja en säker hosting-stjänst som Kinsta för dina webbplatser och webbapplikationer. Som ett resultat så får du en mycket starkare och säkrare barriär mellan angripare och dina användare.

Utöver kritiska säkerhetsfunktioner som automatisk säkerhetskopiering, tvåfaktorsautentisering och SFTP över SSH-protokoll så erbjuder Kinsta’s Cloudflare-integrering skydd på enterprise-nivå med ett IP-baserat skydd och brandväggsskydd.

Specifikt så har Kinsta för närvarande cirka 60 anpassade brandväggsregler som hjälper till att förhindra skadliga attacker och hantera allvarliga oautentiserade sårbarheter i plugins och teman. Detta inkluderar exempelvis specifika regler som letar efter CSRF-sårbarheter.

Sammanfattning

Cross-site request forgery (CSRF) är en attack som lurar autentiserade användare att oavsiktligt initiera begäranden om tillståndsändringar. De riktar sig mot applikationer som inte kan skilja mellan giltiga och förfalskade begäranden om tillståndsändring.

CSRF kan bara lyckas i applikationer som förlitar sig på sessions-cookies för att identifiera inloggade användare och som har en svag SameSite-cookiepolicy. De behöver dessutom en server som accepterar begäranden som inte innehåller okända parametrar som exempelvis lösenord. Hackers kan skicka skadliga attacker med hjälp av antingen GET eller POST.

Användning av CSRF-tokens eller kontroll av referrer-huvudet kan visserligen förhindra vissa CSRF-attacker. Båda åtgärderna har dock potentiella sårbarheter som kan göra dina förebyggande åtgärder värdelösa om du inte är försiktig.

Genom att migrera till en säker hosting-plattform som Kinsta så säkrar du dina webbplatser eller webbappar från CSRF-attacker. Dessutom så förhindrar Kinsta’s integrering med Cloudflare specifika CSRF-attacker.

Salman Ravoof

Salman Ravoof är en självlärd webbutvecklare, författare, skapare och en stor beundrare av fri och öppen källkod (FOSS). Förutom teknik är han intresserad av vetenskap, filosofi, fotografi, konst, katter och mat. Lär dig mer om honom på hans hemsida och kontakta Salman på X.