Cookies als gevaar: Cross-Site Request Vervalsing

Tobias Schüring Laatst bijgewerkt op 21.01.2020
7 Min.
Cross-Site Request Forgery (CSRF)-aanvallen op WordPress  behoren tot de oudste aanvallen van allemaal.

CSRF, deze afkorting duikt steeds weer op in de beveiligings- en onderhoudsupdates van de WordPress core. De methode erachter is inmiddels achterhaald en maakt gebruik van de overvloedige cookies van een internetgebruiker. Maar gelukkig kun je je vrij eenvoudig beschermen tegen cross-site request forgery. Alles wat je nodig hebt is een beetje tijd en aandacht.

U gebruikt waarschijnlijk ook een aantal diensten die de mogelijkheid bieden om ingelogd te blijven, zelfs nadat u de site hebt verlaten. Als u vervolgens de pagina opnieuw bezoekt, hoeft u uw inloggegevens niet opnieuw in te voeren, maar bent u direct ingelogd. Voor de gebruiker is dit natuurlijk geweldig, want het bespaart - net als een wachtwoordbeheer of een zogenaamde Single Sign On - het vervelende invullen van formulieren.

Op de achtergrond gebeurt het volgende: wanneer u voor de eerste keer inlogt op de site, slaat de website een cookie op in uw browser. Dit is een klein tekstbestand waarin bepaalde informatie kan worden opgeslagen. In het geval van ingelogd blijven, is dit een willekeurig gegenereerde tekenreeks.

De volgende keer dat u de website bezoekt, controleert de server deze tekenreeks en, als hij de overeenkomstige tegenhanger kan vinden, logt hij u automatisch in. Dit is ook de reden waarom u overal wordt uitgelogd wanneer u uw browser cache leegmaakt. Omdat tijdens dit proces ook alle cookies worden gewist.

Een CSRF-aanval is in de kern een misbruik van vertrouwen.

Zoals u kunt zien, bij een overeenkomstige aanval misleidt de aanvaller de dienst die de cookies leest door iets te geloven. Hoe dat precies in zijn werk gaat, leg ik hieronder uit met twee voorbeelden.

Het gevaar van deze manipulatie schuilt in het feit dat een derde partij, d.w.z. de aanvaller, in uw naam bijvoorbeeld wijzigingen aanbrengt in uw Facebook-profiel. Cross-site request forgery is echter vaak ook afhankelijk van phishing. Ook hier wordt vertrouwen relevant - namelijk uw vertrouwen in, bijvoorbeeld, de afzenders van e-mails.

Cross Site Request Forgery (CSRF) Aanvallen op WordPress  kunnen met gezond verstand worden voorkomen.

Hoe kwetsbaar is WordPress ?

Je hebt de term Cross-Site Request Forgery waarschijnlijk niet zo vaak gehoord als Brute Force aanvallen of cross-site scripting. Daar is een reden voor: de non-profitorganisatie OWASP (Open Web Application Security Project) publiceert regelmatig een lijst met de tien meest kritieke kwetsbaarheden in webapplicaties. Op de voorlopige lijst voor 2017 CSRF staat op de 8e plaats van de 10. In 2007 en 2010 belandde de aanval nog op de 5e plaats, In 2013, zakte het naar nummer acht afstammen.

Dit is waarschijnlijk deels te wijten aan het feit dat CSRF-aanvallen bijna zo oud zijn als het internet zelf. Professionele ontwikkelaars zijn nu goed geoefend in het beveiligen van hun code hiertegen. Veiligheidsrisico's zijn dus vrij gemakkelijk en snel op te lossen.

WordPress staat ook op de uitkijk. Zo werd in mei beveiligingsupdate 4.7.5 uitgebracht, die zes kwetsbaarheden verhelpt die hackers hadden kunnen gebruiken om een aanval via cross-site scripting of cross-site request forgery uit te voeren. Vaak wordt cross-site scripting vaak als veel gevaarlijker beschouwd.

Bovendien is het probleem van cross-site request forgery vaak relevanter voor Plugin- en applicatieontwikkelaars dan voor webontwerpers, agentschappen en het MKB. Dit komt omdat bescherming tegen CSRF ook een kwestie van programmeren is. CSRF zou bijvoorbeeld relevant kunnen worden in het geval van aankopen opPlugin.

Maar hoe werkt het nu allemaal?

