Cross site request forgery

Cross site request forgery, afgekort CSRF of XSRF, is een aanval waarbij een kwaadwillende een ingelogde gebruiker misleidt om onbewust acties uit te voeren op een webapplicatie. De aanvaller maakt misbruik van het feit dat browsers automatisch cookies meesturen bij elk verzoek naar een website. Hierdoor kan een aanvaller via een vervalst verzoek acties uitvoeren alsof het de legitieme gebruiker is, zonder dat het slachtoffer dit doorheeft.

Hoe werkt een cross site request forgery aanval?

Een CSRF-aanval exploiteert het vertrouwensmodel van webbrowsers. Wanneer je inlogt op een webapplicatie zoals je bankieromgeving of een content management systeem, slaat de browser een sessiecookie op. Bij elk volgend verzoek naar die website stuurt de browser automatisch deze cookie mee als bewijs van jouw identiteit. Dit mechanisme maakt het mogelijk om ingelogd te blijven zonder bij elke pagina opnieuw in te loggen.

De aanvaller creert een kwaadaardige webpagina of e-mail die een verborgen verzoek bevat naar de doelwebsite. Dit verzoek kan een HTML-formulier zijn dat automatisch wordt ingediend via JavaScript, een afbeeldingstag met een speciaal geformuleerde URL, of een verborgen iframe. Wanneer het slachtoffer de kwaadaardige pagina bezoekt terwijl het ingelogd is op de doelwebsite, stuurt de browser het vervalste verzoek inclusief de geldige sessiecookie.

Een concreet voorbeeld: je bent ingelogd bij jouw bank en bezoekt vervolgens een gecompromitteerde website. Die website bevat een onzichtbaar formulier dat een overschrijving initieert naar de rekening van de aanvaller. Jouw browser stuurt dit verzoek naar de bank inclusief jouw sessiecookie. De bank ontvangt een geldig verzoek met geldige authenticatie en voert de overschrijving uit. Jij ziet niets verdachts omdat het verzoek op de achtergrond plaatsvindt.

Drie voorwaarden moeten aanwezig zijn voor een succesvolle CSRF-aanval. Ten eerste moet er een relevante actie zijn die de aanvaller wil uitlokken, zoals het wijzigen van een wachtwoord, het overmaken van geld of het aanpassen van toegangsrechten. Ten tweede moet de webapplicatie sessies beheren via cookies die automatisch worden meegestuurd. Ten derde mag het verzoek geen onvoorspelbare parameters bevatten die de aanvaller niet kan raden.

CSRF verschilt van cross-site scripting (XSS). Bij XSS injecteert de aanvaller kwaadaardige code in de webapplicatie die wordt uitgevoerd in de browser van het slachtoffer. Bij CSRF stuurt de aanvaller een verzoek namens het slachtoffer naar een webapplicatie waarop het slachtoffer is ingelogd. Beide aanvallen misbruiken het vertrouwen tussen browser en webapplicatie, maar op fundamenteel verschillende manieren. Het is belangrijk om beide aanvalstypes te begrijpen omdat ze vaak in combinatie worden ingezet: een XSS-kwetsbaarheid kan worden gebruikt om CSRF-beschermingsmechanismen te omzeilen door het CSRF-token uit de pagina te extraheren.

Hoe herken je een CSRF-aanval?

CSRF-aanvallen zijn lastig te herkennen voor eindgebruikers omdat ze onzichtbaar plaatsvinden. Het slachtoffer merkt pas iets wanneer de gevolgen zichtbaar worden: een onverwachte transactie, gewijzigde accountinstellingen of ongeautoriseerde acties op een platform. Er is geen duidelijk signaal op het moment dat de aanval plaatsvindt.

Voor ontwikkelaars en beveiligingsteams zijn CSRF-kwetsbaarheden te detecteren via security audits en penetratietesten. Test of state-changing endpoints beschermd zijn tegen cross-origin verzoeken. Controleer of formulieren een specifiek CSRF-token bevatten dat niet voorspelbaar is. Geautomatiseerde scanners zoals OWASP ZAP en Burp Suite kunnen CSRF-kwetsbaarheden identificeren door verzoeken te herhalen zonder het verwachte token.

In webserverlogboeken kun je CSRF-aanvallen detecteren door te zoeken naar verzoeken die afkomstig zijn van externe referers maar geldige sessiecookies bevatten. Een POST-verzoek naar jouw wachtwoord-wijzigpagina met een referer-header van een externe website is een sterk signaal van een CSRF-poging. Web application firewalls kunnen regels bevatten die dergelijke patronen automatisch blokkeren.

