CSRF, denna förkortning dyker upp om och om igen i uppdateringsnotiserna i WordPress Core. Metoden bakom detta är nu gammal hatt och utnyttjar webbläsarens vanligtvis rikliga cookies. Lyckligtvis kan du dock skydda dig mot Cross Site Request Forgery ganska enkelt. Allt du behöver är lite tid och uppmärksamhet.

Du använder säkert ett antal tjänster som erbjuder möjligheten att förbli inloggad även när du har lämnat webbplatsen. Om du sedan besöker webbplatsen igen behöver du inte ange dina inloggningsuppgifter på nytt, utan är inloggad direkt. Det är förstås bra eftersom du - precis som vid lösenordshantering eller så kallad single sign-on - slipper fylla i formulär.

Följande sker i bakgrunden: När du loggar in på webbplatsen för första gången placerar webbplatsen en cookie i din webbläsare. Detta är en liten textfil där viss information kan lagras. När du förblir inloggad är detta en slumpmässigt genererad sträng.

Nästa gång du besöker webbplatsen kontrollerar servern denna sträng och om den kan hitta motsvarande motsvarighet loggar den in dig automatiskt. Detta är också anledningen till att du loggas ut överallt när du tömmer webbläsarens cache. Eftersom alla kakor också raderas under denna process.

CSRF-attacker är i grund och botten ett missbruk av förtroendet.

Som du kan se är tjänsten som läser kakorna lurad i en motsvarande attack. Jag kommer nedan att förklara hur exakt detta sker med hjälp av två exempel.

Faran med denna manipulation ligger i att någon gör ändringar i din Facebook-profil i ditt namn, till exempel. Cross Site Request Forgery är dock ofta också beroende av nätfiske. Även här blir förtroendet relevant - till exempel förtroendet för avsändarna av e-postmeddelanden.

Hur utsatt är WordPress?

Du har förmodligen inte hört termen Cross Site Request Forgery så ofta som du har hört den. brute force-attacker eller Cross Site Scripting. Det finns en anledning till detta: den ideella organisationen OWASP (Open Web Application Security Project) publicerar regelbundet en lista över de tio mest kritiska sårbarheterna i webbapplikationer. CSRF har under årens lopp hamnat allt längre ner på listan över säkerhetsrisker och har nu försvunnit från topp 10.

Detta beror förmodligen delvis på att CSRF-attacker är nästan lika gamla som själva internet. Professionella utvecklare är numera vana vid att skydda sin kod mot dem. Säkerhetsrisker är alltså ganska enkla och snabba att åtgärda.

WordPress är också på sin vakt. Säkerhetsuppdatering 4.7.5 publicerades till exempel på Mai , som rättade sex sårbarheter som hackare kunde ha använt för att starta en attack via cross-site scripting eller cross-site request forgery. Cross-site scripting anses dock ofta vara mycket farligare.

Dessutom tenderar frågan om Cross Site Request Forgery att vara mer relevant för plugins och appar än för webbdesign, byråer och små och medelstora företag. Detta beror på att skydd mot CSRF också är en fråga om programmering. CSRF kan till exempel bli relevant vid köp i plugins.

Men hur fungerar allt?

Anatomi av Cross Site Request Forgery (förfalskning av begäranden från olika webbplatser)

Den grundläggande idén bakom en CSRF-attack är relativt enkel och sker vanligtvis i två steg:

• Offret luras att ladda en manipulerad webbplats eller klicka på en länk, till exempel genom att få det att se ut som om meddelandet kommer från en betrodd person. Eller så utnyttjas människans nyfikenhet. Med andra ord spelar phishing en viktig roll i denna typ av angrepp.
• När de manipulerade länkarna eller webbplatserna laddas eller klickar på dem utför offrets webbläsare en HTTP-förfrågan utan att offret märker något.

Två relativt enkla exempel illustrerar hur en sådan attack fungerar.

Låt oss anta att Justus vill överföra 100 euro till Bob via webbplatsen www.bank.de och att Skinny väntar på att utföra en CSRF-attack. Skinny kan använda GET- eller POST-metoden för sin attack.

Förresten kommer följande exempel från följande källor:

• "Cross Site Request Forgery (CSRF)" - OWASP:s granskningsartikel
• "Förhindra CSRF-attacker i WordPress med nonces" - genom att qnimate.com

Cross Site Request Forgery med GET-metoden

GET-metoden används för att begära en resurs från en server, till exempel en HTML-fil. De nödvändiga parametrarna för anropet läggs helt enkelt till i URL:en. Och som vi redan vet från SQL-injektioner: En URL är relativt lätt att manipulera.

Justus loggar in på www.bank.de och matar in alla nödvändiga uppgifter. Följande (helt fiktiva) uppgifter skulle överföras till servern:

GET http://bank.de/transfer.do?acct=BOB&betrag=100 HTTP/1.1

Skinny konstruerar nu en URL som överför 100 000 euro till hans eget konto i stället. Det ser ut så här:

http://bank.de/transfer.do?acct=SKINNY&betrag=100000

Naturligtvis måste Justus utföra den handling som döljer sig bakom den falska länken. Därför skickar Skinny Justus ett mail med en falsk länk. HTML-koden kan till exempel se ut så här:

<a href="http://bank.de/transfer.do?acct=SKINNY&betrag=100000">Wer dieses Rätsel nicht lösen kann, ist kein echter Detektiv!</a>

Eller så skickar han honom ett e-postmeddelande med en "osynlig" (eftersom den har 0 x 0 pixlar) bild. När webbläsaren försöker ladda bilden får han tillgång till webbadressen utan att Justus ens märker det:

