Bescherming tegen CSRF aanvallen

Een van de aanvallen op webapplicaties die de afgelopen jaren behoorlijk is toegenomen is CSRF (Cross-Site Request Forgery). Het beschermen hier tegen is echter lastig. Om een bescherming toe te passen dient er uitgebreide kennis aanwezig te zijn van zowel het systeem dat beschermd moet worden als CSRF zelf.

Voor we in kunnen gaan op de bescherming tegen CSRF is het van belang om te weten wat het precies inhoudt en wat de risico's zijn wanneer je kiest om je hier niet tegen te beschermen.

CSRF is het beste te begrijpen door een voorbeeld. Hieronder zijn twee voorbeelden gegeven van CSRF aanvallen en hoe gevaarlijk ze zijn.

Voorbeeld 1:

Persoon A (genaamd Anton) heeft een website. Op deze website moet men inloggen om wijzigingen te maken aan de inhoud van de website. Anton heeft een mooie afbeelding op de website van Persoon B, (genaamd Berend), gezien. Anton besluit in het kader van bandbreedtebesparing om de afbeelding direct van de site van Berend te laden. Berend komt hier achter en besluit de afbeelding te linken naar de uitlog pagina van Anton. Op het moment dat Anton nu inlogt op zijn eigen website wordt de afbeelding, die verwijst naar de uitlog pagina, geladen. Het resultaat is dat Anton direct weer is uitgelogd. Hij kan niet meer kan inloggen op zijn eigen website.

Het voorgaande voorbeeld is een onschuldig voorbeeld. CSRF kan voor gevaarlijker situaties zorgen. Zie het volgende voorbeeld.

Voorbeeld 2:

Persoon A (genaamd Anke) ziet dat een veilingsite ondersteuning biedt voor externe afbeeldingen. (Afbeeldingen waar het volledige URL voor dient ingevuld te worden.) Anke besluit om een aanbieding te plaatsen voor haar oude auto. Op de aanbieding kan geboden worden. Het bieden op de auto geschiedt door de volgende link:

http://www.naamveilingwebsite.nl/bieden?aanbieding=1020&bedrag=[HIER HET BIEDBEDRAG]

Anke weet dit en besluit een tweede advertentie te plaatsen, waarin ze een nieuwe Porsche aanbiedt. Dit keer plaatst Anke de bovenstaande link als externe afbeelding en stelt het bod in op 100.000 euro. Persoon B genaamd Bert komt op de website en ziet de advertentie van Anke. Wanneer Bert de advertentie van Anke opent, heeft hij ongemerkt 100.000 euro geboden op de oude auto, omdat de browser die Bert gebruikt de externe afbeelding probeerde te laden en dus de link heeft geopend.

Voorbeeld 2 geeft aan hoe gevaarlijk CSRF daadwerkelijk kan zijn. De bescherming hiertegen is echter lastig omdat de ‘valse’ aanvragen vanaf het slachtoffer zelf komen.

Applicaties beschermen tegen CSRF aanvallen

Het beschermen tegen CSRF is lastig. Er zijn echter een aantal beveiligingsmaatregelen die het toepassen van CSRF aanvallen bemoeilijken. De methode die geïmplementeerd is in Webbeheer CMS is het gebruik maken van tokens.

Tokens zijn unieke letterreeksen waarmee gecontroleerd kan worden of de aanroep van een locatie geldig is. Deze tokens dienen voor iedere gebruiker willekeurig te zijn en na elke aanroep vervangen te worden door een nieuwe token. Belangrijk is dat iedere aanvraag wordt voorzien van een token en dat deze iedere keer wordt gecontroleerd. De link die wordt gegeven in het tweede voorbeeld zou na implementatie er bijvoorbeeld zo uit kunnen zien:

http://www.naamveilingwebsite.nl/bieden?aanbieding=1020&bedrag=200&token=a82e8df892819c19c19bb19283d

Aan de link is een token toegevoegd die voor iedere gebruiker uniek is. Anke weet deze token niet van Bert. Wanneer Bert de token van Anke zou gebruiken, zal er niet geboden worden op de aanbieding. De website controleert of de token die Bert gebruikt ook werkelijk zijn token is. Als dit niet het geval is wordt de aanroep geannuleerd.

Internationale URL’s Memcached verhoogt de snelheid van uw website