Cookies som en fara: Förfalskning av begäran på flera webbplatser

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

csrf visas den här förkortningen om och om igen i säkerhets- och underhållsuppdateringarna av WordPress -Kärna. Metoden bakom det är nu en gammal hatt och utnyttjar rikliga cookies av en Internet-användare. Lyckligtvis är det dock ganska lätt att skydda dig från cross-site Request Forgery. 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 lämnar webbplatsen. Om du sedan besöker webbplatsen igen behöver du inte ange dina inloggningsuppgifter igen, men kommer att loggas in direkt. För användaren, naturligtvis, detta är bra, eftersom det - precis som ett lösenord förvaltning eller en så kallad. Enkel inloggning - sparar irriterande form fyllning.

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 nästa besök på webbplatsen kontrollerar servern den här teckensträngen och, om den kan hitta rätt motsvarighet, loggar in automatiskt. Förresten, detta är också anledningen till att du är utloggad överallt när du Webbläsarens cacheminne leerst. Denna process tar också bort alla cookies.

En CSRF-attack är i sin kärna misstro

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

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

Csrf-attacker (Cross Site Request Forgery) attacker på WordPress kan förebyggas genom sunt förnuft.

Hur sårbar är WordPress ?

Du har förmodligen inte hört termen Cross-Site Request Forgery så ofta som du Brute Force Attacker Eller Skript över flera webbplatser. 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å preliminär lista för 2017 csRF på plats 8 av tionde 2007 och 2010 landade attacken fortfarande på 5:e plats. År 2013 steg den till 8:e plats Av.

Detta beror förmodligen delvis på det faktum att CSRF-attacker är nästan lika gamla som Själva Internet. Professionella utvecklare är nu utbildade i att säkra sin kod mot den. Säkerhetsriskerna 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, som rensade upp sex sårbarheter som kan ha orsakat hackare att attackera via cross-site scripting eller cross-site Request Forgery. Ofta men vid den tidpunkten Skript över flera webbplatser anses vara mycket farligare.

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

Men hur fungerar allt nu?

Anatomin av Cross-Site Request Förfalskning

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

  1. Hackaren får offret att ladda en komprometterade 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 nätfiske en viktig roll i den här typen av angrepp.
  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 Bob att korsa sidan www.bank.de € 100, och Skinny sitter på lockelsen att utföra en CSRF attack. Skinny kan nu, till exempel, vara ansvarig för hans attack. Använd metoden GET eller POST.

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

Förfalskning över flera webbplatser på GET-metoden

GET-metoden begär en resurs från en server, till exempel en HTML-fil. De parametrar som krävs för anropet läggs helt enkelt till webbadressen. Och som vi redan har sett från SQL-injektioner Vet: En webbadress är relativt lätt att manipulera.

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

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

Skinny konstruerar nu en webbadress som överför € 100.000 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 åtgärden gömd bakom den falska länken. Det är därför Skinny Justus skickar ett mail med en falsk länk. HTML-koden kan till exempel se ut så här:

">Om du inte kan lösa detta pussel, du är inte en riktig detektiv!

Eller han skickar honom ett mail som innehåller en "osynlig" (eftersom 0 x 0 pixlar) bild. När du försöker ladda bilden, webbläsaren kommer åt webbadressen utan 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 sin webbläsare attacken fungerar även om den inte har öppnat sidan.

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

Förfalskning över flera webbplatser på POST-metoden

GET-metoden kan användas i länkar och är därför särskilt lätt att sprida. Detta, naturligtvis, spelar i händerna på angriparen när det gäller distribution. Nu kan dock leverantörerna 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 ytterligare. Data är dock inte en del av URL:en, utan läggs till i sidhuvudet.

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

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

Samma scenario: Justus vill överföra pengar till Bob. Så det fylls upp Www.bank.de Följande formulär:

<Formuläret Metod="POST" Åtgärder="geld_ueberweisen.php">

    <Input Typ="text" Namn="från">

    <Input Typ="text" Namn="på">

    <Input Typ="text" Namn="betrag_in_euro">

    <Input Typ="skicka">

Formuläret>

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

Om(Isset("_FORM["från"]) && Isset("_FORM["på"]) &&Isset("_FORM["menge_in_euro"]) && Isset("_CMOKIE["user_eingeloggt"]))

{

    transMoney (transMoney)("från", "på", "belopp");

    Echo "Överföring framgångsrik!";

}

Som du kan se kontrollerar koden cookien för att se om Justus är inloggad. Endast om så är fallet kommer överföringen att utföras.

Skinny lagrar nu en osynlig form på en komprometterade webbsida, t.ex.

<Formuläret Metod="POST" Åtgärder="http://www.bank.de/geld_ueberweisen.php">

    <Input Typ="text" Namn="från" Värde="Justus" Stil="display: dold">

    <Input Typ="text" Namn="på" Värde="Mycket bra" Stil="display: dold">

    <Input Typ="text" Namn="betrag_in_euro" Värde="100000" Stil="display: dold">

    <Input Typ="skicka" Värde="Om du inte kan lösa detta pussel, du är inte en riktig detektiv!">

Formuläret>

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 han omedvetet utför 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-Site Request Forgery: Hackaren skickar vanligtvis kommandot från en annan sida. För att anfalla sidan A, insättningar det thus på skadlig kod för sida B. Sedan lockar han intet ont anande användare här, så att hans webbläsare kör koden.

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

Hur man bekämpar CSRF-attacker

Den goda nyheten: Cross-Site Request Forgery har varit känd i evigheter. Utvecklare vet 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. Det är WordPress - Core är nu relativt väl skyddad, och som ni kan se av de pågående uppdateringarna arbetar vi ständigt med det. Precis 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.

Rent konkret innebär detta:

  • Installatören inte alltför många Plugins och endast Plugins , som du verkligen behöver
  • Se upp Plugins , som inte har uppdaterats av utvecklarna under en tid. Detta kan dölja olösta säkerhetsproblem.
  • Informera dig själv i förväg om Plugins som du installerar, t.ex. Plugins eller WordPress version som du använder (så att Plugin också uppdateringar).
  • Uppdatera din Plugins och WP-Core regelbundet. Eftersom de kontinuerliga uppdateringarna finns där för att stänga sådana sårbarheter.
  • du är kritisk till nätfiske
  • Om du är osäker: Titta på det Plugin i WP-arkivet. Hur misslyckas recensionerna, vilka var de största problemen i det förflutna och har Plugin en framträdande säkerhetsrisk kanske inte stängs?

Dom: CSRF är en gammal hatt

Cross-Site Request Forgery har funnits sedan början av den digitala tidsåldern. Dessutom jämförs antalet fall med t.ex. Brute Force Attacker extremt liten.

Detta bekräftar också OWASP:s bedömning: Det antas att attacken är ganska låg spridning, lätt att upptäcka och endast allvarliga i mycket specifika fall Är.

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

Oavsett om det är som användare eller användare är det bästa sättet att skydda dig mot begäransförfalskning på flera webbplatser 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

Skriv en kommentar

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