Cookies som en fara: Förfalskning över flera webbplatser

Tobias Schüring Senast uppdaterad den 21 januari 2020
7 Min.
CSRF-attacker (Cross-Site Request Forgery) i WordPress är bland de äldsta attackerna någonsin.

CSRF visas denna förkortning om och om igen i säkerhets- och underhållsuppdateringarna för WordPress -Kärnan. Metoden bakom det är nu en gammal hatt och utnyttjar en internetanvändares rikliga cookies. Lyckligtvis är det dock ganska enkelt att skydda dig mot förfalskningen av begäran på flera sajter. Allt du behöver är lite tid och uppmärksamhet.

Du kommer säkert att använda en hel rad tjänster där det finns möjlighet att vara inloggad även efter att du har lämnat webbplatsen. Om du sedan besöker webbplatsen igen behöver du inte ange dina inloggningsuppgifter igen, utan kommer att vara inloggad direkt. Detta är naturligtvis bra för användaren, eftersom det sparar irriterande formulärfyllning, precis som en lösenordshantering eller en så kallad enkel inloggning.

I bakgrunden händer följande: När du loggar in på sidan för första gången lagrar webbplatsen en cookie i din webbläsare. Det är en liten textfil som kan lagra specifik information. När det gäller inloggning är detta en slumpmässigt genererad teckensträng.

Vid ditt nästa besök på webbplatsen kontrollerar servern den här teckensträngen och loggar in automatiskt om den kan hitta rätt motsvarighet. Förresten är detta också anledningen till att du kommer att loggas ut överallt när du tömmer din webbläsarcachen. Denna process raderar också alla cookies.

En CSRF-attack är dess största misstro

Du märker redan: I en motsvarande attack lurar angriparen tjänsten, som läser kakorna något. Jag kommer att förklara exakt hur detta sker i två exempel nedan.

Risken med denna manipulation är att en tredje part, det vill säga angriparen, gör ändringar i din Facebook-profil, till exempel för din räkning. Förfalskning av begäran på flera webbplatser är också ofta beroende av nätfiske. Även här blir förtroende relevant – och det är ditt förtroende för t.ex. avsändare av e-post.

CSRF-attacker (Cross Site Request Forgery) på WordPress kan förhindras av sunt förnuft.

Hur sårbart är WordPress ?

Du har förmodligen inte hört termen förfalskning över flera webbplatser så ofta som du Brute Force Attacker eller skript på flera siter. 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 webbprogram. På den preliminära listan för 2017 ligger CSRF på åttonde plats av 10: e plats 2007 och 2010, attacken fortfarande rankad 5: e, 2013 sjönk den till 8: e plats.

Detta beror förmodligen delvis på att CSRF-attacker är nästan lika gamla som Internet självt. Professionella utvecklare är nu utbildade i att säkra sin kod mot den. Säkerhetsrisker hanteras därför enkelt och snabbt.

På WordPress du är också på sin vakt. Till exempel släpptes säkerhetsuppdatering 4.7.5 i maj, vilket rensade upp sex sårbarheter som kunde ha orsakat hackare att attackera via skript på flera platser eller begäran om förfalskning över flera platser. Skript över flera sajter anses dock ofta vara mycket farligare.

Dessutom tenderar frågan om förfalskning av begäran på flera sajter att vara mer Plugin - och applikationsutvecklare som är mer relevanta än för webbdesigners, byråer och små och medelstora företag. Eftersom skydd mot GSRF också är en fråga om programmering. relevant kan GSRF till exempel Plugin Inköp.

Men hur fungerar allt nu?

Anatomin för förfalskning av begäran på flera webbplatser

Grundidén bakom en CSRF-attack är relativt enkel och händer vanligtvis i två steg:

  1. Hackaren får offret att ladda en komprometterad sida eller klicka på en länk, till exempel genom att låtsas vara en förvaltare eller utnyttja mänsklig nyfikenhet. Med andra ord spelar phishing en viktig roll i denna typ av attack.
  2. När du läser in eller klickar på de manipulerade länkarna eller sidorna kör offrets webbläsare en HTTP-begäran utan att offret märker det.

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

Låt oss anta att Justus vill överföra Bob över sidan www.bank.de 100 €, och Skinny är på väg att utföra en CSRF-attack. Skinny kan nu till exempel vara ansvarig för sin attack. Använd GET- eller POST-metoden.

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

Förfalskning av begäran mellan webbplatser med GET-metoden

GET-metoden begär en resurs från en server, till exempel en HTML-fil. De parametrar som krävs för samtalet läggs helt enkelt till i URL:en. Och som vi redan vet från SQL-injektioner är en URL relativt lätt att manipulera.

Justus loggar in för www.bank.de och anger alla nödvändiga data. Följande (helt fiktiva) indata skulle överföras till servern:

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

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

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

Naturligtvis måste Justus också utföra handlingen som är dold bakom den falska länken. Det är därför Skinny Justus skickar ett e-postmeddelande med en falsk länk. Html.B kan till exempel se ut så här:

">Som inte kan lösa det här pusslet är inte en riktig detektiv!