De Anatomie van Cross-Site Request Vervalsing

Het basisidee achter een CSRF-aanval is relatief eenvoudig en gebeurt meestal in twee stappen:

  1. De hacker verleidt het slachtoffer om een gemanipuleerde pagina te laden of op een link te klikken, bijvoorbeeld door zich voor te doen als een vertrouwd persoon of door misbruik te maken van de menselijke nieuwsgierigheid. Met andere woorden, phishing speelt een belangrijke rol bij dit soort aanvallen.
  2. Wanneer de gemanipuleerde links of pagina's worden geladen of erop wordt geklikt, voert de browser van het slachtoffer een HTTP-verzoek uit zonder dat het slachtoffer het merkt.

Twee betrekkelijk eenvoudige voorbeelden illustreren hoe zo'n aanval werkt.

Laten we aannemen dat Justus Bob een bericht wil sturen via de pagina www.bank.de 100€, en Skinny zit te wachten om een CSRF aanval uit te voeren. Skinny kan nu, bijvoorbeeld, de GET of POST methode gebruiken voor zijn aanval.

Tussen haakjes, de volgende voorbeelden komen uit de volgende bronnen:

Cross-Site Request Vervalsing met de GET Methode

De GET-methode wordt gebruikt om een bron van een server op te vragen, bijvoorbeeld een HTML-bestand. De vereiste parameters voor de oproep worden gewoon toegevoegd aan de URL. En zoals we al weten van SQL injecties: Een URL is relatief eenvoudig te manipuleren.

Dus Justus logt in bij www.bank.de en voert alle nodige gegevens in. De volgende (volledig fictieve) invoer zou naar de server worden verzonden:

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

Skinny construeert nu een URL die in plaats daarvan €100.000 naar zijn eigen rekening overmaakt. Het ziet er zo uit:

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

Natuurlijk moet Justus de actie uitvoeren die achter de valse link schuilgaat. Daarom stuurt Skinny Justus een mail met een valse link. De HTML-code kan er bijvoorbeeld als volgt uitzien:

">Wie dit mysterie niet kan oplossen is geen echte detective!

Of hij stuurt hem een e-mail die een "onzichtbare" (want 0 bij 0 pixels) afbeelding bevat. Als hij de afbeelding probeert te laden, opent de browser de URL zonder dat Justus het merkt:

Wanneer Justus de link oproept - bewust of onbewust - worden de parameters doorgegeven aan de server, de overschrijving wordt in gang gezet en 100.000€ verdwijnt van zijn rekening.

Natuurlijk, Justus moet op de link klikken terwijl hij ingelogd is. Maar als, helaas, zijn browser een login cookie van zijn bank bevat de aanval werkt zelfs als hij de pagina niet heeft geopend.

Dit is precies wat cross-site request forgery zo verraderlijk maakt: het slachtoffer is zich er misschien niet eens van bewust dat het cookie bestaat.

Cross-Site Request Vervalsing met de POST Methode

De GET-methode kan in links worden gebruikt en is daarom bijzonder gemakkelijk te verspreiden. Dit speelt de aanvaller natuurlijk in de kaart wat de verdeling betreft. Nu kunnen aanbieders er echter voor zorgen dat GET-verzoeken in principe geen schrijfmachtiging krijgen.

De POST-methode blijft over: hierbij worden gegevens naar een server gestuurd, zodat deze ze verder kan verwerken. De gegevens maken geen deel uit van de URL, maar worden aan de header toegevoegd.

Klinkt misschien een beetje lomp, maar je kent het gebruik. Omdat formulieren op deze manier werken.

Voor onze aanvaller, Skinny, betekent dit dat hij meer moeite moet doen, maar hij kan nog steeds komen waar hij wil.

Zelfde scenario: Justus wil geld overmaken naar Bob. Dus hij vult www.bank.de en vult het volgende formulier in:

<formulier methode="POST" actie="money_transfer.php">

    <input type="tekst" naam="van">

    <input type="tekst" naam="an">

    <input type="tekst" naam="bedrag_in_euro">

    <input type="submit">

formulier>

Dit stuurt het commando money_transfer.php, dat er zo uitziet:

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

{

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

    echo "Überweisung erfolgreich!";

}

Zoals je kunt zien, controleert de code eerst of Justus is ingelogd met behulp van de cookie. Alleen als hij dat is, zal de overdracht worden uitgevoerd.

