Cookies als gevaar: Cross-Site Request Forgery

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

CSRF, deze afkorting komt herhaaldelijk voor in de beveiligings- en onderhoudsupdates van de WordPress -Core. De methode die erachter zit, is nu oude rot en maakt gebruik van de overvloedige cookies van een internetgebruiker. Gelukkig is het vrij eenvoudig om jezelf te beschermen tegen Cross-Site Request Forgery. Het enige wat je nodig hebt is een beetje tijd en aandacht.

Waarschijnlijk maakt u ook gebruik van een aantal diensten waarbij er een optie is om ingelogd te blijven, zelfs nadat u de site heeft verlaten. Als u vervolgens de site opnieuw bezoekt, hoeft u uw inloggegevens niet opnieuw in te voeren, maar wordt u direct ingelogd. Dit is natuurlijk geweldig voor de gebruiker, want het is - net als een wachtwoordbeheer of een zgn. Enkelvoudig aanmelden - vervelend formulier invullen.

Op de achtergrond gebeurt het volgende: Wanneer u voor het eerst inlogt op de site, slaat de website een cookie op in uw browser. Dit is een klein tekstbestand waarin bepaalde informatie kan worden opgeslagen. Als je ingelogd blijft, is dit een willekeurig gegenereerde tekenreeks.

De volgende keer dat u de website bezoekt, controleert de server deze tekenreeks en als hij de bijbehorende tegenhanger kan vinden, logt hij u automatisch in. Dit is trouwens ook de reden waarom u overal wordt uitgelogd, als u uw Browser Cache leeg. Dit komt omdat alle cookies tijdens dit proces worden verwijderd.

Een CSRF-aanval is in wezen een misbruik van vertrouwen

Je merkt het al: Bij een overeenkomstige aanval veinst de aanvaller iets naar de dienst die de cookies leest. Hoe dit precies gebeurt, wordt hieronder aan de hand van twee voorbeelden uitgelegd.

Het gevaar van deze manipulatie ligt in het feit dat een derde partij, dus de aanvaller, wijzigingen aanbrengt in uw Facebook-profiel, bijvoorbeeld namens uzelf. Cross-Site Request Forgery is echter vaak ook afhankelijk van phishing. Ook hier wordt vertrouwen relevant - namelijk uw vertrouwen in de afzender van bijvoorbeeld e-mails.

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

Hoe bedreigd is datWordPress ?

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 kritische kwetsbaarheden in webapplicaties. Bij de voorlopige lijst voor 2017 CSRF staat op de 8e plaats van de 10. In 2007 en 2010 eindigde de aanval nog op de 5e plaats, In 2013 steeg het naar de 8e plaats uit.

Een van de redenen hiervoor is waarschijnlijk dat CSRF-aanvallen bijna net zo oud zijn als het internet zelf. Professionele ontwikkelaars zijn nu bekwaam in het beveiligen van hun code tegen hen. Veiligheidsrisico's zijn daarom eenvoudig en snel te verhelpen.

Met WordPress een is ook op wacht. Zo werd in mei beveiligingsupdate 4.7.5 uitgebracht, waarmee zes kwetsbaarheden werden opgelost die hackers hadden kunnen gebruiken om via cross-site scripting of cross-site request forgery een aanval uit te voeren. Vaak maar toch cross-site scripting wordt beschouwd als veel gevaarlijker.

Bovendien is de kwestie van Cross-Site Request Forgery meestal relevanter voor Plugin- en applicatieontwikkelaars dan voor webdesigners, bureaus en het MKB. Want bescherming tegen CSRF is ook een kwestie van programmering. CSRF zou bijvoorbeeld relevant kunnen worden voorPluginaankopen.

Maar hoe werkt het geheel nu?

De anatomie van Cross-Site Request Forgery

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

  1. De hacker laat het slachtoffer een gemanipuleerde pagina laden of klikt op een link, bijvoorbeeld door zich voor te doen als een vertrouwd persoon of door de menselijke nieuwsgierigheid uit te buiten. Met andere woorden, phishing speelt een belangrijke rol in dit soort aanvallen.
  2. Bij het laden of klikken op de gemanipuleerde links of pagina's voert de browser van het slachtoffer een HTTP-verzoek uit zonder dat het slachtoffer het merkt.

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

Laten we zeggen dat Justus Bob wil overhalen... www.bank.de Maak 100€ over en Skinny zit te wachten op een CSRF-aanval. Skinny kan nu de GET of POST methode gebruiken voor zijn aanval.

De volgende voorbeelden komen overigens uit de volgende bronnen:

Cross-Site Request Forgery in de GET-methode

De GET-methode wordt gebruikt om een resource van een server op te vragen, bijvoorbeeld een HTML-bestand. De parameters die nodig zijn voor de oproep worden eenvoudigweg toegevoegd aan de URL. En zoals we al gehoord hebben van SQL-injecties weten: Een URL is relatief eenvoudig te manipuleren.

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

GET http://bank.de/transfer.do?acct=BOBetrag=100 HTTP/1.1

Skinny bouwt 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=SKINNYetrag=100000

Natuurlijk moet Justus de actie uitvoeren die achter de neplink schuilgaat. Daarom stuurt Skinny Justus een mailtje met een neplink. De HTML-code kan er bijvoorbeeld zo uitzien:

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

Of hij stuurt hem een e-mail met een "onzichtbare" (want 0 bij 0 pixels) afbeelding. Wanneer u probeert de afbeelding te laden, krijgt de browser toegang tot de URL zonder dat Justus dit merkt:

Wanneer Justus de link oproept - bewust of onbewust - worden de parameters doorgegeven aan de server, wordt de overdracht geïnitieerd en verdwijnt 100.000€ van zijn account.