Eller så skickar han honom ett e-postmeddelande som innehåller en "osynlig" (eftersom 0 av 0 pixlar) bild. När du försöker ladda bilden kommer webbläsaren åt WEBBADRESSen utan att Justus ens märker det:

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

Naturligtvis måste Justus klicka på länken medan den ä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 öppnat sidan.

Detta är exakt vad Cross-Site Request Forgery gör så lömskt: offret kanske inte ens är medveten om att cookien finns.

Förfalskning av begäran på flera siter med POST-metoden

GET-metoden kan användas i länkar och är därför särskilt lätt att sprida. Detta spelar naturligtvis angriparen i händerna när det gäller distribution. Nu kan dock leverantörer se till att GET-begäranden inte får skrivbehörighet i princip.

Det finns fortfarande POST-metoden: Data skickas till en server så att den kan bearbeta den vidare. Data ingår dock inte i URL:en, utan läggs till i huvudet.

Låter lite skrymmande, men du vet verkligen användningsfallet. För att formulär fungerar på det sättet.

För vår angripare, Skinny, betyder det att han måste anstränga sig mer, men kan fortfarande komma dit.

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

<formulärmetod ="POST"-åtgärd ="geld_ueberweisen.php">inmatningstyp      <  ="textnamn" ="från"> inmatningstyp      <  ="text" namn ="en">inmatningstyp      <  ="text" namn="betrag_in_euro">inmatningstyp      <  ="skicka">  formulär>

Detta skickar kommandot geld_ueberweisen.php 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 kontrollerar koden cookien för att se om Justus är inloggad. Endast om det är det kommer överföringen att utföras.

Skinny sätter nu in en osynlig form på en manipulerad webbplats, e.B.

<formulärmetod ="POST"-åtgärd ="http://www.bank.de/geld_ueberweisen.php">inmatningstyp      <  ="text" namn="från"-värde ="Justus"-format ="display: dold">      < inmatningstyp ="text" namn="an" värde="Mager" stil="display: dold">      < inmatningstyp ="text" namn="betrag_in_euro" värde="100000" stil="display: hidden        <      >"    är inte en riktigdetektiv!" > formulär>

Han skickar länken till denna manipulerade webbplats till Justus. Han känner sig utmanad, klickar på knappen för att se pusslet; och redan utför han omedvetet funktionen geld_ueberweisen.php. Eftersom detta hittar en motsvarande cookie i sin webbläsare kommer 100 000 € att överföras till Skinny igen.

Attack via omvägar

Det är därför namnet Cross-SiteRequestForgery: Hackaren skickar vanligtvis kommandot från en annan sida. För att attackera sidan A lägger den därmed in på sidan B skadlig kod. Sedan lockar han den intet ont anande användaren här, så att hans webbläsare kör koden.

Hur farliga är CSRF-attacker (Cross Site Request Forgery) i WordPress ?

Hur man bekämpar CSRF-attacker

Den goda nyheten: Cross-Site Request Forgery har varit känd i evigheter. Utvecklare känner till risken och arbetar specifikt för att bli av med den.

De dåliga nyheterna: Du kan inte riktigt skydda dig mot det på den tekniska sidan. Den WordPress - Core är nu relativt väl skyddat, och som ni kan se av de pågående uppdateringarna arbetar vi ständigt med det. Som med andra typer av attacker kommer de flesta sårbarheter med Plugins Därför. Så du måste lita på att utvecklarna av de tillägg du använder gör ett bra jobb.

Konkret innebär detta:

  • Installatören inte för många Plugins och endast Plugins , som du verkligen behöver
  • Se upp Plugins , som inte har uppdaterats av utvecklarna på ett tag. Detta kan dölja olösta säkerhetsproblem.
  • Informera dig själv i förväg om Plugins , som du installerar, e.B. om deras kompatibilitet med andra Plugins eller WordPress version som du använder (så att Plugin uppdateras också).
  • Uppdatera din Plugins och WP-Core regelbundet. Eftersom de kontinuerliga uppdateringarna finns där för att stänga sådana säkerhetsproblem.
  • du är kritisk mot nätfiske
  • Om du är osäker: Titta på det Plugin i WP-databasen. Hur misslyckas recensionerna, vilka var de största problemen tidigare och har Plugin ett framträdande säkerhetsproblem kanske inte stängs?

Dom: CSRF är en gammal hatt

Förfalskning av begäran på flera sajter har funnits sedan början av den digitala tidsåldern. Dessutom jämförs ärendenumren med t.ex. Brute Force Attacker extremt små.

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

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

Oavsett om det är som användare eller användare är det bästa sättet att skydda dig mot begäran förfalskning på flera sajter att göra det med forskning och lite sunt förnuft.

Som systemadministratör övervakar Tobias vår infrastruktur och hittar varje justeringsskruv för att optimera prestandan hos våra servrar. På grund av sina outtröttliga ansträngningar är han ofta också Slack som ska hittas.

Liknande artiklar

Kommentarer om den här artikeln

Skriva en kommentar

Din e-postadress kommer inte att publiceras. Obligatoriska fält är markerade med *.