Cross Site Request Forgery

Cross Site Request Forgery: cookies als gevaar

CSRF, deze afkorting duikt steeds weer op in de update notes van de WordPress Core. De methode erachter is inmiddels oude koek en maakt misbruik van de meestal overvloedige cookies van een browser. Maar gelukkig kun je jezelf vrij eenvoudig beschermen tegen Cross Site Request Forgery. Alles wat je nodig hebt is een beetje tijd en aandacht.

Je gebruikt zeker een aantal diensten die de mogelijkheid bieden om ingelogd te blijven, ook nadat je de website hebt verlaten. Als je dan de website opnieuw bezoekt, hoef je niet opnieuw je inloggegevens in te voeren, maar ben je direct ingelogd. Dat is natuurlijk geweldig, want het bespaart je – net als wachtwoordbeheer of een zogenaamde single sign-on – het invullen van formulieren.

Het volgende gebeurt op de achtergrond: wanneer je voor het eerst inlogt op de website, plaatst de website een cookie in je browser. Dit is een klein tekstbestand waarin bepaalde informatie kan worden opgeslagen. In het geval van ingelogd blijven is dit een willekeurig gegenereerde string.

De volgende keer dat je de website bezoekt, controleert de server deze string en, als hij de overeenkomstige tegenhanger kan vinden, logt hij je automatisch in. Dit is ook de reden waarom je overal wordt uitgelogd als je de cache van je browser leegt. Want tijdens dit proces worden ook alle cookies verwijderd.

CSRF-aanvallen zijn in de kern een vertrouwensmisbruik

Zoals je ziet wordt bij een dergelijke aanval de dienst die de cookies leest voor de gek gehouden. Ik zal hieronder aan de hand van twee voorbeelden uitleggen hoe dit precies gebeurt.

Het gevaar van deze manipulatie schuilt bijvoorbeeld in iemand die in jouw naam wijzigingen aanbrengt in je Facebook-profiel. Maar ook cross site request forgery is vaak afhankelijk van phishing. Ook hier wordt vertrouwen relevant – je vertrouwen in de afzenders van e-mails, bijvoorbeeld.

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-profit organisatie OWASP (Open Web Application Security Project) publiceert regelmatig een lijst van de tien meest kritieke kwetsbaarheden in webapplicaties. CSRF is in de loop der jaren als beveiligingsrisico steeds verder naar beneden gegleden en is nu uit de top 10 verdwenen.

Dit komt waarschijnlijk deels doordat CSRF-aanvallen bijna net zo oud zijn als het internet zelf. Professionele ontwikkelaars zijn nu geoefend in het beveiligen van hun code ertegen. Beveiligingsrisico's zijn dus vrij eenvoudig en snel te verhelpen.

Ook WordPress is op zijn hoede. Zo werd beveiligingsupdate 4.7.5 gepubliceerd, die zes kwetsbaarheden verhelpt die hackers hadden kunnen gebruiken om een aanval uit te voeren via cross-site scripting of cross-site request forgery. Cross-site scripting wordt echter vaak als veel gevaarlijker beschouwd.

Bovendien is de kwestie van Cross Site Request Forgery meestal relevanter voor plugins en apps dan voor webdesign, bureaus en het MKB. Dat komt omdat bescherming tegen CSRF ook een kwestie van programmeren is. CSRF kan bijvoorbeeld relevant worden bij in-plugin aankopen.

Maar hoe werkt het nu allemaal?

De anatomie van Cross Site Request Forgery

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

  • Het slachtoffer wordt misleid om een gemanipuleerde website te laden of op een link te klikken, bijvoorbeeld door het te laten lijken alsof het bericht van een vertrouwd persoon komt. Of er wordt misbruik gemaakt van de menselijke nieuwsgierigheid. Met andere woorden, phishing speelt een belangrijke rol bij dit soort aanvallen.
  • Bij het laden of aanklikken van de gemanipuleerde links of websites voert de browser van het slachtoffer een HTTP-verzoek uit zonder dat het slachtoffer iets merkt.

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

Laten we aannemen dat Joost €100 wil overmaken naar Bob via de website www.bank.nl en dat Skinny op de loer ligt om een CSRF-aanval uit te voeren. Skinny kan de GET of POST methode gebruiken voor zijn aanval.

De volgende voorbeelden komen overigens uit de volgende bronnen:

Cross Site Request Forgery met de GET-methode

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

Joost logt in op www.bank.nl en voert alle benodigde gegevens in. De volgende (geheel fictieve) invoer zou aan de server worden doorgegeven:

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

Skinny construeert nu een URL die €100.000 overmaakt naar zijn eigen rekening. Het ziet er als volgt uit:

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

Natuurlijk moet Joost de actie uitvoeren die achter de valse link verborgen zit. Daarom stuurt Skinny Joost een mail met een valse link. De HTML-code kan er bijvoorbeeld zo uitzien:

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

