CsrF-attacker (Cross-Site Request Forgery) på WordPress är bland de äldsta attackerna någonsin.

Cookies som en fara: Förfalskning av begäran över hela webbplatsen

CSRF, denna förkortning visas om och om igen i säkerhets- och underhållsuppdateringarna för WordPress-kärnan. Metoden bakom det är nu gammal hatt och utnyttjar de rikliga kakorna hos en Internetanvändare. Lyckligtvis kan du skydda dig mot förfalskning av begäran över hela webbplatsen ganska enkelt. Allt du behöver är lite tid och uppmärksamhet.

Du använder verkligen också en hel rad tjänster där det finns ett alternativ 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, men kommer att loggas in direkt. För användaren är detta naturligtvis bra, eftersom det sparar - precis som en lösenordshantering eller en så kallad enkel inloggning - irriterande formulärfyllning.

Följande fungerar i bakgrunden: När du loggar in på webbplatsen för första gången lagrar webbplatsen en cookie i din webbläsare. Det är en liten textfil där viss information kan lagras. Om du förblir inloggad ä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 automatiskt in dig automatiskt om den kan hitta motsvarande motsvarighet. Förresten är detta också anledningen till att du blir utloggad överallt när du tömmer din webbläsarcache . För under denna process raderas också alla cookies.

En CSRF-attack är i huvudsak ett missbruk av förtroende

Du märker redan: I en motsvarande attack lurar angriparen tjänsten som läser cookies. Hur exakt detta händer förklarar jag nedan med två exempel.

Risken för denna manipulation ligger i det faktum att en tredje part, det vill säga angriparen, till exempel gör ändringar i din Facebook-profil för din räkning. Förfalskning av begäran över flera webbplatser är dock ofta också beroende av nätfiske. Även här blir förtroende relevant – nämligen ditt förtroende för till exempel e-postavsändare.

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

Hur utsatt är WordPress?

Du har förmodligen inte hört termen förfalskning av begäranden över flera webbplatser så ofta som brute force-attacker eller skript på 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å den preliminära listan för 2017 upptar CSRF 8: e plats av 10. Under 2007 och 2010 landade attacken på 5: e plats, 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 skickliga på att säkra sin kod mot den. Säkerhetsrisker löses därför ganska enkelt och snabbt.

WordPress är också på din vakt. Till exempel släpptes säkerhetsuppdateringen 4.7.5 i maj, som åtgärdade sex sårbarheter som hackare kunde ha använt för att attackera via skript på flera webbplatser eller förfalskning av begäran över flera webbplatser. Skript över flera webbplatser anses dock ofta vara mycket farligare.

Dessutom tenderar frågan om förfalskning av begäran över flera webbplatser att vara mer relevant för plugin- och applikationsutvecklare än för webbdesigners, byråer och små och medelstora företag. Eftersom skydd mot CSRF också är en fråga om programmering. CSRF kan bli relevant, till exempel för köp i plugin.

Men hur fungerar allt?

Anatomin av cross-site förfrågan förfalskning

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

  1. Hackaren lurar offret att ladda en manipulerad sida eller klicka på en länk, till exempel genom att posera som en betrodd person eller utnyttja mänsklig nyfikenhet. Med andra ord spelar phishing en viktig roll i denna typ av attack.
  2. När du laddar eller klickar på de manipulerade länkarna eller sidorna kör offrets webbläsare en HTTP-begäran utan att offret lägger till det.

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

Låt oss anta att Justus vill överföra Bob www.bank.de 100 € via webbplatsen, och Skinny sitter och väntar på att utföra en CSRF-attack. Skinny kan nu använda t.ex. Använd METODERNA GET eller POST.

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

Förfalskning av begäran över flera webbplatser på 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 anger alla nödvändiga data. Följande (helt fiktiva) indata skulle överföras till servern:

HÄMTA HTTP://BANK.DE/TRANSFER.DO?ACCT=BOB&BETRAG=100 HTTP/1.1

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

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

Naturligtvis måste Justus också utföra handlingen som döljs bakom den falska länken. Det är därför Skinny skickar Justus ett e-postmeddelande med en falsk länk. Till exempel.B kan HTML-koden 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 som innehåller en "osynlig" (eftersom 0 x 0 pixlar) bild. När du försöker ladda bilden kommer webbläsaren åt WEBBADRESSEN utan att Justus ens inser:

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

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

Naturligtvis måste Justus klicka på länken när du är inloggad. Men om det tyvärr finns en inloggningscookie från hans bank i hans webbläsare kommer attacken att fungera även om han inte bara har öppnat sidan.

Det är just det som gör förfalskning av begäran över flera webbplatser så bedrägligt: Den skadelidande kanske inte ens är medveten om att cookien finns.

Förfalskning av begäran över flera webbplatser i POST-metoden

GET-metoden kan användas i länkar och är därför särskilt enkel att distribuera. Naturligtvis spelar detta i händerna på angriparen 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 som återstår är POST-metoden: Data överförs till en server så att den kan bearbeta den ytterligare. Data ingår dock inte i URL:en, utan läggs till i huvudet.

Det kan låta lite skrymmande, men du känner verkligen till användningsfallet. För att formulär fungerar på det här 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 w ww.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 först cookien för att kontrollera om Justus är inloggad. Endast om så är fallet kommer överföringen att utföras.

Skinny lagrar nu en osynlig form på en manipulerad webbplats, e.B.

<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 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 hans 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 attackera sidan A sätter han in skadlig kod på sidan B. 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) på WordPress?

Hur du skyddar dig mot 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 eliminera den.

De dåliga nyheterna: Du kan inte riktigt skydda dig mot det på den tekniska sidan. WordPress-kärnan är nu relativt väl skyddad, och som du kan se från de pågående uppdateringarna bearbetas den ständigt. Som med andra typer av attacker kommer de flesta sårbarheter med plugins. Så du måste lita på att utvecklarna av de tillägg du använder gör ett bra jobb.

Konkret innebär detta följande:

  • Installera inte för många plugins och bara de plugins du verkligen behöver
  • Se upp för plugins som inte har uppdaterats av utvecklarna på ganska länge. Detta kan dölja oförfixade säkerhetsluckor.
  • Informera dig själv i förväg om de plugins du installerar, e.B. om deras kompatibilitet med andra plugins eller WordPress-versionen du använder (så att plugin också kan uppdateras).
  • Uppdatera dina plugins och WP-kärnan regelbundet. Eftersom de kontinuerliga uppdateringarna finns exakt där för att öingvã¶nder sådana säkertluckor.
  • Du är kritisk till nätfiske
  • Om du är osäker: Ta en närmare titt på plugin i WP-lagringsplatsen. Vilka är betygen, vilka har varit de största problemen tidigare och har plugin-programmet eventuellt inte stängt en framträdande säkerhetsrisk?

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 till exempel brute force-attacker .

Detta bekräftas också av bedömningen av OWASP: Här antas det 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 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.

Oavsett om det är som användare eller användare: Det bästa sättet att skydda dig mot förfalskning av förfrågningar över flera webbplatser är med forskning och lite sunt förnuft.

Tyckte du om artikeln?

Med din recension hjälper du oss att förbättra vårt innehåll ytterligare.

Skriva en kommentar

Din e-postadress kommer inte att publiceras.