Skinny zet nu een onzichtbaar formulier op een gemanipuleerde webpagina, bijv.

<formulier methode="POST" actie="http://www.bank.de/geld_ueberweisen.php">

    <input type="tekst" naam="van" waarde="Justus" stijl="display: verborgen">

    <input type="tekst" naam="an" waarde="mager" stijl="display: verborgen">

    <input type="tekst" naam="bedrag_in_euro" waarde="100000" stijl="display: verborgen">

    <input type="submit" waarde="Iedereen die dit mysterie niet kan oplossen is geen echte detective!">

formulier>

Hij stuurt de link naar deze gemanipuleerde website naar Justus. Hij voelt zich uitgedaagd, klikt op de knop om de puzzel te zien, en voert zonder het te weten de functie geld_ueberweisen.php uit. Aangezien deze een overeenkomstige cookie in zijn browser vindt, wordt er weer 100.000€ naar Skinny overgemaakt.

Aanval via omwegen

Dat is waarom de naam CrossSite Request Forgery: De hacker stuurt het commando meestal vanaf een andere site. Om pagina A aan te vallen, plaatst hij kwaadaardige code op pagina B. Dan lokt hij de nietsvermoedende gebruiker hierheen, zodat zijn browser de code uitvoert.

Hoe gevaarlijk zijn Cross Site Request Forgery (CSRF)-aanvallen op WordPress ?

Hoe kunt u zich beveiligen tegen CSRF-aanvallen

Het goede nieuws is dat cross-site request forgery al eeuwen bestaat. De ontwikkelaars kennen het risico en doen er alles aan om het te elimineren.

Het slechte nieuws is dat je je er technisch gezien niet tegen kunt beschermen. De kern WordPress is nu relatief goed beschermd, en zoals u kunt zien aan de voortdurende updates, wordt er voortdurend aan gewerkt. Net als bij andere soorten aanvallen zijn de meeste kwetsbaarheden te vinden op Plugins . U moet er dus op vertrouwen dat de ontwikkelaars van de extensies die u gebruikt, goed werk leveren.

Dat betekent specifiek:

  • Installeer niet te veel Plugins en alleen de Plugins die je echt nodig hebt.
  • Wees voorzichtig met Plugins, dat al een tijdje niet meer is bijgewerkt door de ontwikkelaars. Onopgeloste veiligheidslekken kunnen hier verborgen zijn.
  • Controleer de compatibiliteit van de Plugins die u installeert met andere Plugins of de WordPress versie die u gebruikt (zodat de Plugin kan worden bijgewerkt).
  • Update uw Plugins en WP core regelmatig. Omdat de voortdurende updates er juist zijn om zulke veiligheidsgaten te dichten.
  • Je kritisch in termen van phishing
  • Als je niet zeker bent, kijk dan eens goed naar Plugin in de WP repository. Wat zijn de beoordelingen, wat waren in het verleden de grootste problemen en heeft de Plugin misschien een prominent veiligheidsgat niet gedicht?

Conclusie: CSRF is oude koek

Cross-site request forgery bestaat al sinds het begin van het digitale tijdperk. Bovendien is het aantal gevallen uiterst gering in vergelijking met bv. Brute Force aanvallen.

Dit wordt ook bevestigd door de beoordeling van OWASP dat de aanval vrij onopvallend is, gemakkelijk op te sporen en alleen in bepaalde specifieke gevallen ernstig is. gevallen.

Toch is het goed te weten hoe de aanvallen werken. Omdat de aanvallen vaak alleen werken dankzij menselijke fouten. Keer op keer openen gebruikers e-mails uit nieuwsgierigheid of klikken ze op links die ze beter niet hadden kunnen openen.

Dus, of u nu een gebruiker of eindgebruiker bent, de beste manier om uzelf te beschermen tegen cross-site request forgery is met onderzoek en een beetje gezond verstand.

Als systeembeheerder waakt Tobias over onze infrastructuur en vindt hij alle mogelijke manieren om de prestaties van onze servers te optimaliseren. Door zijn onvermoeibare inzet is hij vaak 's nachts bij Slack te vinden.

Verwante artikelen

Reacties op dit artikel

Laat een opmerking achter

Jouw e-mailadres zal niet worden gepubliceerd. Verplichte velden zijn met een * gemarkeerd.