<img src="http://bank.de/transfer.do?acct=SKINNY&betrag=100000" width="0" height="0" border="0">

När Justus - medvetet eller omedvetet - ringer upp länken skickas parametrarna till servern, överföringen utlöses och 100 000 euro försvinner från hans konto.

Justus måste naturligtvis klicka på länken medan han är inloggad. Men om det tyvärr finns en inloggningscookie från hans bank i hans webbläsare fungerar attacken även om han inte har webbplatsen öppen för tillfället.

Det är just detta som gör Cross Site Request Forgery så försåtligt: Justus är förmodligen inte ens medveten om att kakan existerar.

Cross Site Request Forgery med POST-metoden

GET-metoden kan användas i länkar och är därför särskilt lätt att sprida. Leverantörerna kan dock nu se till att GET-förfrågningar i princip inte får skrivtillstånd.

POST-metoden kvarstår: Här överförs data till en server så att den kan bearbeta dem vidare. Uppgifterna är inte en del av URL:en, utan läggs till i huvudet.

Det kan låta lite krångligt, men du känner säkert till användningsområdet eftersom formulär fungerar på detta sätt.

För vår anfallare Skinny innebär detta att han måste anstränga sig mer men ändå kan nå målet.

Samma scenario: Justus vill överföra pengar till Bob. Därför fyller han i följande formulär på www.bank.de:

<form method="POST" action="geld_ueberweisen.php">

    <input type="text" name="von">

    <input type="text" name="an">

    <input type="text" name="betrag_in_euro">

    <input type="submit">

</form>

Detta skickar kommandot geld_ueberweisen.php, som ser ut så här:

if(isset($_FORM["von"]) && isset($_FORM["an"]) &&isset($_FORM["menge_in_euro"]) && isset($_CMOKIE["user_eingeloggt"]))

{

    transMoney("von", "an", "betrag");

    echo "Überweisung erfolgreich!";

}

Som du kan se använder koden cookien för att först kontrollera om Justus är inloggad. Först därefter utförs överföringen.

Skinny lägger nu in ett osynligt formulär på en manipulerad webbplats, till exempel:

<form method="POST" action="http://www.bank.de/geld_ueberweisen.php">

    <input type="text" name="von" value="Justus" style="display: hidden">

    <input type="text" name="an" value="Skinny" style="display: hidden">

    <input type="text" name="betrag_in_euro" value="100000" style="display: hidden">

    <input type="submit" value="Wer dieses Rätsel nicht lösen kann, ist kein echter Detektiv!">

</form>

Han skickar länken till den manipulerade webbplatsen till Justus. Han känner sig utmanad, klickar på knappen för att se pusslet - och utför utan att veta det funktionen geld_ueberweisen.php. Eftersom detta hittar en motsvarande cookie i hans webbläsare överförs 100 000 euro till Skinny igen.

Attack via omvägar

Det är därför det kallas för cross-site request forgery: kommandot skickas vanligtvis från en annan webbplats. För att angripa webbplats A lägger han in skadlig kod på webbplats B. Offret lockas sedan hit så att hans webbläsare utför koden. Sedan lurar han det intet ont anande offret hit så att hans webbläsare exekverar koden.

Hur du skyddar dig mot CSRF-attacker

Den goda nyheten: Cross Site Request Forgery har varit känt i flera år. Risken är känd och utvecklingen arbetar särskilt för att eliminera den.

Den dåliga nyheten är att du inte kan skydda dig mot det på den tekniska sidan. WordPress-kärnan är numera relativt väl skyddad, och som du kan se i de pågående uppdateringarna arbetas det ständigt på den. Precis som med andra typer av attacker kommer de flesta sårbarheter från plugins. Så du måste lita på att utvecklingen av de tillägg du använder gör ett bra jobb.

Konkret innebär detta följande:

• Installera inte för många tilläggsprogram och installera endast de tilläggsprogram du verkligen behöver.
• Var försiktig med plug-ins som inte har uppdaterats på länge. Här kan det finnas dolda säkerhetsluckor som inte har åtgärdats.
• Ta reda på vad du ska göra med de insticksprogram som du installerar i förväg, till exempel om deras kompatibilitet med andra insticksprogram eller vilken WordPress-version du använder (så att insticksprogrammet också kan uppdateras).
• Uppdatera dina plugins och WordPress-kärnan regelbundet. Eftersom de kontinuerliga uppdateringarna är till för att täppa till sådana säkerhetsluckor.
• Var kritisk mot nätfiske.
• Om du är osäker kan du ta en närmare titt på insticksprogrammet i WP:s arkiv. Vilka är värderingarna, vilka var de största problemen tidigare och har insticksprogrammet eventuellt inte stängt ett framträdande säkerhetshål?

Slutsats: CSRF är gammal hatt

Cross site request forgery har funnits sedan början av den digitala tidsåldern. Dessutom är antalet fall extremt litet jämfört med brute force-attacker.

Detta bekräftas också av OWASP:s bedömning: Här antas attacken vara ganska utbredd, lätt att upptäcka och allvarlig endast i mycket specifika fall.

Ändå är det bra att veta hur attackerna fungerar. För ofta fungerar attackerna bara tack vare den mänskliga faktorn. Om och om igen öppnar användare e-postmeddelanden av nyfikenhet eller klickar på länkar som de inte skulle ha öppnat bättre.

Det bästa sättet att skydda sig mot cross-site request forgery är att göra efterforskningar och använda lite sunt förnuft.