Of hij stuurt hem een e-mail met daarin een "onzichtbaar" (want 0 bij 0 pixels) plaatje. Als hij de afbeelding probeert te laden, opent de browser de URL zonder dat Joost het merkt:

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

Als Joost de link oproept – bewust of onbewust – worden de parameters doorgegeven aan de server, wordt de overschrijving in gang gezet en verdwijnt er €100.000 van zijn rekening.

Natuurlijk moet Joost op de link klikken terwijl hij is ingelogd. Maar als er helaas een login cookie van zijn bank in zijn browser staat, werkt de aanval ook als hij de website op dat moment niet open heeft staan.

Dit is precies wat Cross Site Request Forgery zo verraderlijk maakt: Joost is zich er waarschijnlijk niet eens van bewust dat de cookie bestaat.

Cross Site Request Forgery met de POST methode

De GET methode kan gebruikt worden in links en is dus bijzonder gemakkelijk te verspreiden. Aanbieders kunnen er nu echter voor zorgen dat GET verzoeken in principe geen schrijftoestemming krijgen.

De POST methode blijft: Hier worden gegevens overgebracht naar een server, zodat die ze verder kan verwerken. De gegevens maken geen deel uit van de URL, maar worden toegevoegd aan de header.

Het klinkt misschien wat omslachtig, maar je kent zeker de use case, want formulieren werken zo.

Voor onze aanvaller Skinny betekent dit dat hij zich meer moet inspannen, maar toch bij het doel kan komen.

Hetzelfde scenario: Joost wil geld overmaken naar Bob. Dus vult hij het volgende formulier in op www.bank.nl:

<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>

Dit stuurt het commando geld_overmaken.php, dat er als volgt 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 ziet gebruikt de code eerst de cookie om te controleren of Joost is ingelogd. Pas daarna wordt de overdracht uitgevoerd.

Skinny laat nu bijvoorbeeld een onzichtbaar formulier op een gemanipuleerde website achter:

<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>

Hij stuurt de link naar deze gemanipuleerde website naar Joost. Die voelt zich uitgedaagd, klikt op de knop om de puzzel te bekijken – en voert onbewust de functie geld_ueberweisen.php uit. Omdat deze een bijbehorende cookie in zijn browser vindt, wordt er weer €100.000 naar Skinny overgemaakt.

Aanval via omwegen

Daarom heet het cross site request forgery: het commando wordt meestal verstuurd vanaf een andere website. Om website A aan te vallen, zet hij kwaadaardige code neer op website B. Vervolgens lokt hij het slachtoffer hierheen zodat zijn browser de code uitvoert.

"*" geeft verplichte velden aan

Ik wil me abonneren op de nieuwsbrief om op de hoogte te blijven van nieuwe blogartikelen, ebooks, features en nieuws over WordPress. Ik kan mijn toestemming te allen tijde intrekken. Bekijk ons Privacybeleid.
Dit veld dient ter validatie en mag niet worden gewijzigd.

Hoe je jezelf kunt beschermen tegen CSRF-aanvallen

Het goede nieuws: Cross Site Request Forgery is al tijden bekend. Het risico is bekend en bij de ontwikkeling wordt er specifiek aan gewerkt om het te elimineren.

Het slechte nieuws is dat je je er technisch niet echt tegen kunt beschermen. De WordPress core is nu relatief goed beschermd, en zoals je kunt zien aan de voortdurende updates wordt er steeds aan gewerkt. Net als bij andere soorten aanvallen komen de meeste kwetsbaarheden van plugins. Je moet er dus op vertrouwen dat de ontwikkeling van de extensies die je gebruikt goed werk levert.

Dat betekent specifiek:

  • Installeer niet te veel plugins en installeer alleen de plugins die je echt nodig hebt.
  • Wees voorzichtig met plugins die lange tijd niet zijn bijgewerkt. Niet gerepareerde beveiligingslekken kunnen hier verborgen zijn.
  • Zoek van tevoren informatie over de plugins die je installeert, bijvoorbeeld over hun compatibiliteit met andere plugins of de WordPress versie die je gebruikt (zodat de plugin ook bijgewerkt kan worden).
  • Werk je plugins en de WordPress core regelmatig bij. Want de continue updates zijn er juist om zulke beveiligingsgaten te dichten.
  • Wees kritisch op phishing.
  • Als je twijfelt, bekijk de plugin in de WP repository dan goed. Wat zijn de beoordelingen, wat waren de grootste problemen in het verleden en heeft de plugin mogelijk een prominent beveiligingslek 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 extreem klein vergeleken met brute force aanvallen.

Dit wordt ook bevestigd door de beoordeling van de OWASP: Hier wordt aangenomen dat de aanval redelijk wijdverspreid is, gemakkelijk op te sporen en alleen in zeer specifieke gevallen ernstig.

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.

De beste manier om je te beschermen tegen cross site request forgery is je onderzoek doen en een beetje gezond verstand gebruiken.

Vond je het artikel leuk?

Met jouw beoordeling help je ons om onze inhoud nog verder te verbeteren.

Laat een reactie achter

Je e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd met *.