I den h\u00e4r artikeln s\u00e5 beskrivs en CSRF-attack, hur den fungerar och vilka \u00e5tg\u00e4rder som du kan vidta f\u00f6r att f\u00f6rbereda dig f\u00f6r en s\u00e5dan.<\/p>\n
Kolla in v\u00e5r videoguide f\u00f6r att f\u00f6rst\u00e5 allt om CSRF-attacker<\/a><\/strong><\/p>\n En Cross-Site Request Forgery-attack, \u00e4ven k\u00e4nd som en CSRF-attack, lurar en autentiserad anv\u00e4ndare att utf\u00f6ra oavsiktliga \u00e5tg\u00e4rder. Detta sker genom inskickandet av skadliga beg\u00e4randen som ser normala ut.<\/p>\n Typiskt sett s\u00e5 inneb\u00e4r en CSRF-attack tillst\u00e5nds\u00e4ndrande beg\u00e4randen. Angriparen f\u00e5r ju exempelvis inte n\u00e5got svar. Exempel p\u00e5 s\u00e5dana beg\u00e4randen \u00e4r att radera en post, \u00e4ndra ett l\u00f6senord<\/a>, k\u00f6pa en produkt eller skicka ett meddelande. Dessa kan alla ske utan anv\u00e4ndarens vetskap.<\/p>\n Den illvilliga angriparen anv\u00e4nder vanligtvis social ingenj\u00f6rskonst f\u00f6r att skicka en intet ont anande anv\u00e4ndare en l\u00e4nk via chatt eller e-post.<\/p>\n N\u00e4r anv\u00e4ndaren klickar p\u00e5 l\u00e4nken s\u00e5 utf\u00f6rs sedan de kommandon som angriparen har st\u00e4llt in.<\/p>\n Om man exempelvis klickar p\u00e5 en l\u00e4nk s\u00e5 kan man \u00f6verf\u00f6ra pengar fr\u00e5n en anv\u00e4ndares konto. Den kan dessutom \u00e4ndra en anv\u00e4ndares e-postadress s\u00e5 att denne inte kan f\u00e5 tillg\u00e5ng till kontot igen.<\/p>\n Det f\u00f6rsta och mest avg\u00f6rande steget i en CSRF-attack \u00e4r att f\u00e5 anv\u00e4ndaren att initiera en beg\u00e4ran om att \u00e4ndra status medan han eller hon \u00e4r inloggad. Med CSRF-attacker s\u00e5 f\u00f6rs\u00f6ker angriparen f\u00e5 en autentiserad anv\u00e4ndare att omedvetet skicka in en skadlig webb-beg\u00e4ran till en webbplats eller en webb-applikation. Dessa beg\u00e4randen kan exempelvis best\u00e5 av cookies, URL-parametrar<\/a> och andra datatyper som verkar normala f\u00f6r anv\u00e4ndaren.<\/p>\n F\u00f6r att en CSRF-attack ska lyckas s\u00e5 m\u00e5ste f\u00f6ljande villkor uppfyllas:<\/p>\n Den vanligaste metoden f\u00f6r att genomf\u00f6ra CSRF-attacker \u00e4r att anv\u00e4nda cookies i applikationer med en svag SameSite-cookiepolicy. Webbl\u00e4sare inkluderar cookies automatiskt<\/a> och ofta anonymt. De sparar dessutom cookies som anv\u00e4nds av en dom\u00e4n i alla webb-beg\u00e4randen som en anv\u00e4ndare skickar till den dom\u00e4nen.<\/p>\n SameSite-cookiepolicy definierar hur webbl\u00e4saren behandlar cookien i sammanhang med surfning mellan olika webbplatser. Om den \u00e4r inst\u00e4lld p\u00e5 strikt s\u00e5 delas cookien inte i sammanhang d\u00e4r man surfar fr\u00e5n olika webbplatser. Som ett resultat s\u00e5 f\u00f6rhindras CSRF-attacker. Webbl\u00e4saren bifogar cookien i alla sammanhang mellan olika webbplatser om den \u00e4r inst\u00e4lld p\u00e5 none. Detta g\u00f6r applikationen s\u00e5rbar f\u00f6r CSRF-attacker.<\/p>\n N\u00e4r en anv\u00e4ndare omedvetet skickar in en skadlig beg\u00e4ran via en webbl\u00e4sare s\u00e5 f\u00e5r varje sparad cookie en beg\u00e4ran om att verka legitim f\u00f6r servern. Servern svarar sedan p\u00e5 beg\u00e4randet genom att exempelvis \u00e4ndra anv\u00e4ndarens konto, \u00e4ndra sessions-l\u00e4get eller returnera de beg\u00e4rda uppgifterna.<\/p>\n L\u00e5t oss titta n\u00e4rmare p\u00e5 tv\u00e5 exempel p\u00e5 CSRF-attacker, den ena med en GET-beg\u00e4ran och den andra med en POST-beg\u00e4ran.<\/p>\n Vi ska f\u00f6rst titta p\u00e5 en GET-beg\u00e4ran<\/a> som anv\u00e4nds av en webb-applikation f\u00f6r finansiella bank\u00e4renden. H\u00e4r utnyttjar attacken en GET-beg\u00e4ran och leverans av hyperl\u00e4nkar.<\/p>\n Anta att GET-beg\u00e4randet f\u00f6r \u00f6verf\u00f6ring av pengar ser ut ungef\u00e4r s\u00e5 h\u00e4r:<\/p>\n I det \u00e4kta beg\u00e4randet ovan s\u00e5 beg\u00e4r anv\u00e4ndaren att f\u00e5 \u00f6verf\u00f6ra 1 000 dollar till ett konto hos \u00c4ven om denna beg\u00e4ran \u00e4r tydlig, enkel och praktisk, s\u00e5 uts\u00e4tter den kontoinnehavaren f\u00f6r en CSRF-attack. Detta beror exempelvis p\u00e5 att beg\u00e4randet inte kr\u00e4ver n\u00e5gra detaljer som en angripare kanske inte k\u00e4nner till. F\u00f6r att inleda en attack s\u00e5 beh\u00f6ver en angripare bara \u00e4ndra parametrarna i denna beg\u00e4ran (beloppet och kontonumret) f\u00f6r att skapa en utf\u00f6rbar f\u00f6rfalskad beg\u00e4ran.<\/p>\n Det skadliga beg\u00e4randet skulle vara effektivt f\u00f6r alla anv\u00e4ndare p\u00e5 banken s\u00e5 l\u00e4nge som de har p\u00e5g\u00e5ende sessioner som hanteras av cookies.<\/p>\n S\u00e5 h\u00e4r skulle en f\u00f6rfalskad beg\u00e4ran om att \u00f6verf\u00f6ra 500 dollar till en hackers konto (h\u00e4r nummer N\u00e4r detta \u00e4r klart s\u00e5 m\u00e5ste angriparen komma p\u00e5 ett s\u00e4tt att lura anv\u00e4ndaren att skicka denna beg\u00e4ran medan han \u00e4r inloggad i sin n\u00e4tbanksapplikation. Ett s\u00e4tt att g\u00f6ra detta p\u00e5 \u00e4r exempelvis att skapa en harml\u00f6s hyperl\u00e4nk som f\u00e5r anv\u00e4ndarens uppm\u00e4rksamhet. L\u00e4nken kan se ut s\u00e5 h\u00e4r:<\/p>\n Eftersom angriparen har hittat de korrekta e-postadresserna<\/a> till sina m\u00e5l s\u00e5 kan de skicka detta via e-post till m\u00e5nga bankkunder. De som klickar p\u00e5 l\u00e4nken medan de \u00e4r inloggade skulle utl\u00f6sa beg\u00e4randet om att skicka 500 dollar till angriparen fr\u00e5n det inloggade kontot.<\/p>\n L\u00e5t oss se hur samma finansinstitut skulle uppleva en CSRF om de endast accepterade POST-beg\u00e4randen<\/a>. I det h\u00e4r fallet s\u00e5 skulle den hyperl\u00e4nk som anv\u00e4ndes i exemplet med GET-beg\u00e4randet inte fungera. D\u00e4rf\u00f6r skulle en lyckad CSRF-attack kr\u00e4va att en angripare skapar ett HTML-formul\u00e4r. Det \u00e4kta beg\u00e4randet om att skicka 1 000 dollar f\u00f6r en k\u00f6pt produkt skulle se ut s\u00e5 h\u00e4r:<\/p>\n Det h\u00e4r POST-beg\u00e4randet kr\u00e4ver en cookie f\u00f6r att fastst\u00e4lla anv\u00e4ndarens identitet, det belopp som han\/hon vill skicka och det konto som han\/hon vill skicka. Angripare kan \u00e4ndra det h\u00e4r beg\u00e4randet f\u00f6r att utf\u00f6ra en CSRF-attack.<\/p>\n Det kr\u00e4vs bara att man l\u00e4gger till en \u00e4kta cookie i en f\u00f6rfalskad beg\u00e4ran f\u00f6r att f\u00e5 servern att bearbeta \u00f6verf\u00f6ringen. Man kan exempelvis g\u00f6ra detta genom att skapa en ofarlig hyperl\u00e4nk som tar anv\u00e4ndaren till en utl\u00f6sande webbsida som ser ut s\u00e5 h\u00e4r:<\/p>\n Vi har redan st\u00e4llt in parametrarna f\u00f6r belopp och konto i formul\u00e4ret ovan. N\u00e4r en autentiserad anv\u00e4ndare sedan bes\u00f6ker sidan s\u00e5 l\u00e4gger webbl\u00e4saren till sessions-cookien innan den vidarebefordrar beg\u00e4randet till servern. Servern vidarebefordrar sedan 500 dollar till hackarens konto.<\/p>\n Det finns flera metoder f\u00f6r att f\u00f6rhindra och drastiskt mildra potentiella CSRF-attacker p\u00e5 din webbplats eller webb-applikation, bland annat:<\/p>\n En CSRF-s\u00e4ker webbplats tilldelar varje session en unik token och delar den med servern och klientens webbl\u00e4sare<\/a>. N\u00e4r en webbl\u00e4sare skickar en k\u00e4nslig beg\u00e4ran s\u00e5 f\u00f6rv\u00e4ntar sig servern att den inneh\u00e5ller denna tilldelade CSRF-token. Om den har fel token s\u00e5 sl\u00e4pper servern den. Denna CSRF-token lagras inte i sessions-cookies i klientens webbl\u00e4sare av s\u00e4kerhetssk\u00e4l.<\/p>\n \u00c4ven om CSRF-token \u00e4r en utm\u00e4rkt s\u00e4kerhets\u00e5tg\u00e4rd s\u00e5 \u00e4r den h\u00e4r metoden inte s\u00e4ker mot angrepp. N\u00e5gra av de s\u00e5rbarheter som f\u00f6ljer med en CSRF-token \u00e4r f\u00f6ljande:<\/p>\n En angripare beh\u00f6ver bara ta bort denna token och skicka den s\u00e5 h\u00e4r f\u00f6r att utf\u00f6ra attacken:<\/p>\n Efter detta s\u00e5 kan en angripare sedan logga in i en applikation med sitt konto f\u00f6r att f\u00e5 en token, exempelvis:<\/p>\n Och eftersom dessa tokens \u00e4r poolade s\u00e5 kan angriparen kopiera och anv\u00e4nda samma token f\u00f6r att logga in p\u00e5 ett annat anv\u00e4ndarkonto, eftersom du kommer att anv\u00e4nda den igen:<\/p>\n En angripare kan allts\u00e5 logga in i en applikation med sitt konto och \u00f6ppna cookie-filen f\u00f6r att se f\u00f6ljande:<\/p>\n De kan sedan anv\u00e4nda denna information f\u00f6r att skapa en annan cookie f\u00f6r att slutf\u00f6ra attacken<\/p>\n En annan strategi f\u00f6r att f\u00f6rhindra CSRF-attacker \u00e4r att anv\u00e4nda referrer-huvudet. I HTTP s\u00e5 anger referrer-huvudet beg\u00e4randenas ursprung. De anv\u00e4nds exempelvis f\u00f6r att utf\u00f6ra analyser<\/a>, optimering och loggning.<\/p>\n Du kan dessutom aktivera kontroll av referrer-huvuden p\u00e5 serversidan f\u00f6r att f\u00f6rhindra CSRF-attacker. Serverns sida kontrollerar k\u00e4llursprunget f\u00f6r beg\u00e4randet och fastst\u00e4ller m\u00e5l-ursprunget f\u00f6r beg\u00e4randet. Om de st\u00e4mmer \u00f6verens s\u00e5 till\u00e5ts beg\u00e4randet. Vid tillf\u00e4llen d\u00e5 de inte st\u00e4mmer \u00f6verens s\u00e5 sl\u00e4pper servern beg\u00e4randet.<\/p>\n Det \u00e4r mycket enklare att anv\u00e4nda referrer-huvudet \u00e4n att anv\u00e4nda tokens eftersom det exempelvis inte kr\u00e4ver en individuell anv\u00e4ndaridentifiering.<\/p>\n Liksom CSRF-tokens s\u00e5 har referrer-huvudet n\u00e5gra betydande s\u00e5rbarheter.<\/p>\n F\u00f6r det f\u00f6rsta s\u00e5 \u00e4r referrer-huvuden inte obligatoriska. Som ett resultat s\u00e5 skickar vissa webbplatser beg\u00e4randen utan dem. Om CSRF inte har en policy f\u00f6r att hantera beg\u00e4randen utan huvudet s\u00e5 kan angripare anv\u00e4nda beg\u00e4randen utan huvudet f\u00f6r att utf\u00f6ra tillst\u00e5nds\u00e4ndrings-attacker.<\/p>\n Dessutom s\u00e5 har den h\u00e4r metoden blivit mindre effektiv i och med det senaste inf\u00f6randet av referrer-policyn<\/a>. Denna specifikation f\u00f6rhindrar webbadress-l\u00e4ckage till andra dom\u00e4ner och ger anv\u00e4ndarna st\u00f6rre kontroll \u00f6ver informationen i referrer-huvudet. De kan exempelvis v\u00e4lja att exponera en del av informationen i referrer-huvudet eller att inaktivera den genom att l\u00e4gga till en metadata-tagg p\u00e5 HTML-sidan, som visas nedan:<\/p>\n Ovanst\u00e5ende kod tar bort referrer-huvudet f\u00f6r alla beg\u00e4randen fr\u00e5n den h\u00e4r sidan. Som ett resultat s\u00e5 blir det sv\u00e5rt f\u00f6r applikationer som f\u00f6rlitar sig p\u00e5 referrer-huvuden att f\u00f6rhindra CSRF-attacker fr\u00e5n en s\u00e5dan sida.<\/p>\n F\u00f6rutom att anv\u00e4nda referrer-huvudet och CSRF-tokens s\u00e5 finns det ett tredje och mycket enklare alternativ: att v\u00e4lja en s\u00e4ker hosting-stj\u00e4nst som Kinsta<\/a> f\u00f6r dina webbplatser och webbapplikationer. Som ett resultat s\u00e5 f\u00e5r du en mycket starkare och s\u00e4krare barri\u00e4r mellan angripare och dina anv\u00e4ndare.<\/p>\n Ut\u00f6ver kritiska s\u00e4kerhetsfunktioner som automatisk s\u00e4kerhetskopiering<\/a>, tv\u00e5faktorsautentisering<\/a> och SFTP \u00f6ver SSH-protokoll<\/a> s\u00e5 erbjuder Kinsta’s Cloudflare-integrering<\/a> skydd p\u00e5 enterprise-niv\u00e5 med ett IP-baserat skydd och brandv\u00e4ggsskydd.<\/p>\n Specifikt s\u00e5 har Kinsta f\u00f6r n\u00e4rvarande cirka 60 anpassade brandv\u00e4ggsregler som hj\u00e4lper till att f\u00f6rhindra skadliga attacker och hantera allvarliga oautentiserade s\u00e5rbarheter i plugins och teman. Detta inkluderar exempelvis specifika regler som letar efter CSRF-s\u00e5rbarheter.<\/p>\n Cross-site request forgery (CSRF) \u00e4r en attack som lurar autentiserade anv\u00e4ndare att oavsiktligt initiera beg\u00e4randen om tillst\u00e5nds\u00e4ndringar. De riktar sig mot applikationer som inte kan skilja mellan giltiga och f\u00f6rfalskade beg\u00e4randen om tillst\u00e5nds\u00e4ndring.<\/p>\n CSRF kan bara lyckas i applikationer som f\u00f6rlitar sig p\u00e5 sessions-cookies f\u00f6r att identifiera inloggade anv\u00e4ndare och som har en svag SameSite-cookiepolicy. De beh\u00f6ver dessutom en server som accepterar beg\u00e4randen som inte inneh\u00e5ller ok\u00e4nda parametrar som exempelvis l\u00f6senord. Hackers kan skicka skadliga attacker med hj\u00e4lp av antingen GET eller POST.<\/p>\n Anv\u00e4ndning av CSRF-tokens eller kontroll av referrer-huvudet kan visserligen f\u00f6rhindra vissa CSRF-attacker. B\u00e5da \u00e5tg\u00e4rderna har dock potentiella s\u00e5rbarheter som kan g\u00f6ra dina f\u00f6rebyggande \u00e5tg\u00e4rder v\u00e4rdel\u00f6sa om du inte \u00e4r f\u00f6rsiktig.<\/p>\nVad \u00e4r en CSRF-attack?<\/h2>\n
![\"Hur](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/11\/CSRF-Attack-Okta.png\")
Hur fungerar en CSRF-attack?<\/h2>\n
\n
CSRF f\u00f6r en GET-beg\u00e4ran<\/h2>\n
GET https:\/\/xymbank.com\/online\/transfer?amount=1000&accountNumber=547895 HTTP\/1.1<\/code><\/pre>\n547895<\/code> som betalning f\u00f6r k\u00f6pta produkter.<\/p>\n654585<\/code>) se ut. Observera att exemplet nedan \u00e4r en starkt f\u00f6renklad version av de steg som ing\u00e5r i en CSRF-attack.<\/p>\nGET https:\/\/xymbank.com\/online\/transfer?amount=500&accountNumber=654585 HTTP\/1.1<\/code><\/pre>\n<a\nhref=\"https:\/\/xymbank.com\/online\/transfer?amount=500&accountNumber=654585\">Click here to get more information<\/a>.<\/code><\/pre>\nCSRF f\u00f6r en POST-beg\u00e4ran<\/h2>\n
POST \/online\/transfer HTTP\/1.1\nHost: xymbank.com\nContent-Type: application\/x-www-form-urlencoded\nCookie: session=FRyhityeQkAPzeQ5gHgTvlyxHJYhg\namount=1000\naccount=547895<\/code><\/pre>\n<html>\n<body>\n<form action=\"https:\/\/xymbank.com\/online\/transfer\" method=\"POST\">\n<input type=\"hidden\" name=\"amount\" value=\"500\"\/>\n<input type=\"hidden\" name=\"account\" value=\"654585\" \/>\n<\/form>\n<script>\ndocument.forms[0].submit();\n<\/script>\n<\/body>\n<\/html><\/code><\/pre>\n3 s\u00e4tt att minska CSRF-attacker<\/h2>\n
\n
S\u00e5 h\u00e4r f\u00f6rhindrar du CSRF-attacker med hj\u00e4lp av CSRF-token<\/h2>\n
Potentiella s\u00e5rbarheter med CSRF-token<\/h3>\n
\n
POST \/change_password\nPOST body:\npassword=pass123&csrf_token=93j9d8eckke20d433<\/code><\/pre>\nPOST \/change_password\nPOST body:\npassword=pass123<\/code><\/pre>\n\n
[application_url].com?csrf_token=93j9d8eckke20d433<\/code><\/pre>\n\n
Csrf_token:93j9d8eckke20d433<\/code><\/pre>\n\n
S\u00e5 h\u00e4r f\u00f6rhindrar du CSRF-attacker med Referrer-huvudet<\/h2>\n
Potentiella s\u00e5rbarheter med referrer-huvudet<\/h3>\n
<meta name=\"referrer\" content=\"no-referrer\"><\/code><\/pre>\nHur Kinsta skyddar mot CSRF-attacker<\/h2>\n
Sammanfattning<\/h2>\n