Natuurlijk moet Justus op de link klikken terwijl hij ingelogd is. Maar als er helaas een login cookie van zijn bank in zijn browser zit de aanval werkt zelfs als hij de pagina op dat moment nog niet heeft geopend.

Dit is precies wat Cross-Site Request Forgery zo verraderlijk maakt: de benadeelde kan niet eens weten dat het koekje bestaat.

Cross-Site Request Forgery in de POST-methode

De GET-methode kan worden gebruikt in links en is daarom bijzonder gemakkelijk te verspreiden. Dit speelt de aanvaller natuurlijk in de kaart wat betreft de verdeling. Maar nu kunnen aanbieders ervoor zorgen dat GET-verzoeken geen schriftelijke toestemming krijgen.

Dan blijft de POST-methode over: hier worden de gegevens naar een server overgebracht, zodat ze verder kunnen worden verwerkt. De gegevens maken echter geen deel uit van de URL, maar worden bij de header gevoegd.

Het klinkt misschien wat lijvig, maar je kent zeker de use case. Want vormen werken op deze manier.

Voor onze aanvaller, Skinny, betekent dit dat hij weliswaar meer moeite moet doen, maar toch zijn doel kan bereiken.

Zelfde scenario: Justus wil geld overmaken aan Bob. Dus hij vult www.bank.com de volgende vorm:

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

    <invoer type="tekst" naam="door">

    <invoer type="tekst" naam="op">

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

    <invoer type="onderwerpen>

formulier>

Dit stuurt het commando geld_ueberweisen.php dat er als volgt uitziet

indien(isset($_FORM["door"]) && isset($_FORM["op"]) &&isset($_FORM["crowd_in_euro"]) && isset($_CMOKIE["user_logged in"]))

{

    transMoney("door", "op", "bedrag");

    echo "Overdracht succesvol!";

}

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

Skinny deponeert nu een onzichtbaar formulier op een gemanipuleerde website, bijv.

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

    <invoer type="tekst" naam="door" waarde="Justus" stijl="display: verborgen">

    <invoer type="tekst" naam="op" waarde="Mager" stijl="display: verborgen">

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

    <invoer type="onderwerpen waarde="Hij die dit mysterie niet kan oplossen is geen echte detective!">

formulier>

Hij stuurt de link naar deze gemanipuleerde website naar Justus. Als hij zich uitgedaagd voelt, klikt hij op de knop om de puzzel te zien; en dan voert hij onbewust de functie geld_ueberweisen.php uit. Aangezien deze een corresponderend koekje in zijn browser vindt, worden 100.000€ opnieuw naar Skinny overgedragen.

aanval met slinkse middelen

Vandaar de naam Kruis-Site Request Forgery: De hacker stuurt het commando meestal vanaf een andere site. Om kant A aan te vallen, deponeert hij daarom kwaadaardige code op kant B. Vervolgens lokt hij de nietsvermoedende gebruiker hierheen zodat zijn browser de code kan uitvoeren.

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

Hoe te beschermen tegen CSRF-aanvallen

Het goede nieuws: Cross-Site Request Forgery bestaat al heel lang. Ontwikkelaars kennen het risico en werken er hard aan om het te elimineren.

Het slechte nieuws is dat je je er technisch gezien niet echt tegen kunt beschermen. De WordPress -Kern is nu relatief goed beschermd, en zoals u kunt zien aan de lopende updates, wordt er voortdurend aan gewerkt. Net als bij andere soorten aanvallen, gaan de meeste kwetsbaarheden met zich meePlugins . Je moet er dus op vertrouwen dat de ontwikkelaars van de extensies die je gebruikt goed werk leveren.

Dat betekent concreet:

  • Installeer er niet te veel Plugins en alleen die Pluginsje echt nodig hebt.
  • Kijk uit voor Pluginsdegenen die niet zijn bijgewerkt door de ontwikkelaars voor een lange tijd. Onopgeloste veiligheidsgaten kunnen hier worden verborgen.
  • Ontdek van tevoren welke Pluginsu installeert, bijvoorbeeld hun compatibiliteit met anderen Plugins of de WordPress versie die u gebruikt (zodat deze Plugin kan worden bijgewerkt).
  • Update uw Plugins en de WP-Core regelmatig. Want de continue updates zijn er precies om dergelijke beveiligingsgaten te dichten.
  • Je bent kritisch over phishing
  • Als u niet zeker bent: neem een kijkje in de Plugin WP repository. Wat zijn de ratings, wat zijn de grootste problemen in het verleden geweest en heeft dit Plugin mogelijk niet een prominent veiligheidsgat gedicht?

Conclusie: CSRF is een oude rotbeitel

Cross-Site Request Forgery bestaat al sinds het begin van het digitale tijdperk. Bovendien is het aantal gevallen toegenomen in vergelijking met bijvoorbeeld Brute Force Aanvallen uiterst klein.

Dit bevestigt ook de beoordeling van OWASPHier wordt aangenomen dat de aanval vrij kleinschalig is, gemakkelijk op te sporen is en alleen in zeer specifieke gevallen ernstig is. is.

Toch is het goed om te weten hoe de aanvallen werken. Want vaak werken de aanvallen alleen dankzij een menselijke fout. Steeds weer openen gebruikers mails uit nieuwsgierigheid of klikken ze op links die ze niet hadden moeten openen.

Dus of u nu een gebruiker of een gebruiker bent, de beste manier om uzelf te beschermen tegen Cross-Site Request Forgery is om wat onderzoek te doen en een beetje gezond verstand te gebruiken.

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 te Slack vinden.

Gerelateerde artikelen

Commentaar op dit artikel

Schrijf een opmerking

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