Monitor ook op ongebruikelijke patronen van state-changing verzoeken. Als een gebruiker binnen enkele seconden meerdere kritieke acties uitvoert vanaf verschillende referers, kan dit wijzen op een geautomatiseerde CSRF-aanval die via meerdere kwaadaardige pagina's wordt uitgevoerd.

Hoe bescherm je je tegen cross site request forgery?

De meest effectieve bescherming is het gebruik van anti-CSRF-tokens. De server genereert een specifiek, onvoorspelbaar token dat wordt opgenomen in elk HTML-formulier als verborgen veld. Bij het verwerken van het formulier controleert de server of het meegestuurde token overeenkomt met het verwachte token. Omdat de aanvaller dit token niet kent en niet kan raden, kan het vervalste verzoek niet worden gevalideerd.

Het SameSite-attribuut voor cookies biedt een krachtige verdedigingslaag. Door het SameSite-attribuut in te stellen op Strict of Lax, voorkom je dat cookies worden meegestuurd bij verzoeken die worden geinitieerd vanaf een andere website. De instelling Strict biedt maximale bescherming maar kan de gebruikservaring beinvloeden, terwijl Lax een balans biedt tussen beveiliging en bruikbaarheid door cookies wel mee te sturen bij top-level navigatie maar niet bij cross-origin verzoeken.

Moderne webframeworks bieden ingebouwde CSRF-bescherming. Django, Ruby on Rails, Laravel, Spring en ASP.NET genereren automatisch CSRF-tokens en valideren deze bij formulierinzendingen. Controleer of deze bescherming is geactiveerd in jouw framework-configuratie en dat alle state-changing endpoints erdoor worden beschermd.

Aanvullende maatregelen omvatten het controleren van de Origin- en Referer-headers bij inkomende verzoeken, het gebruik van custom request headers die niet automatisch worden meegestuurd door browsers, en het vereisen van hernieuwde authenticatie voor kritieke acties zoals het wijzigen van wachtwoorden of het uitvoeren van financiele transacties. Content Security Policy headers bieden een extra verdedigingslaag door te beperken welke domeinen formulieren mogen indienen naar jouw applicatie.

Bij single-page applicaties die communiceren via API-calls is de bescherming anders opgezet. In plaats van verborgen formuliervelden gebruik je hier custom headers zoals X-Requested-With die niet automatisch worden meegestuurd bij cross-origin verzoeken. De browser blokkeert cross-origin verzoeken met custom headers tenzij de server deze expliciet toestaat via CORS-headers. Dit maakt de combinatie van custom headers en strikte CORS-configuratie een effectieve verdediging voor moderne webapplicaties.

Educatie van ontwikkelaars is minstens zo belangrijk als technische maatregelen. Veel CSRF-kwetsbaarheden ontstaan doordat ontwikkelaars GET-verzoeken gebruiken voor state-changing operaties of vergeten CSRF-bescherming te activeren op nieuwe endpoints. Security-aware development practices, inclusief code reviews met aandacht voor CSRF, verkleinen het risico op deze kwetsbaarheden aanzienlijk. Op de vergelijkingspagina vind je aanbieders van penetratietesten die CSRF-kwetsbaarheden in jouw webapplicaties opsporen.

Veelgestelde vragen over cross site request forgery

Wat is het verschil tussen CSRF en XSS?

CSRF laat de browser van het slachtoffer een vervalst verzoek sturen. XSS injecteert kwaadaardige code die in de browser wordt uitgevoerd.

Beschermt HTTPS tegen CSRF-aanvallen?

Nee, HTTPS versleutelt verkeer maar voorkomt niet dat browsers automatisch cookies meesturen bij cross-origin verzoeken.

Zijn REST API's kwetsbaar voor CSRF?

API's die cookie-gebaseerde authenticatie gebruiken zijn kwetsbaar. API's met Bearer tokens in headers zijn inherent beschermd.

Hoe test je op CSRF-kwetsbaarheden?

Gebruik tools zoals Burp Suite of OWASP ZAP. Stuur verzoeken zonder CSRF-token en controleer of de server ze accepteert.

Kan een CSRF-aanval gegevens stelen?

Meestal niet direct. CSRF voert acties uit namens het slachtoffer maar kan doorgaans geen responsdata uitlezen vanuit cross-origin verzoeken.

Wil je jouw webapplicaties laten testen op CSRF-kwetsbaarheden? Vergelijk pentestaanbieders op IBgidsNL.