Cross-Site Request Forgery (CSRF)

XSRF, Sea Surf, Session Riding, Cross-Site Reference Forgery, Hostile Linking, One-Click Attack, CSRF-aanval, Vervalste cross-site verzoeken
Cross-Site Request Forgery (CSRF) is een beveiligingslek waarbij kwaadwillenden ongeautoriseerde acties uitvoeren namens een ingelogde gebruiker door misbruik te maken van hun authenticatiesessie.
Security & Monitoring

Wat is Cross-Site Request Forgery (CSRF)?

Cross-Site Request Forgery (CSRF) is een veelvoorkomend beveiligingslek in webapplicaties waarbij een aanvaller een ingelogde gebruiker misleidt om ongewenste acties uit te voeren op een website waar ze momenteel zijn geauthenticeerd. De aanval maakt misbruik van het vertrouwen dat een website heeft in de browser van de gebruiker.

Bij een CSRF-aanval stuurt de aanvaller een kwaadaardig verzoek naar een webapplicatie via de browser van het slachtoffer. Omdat de gebruiker al is ingelogd en de browser automatisch authenticatiecookies meestuurt, denkt de server dat het verzoek legitiem is en voert de actie uit.

Hoe werkt een CSRF-aanval?

Een typische CSRF-aanval verloopt in de volgende stappen:

  • Stap 1: Het slachtoffer logt in op een legitieme website (bijvoorbeeld een bankwebsite) en ontvangt een sessiecookie
  • Stap 2: De aanvaller stuurt het slachtoffer een link via e-mail, social media of een andere website
  • Stap 3: Het slachtoffer klikt op de link terwijl ze nog steeds zijn ingelogd op de legitieme website
  • Stap 4: De kwaadaardige link bevat een verborgen verzoek dat automatisch wordt uitgevoerd
  • Stap 5: De browser stuurt het verzoek inclusief de sessiecookie naar de legitieme website
  • Stap 6: De website voert de ongewenste actie uit (bijvoorbeeld geld overmaken, wachtwoord wijzigen)

Verschil tussen CSRF en XSS

Hoewel Cross-Site Request Forgery (CSRF) en Cross-Site Scripting (XSS) beide beveiligingslekken zijn, werken ze fundamenteel anders:

  • CSRF: Maakt misbruik van het vertrouwen dat een website heeft in de gebruiker. De aanval dwingt de gebruiker om ongewenste acties uit te voeren
  • XSS: Maakt misbruik van het vertrouwen dat een gebruiker heeft in een website. De aanval injecteert kwaadaardige scripts in een legitieme website

Potentiële schade van CSRF-aanvallen

CSRF-aanvallen kunnen ernstige gevolgen hebben, afhankelijk van de functionaliteit van de getroffen applicatie:

  • Ongeautoriseerde financiële transacties en geldovermakingen
  • Wijzigen van accountgegevens zoals e-mailadres of wachtwoord
  • Plaatsen van ongewenste bestellingen in webshops
  • Verwijderen of wijzigen van belangrijke data
  • Uitvoeren van administratieve acties in beheerderspanelen
  • Posten van ongewenste content op social media

Toepassingen

Beschermingsmaatregelen tegen CSRF

Er zijn verschillende effectieve methoden om webapplicaties te beschermen tegen CSRF-aanvallen:

1. CSRF-tokens (Anti-CSRF tokens)

De meest gebruikte en effectieve bescherming is het implementeren van CSRF-tokens:

  • Genereer voor elke gebruikerssessie een unieke, onvoorspelbare token
  • Voeg deze token toe aan elk formulier als verborgen veld
  • Controleer bij elk verzoek of de token overeenkomt met de sessietoken
  • Vernieuw tokens regelmatig voor extra beveiliging

2. SameSite Cookie-attribuut

Moderne browsers ondersteunen het SameSite-attribuut voor cookies:

  • SameSite=Strict: Cookies worden alleen meegestuurd bij verzoeken van dezelfde site
  • SameSite=Lax: Cookies worden meegestuurd bij top-level navigatie
  • SameSite=None: Cookies worden altijd meegestuurd (vereist Secure-attribuut)

3. Double Submit Cookie-methode

Een alternatieve aanpak zonder server-side sessie:

  • Stuur een random waarde in zowel een cookie als een request parameter
  • Vergelijk beide waarden bij het ontvangen van het verzoek
  • Aanvallers kunnen de cookie-waarde niet lezen door same-origin policy

4. Custom Request Headers

Voor AJAX-verzoeken kun je custom headers gebruiken:

  • Voeg een custom header toe aan alle AJAX-verzoeken
  • Controleer de aanwezigheid van deze header op de server
  • Cross-origin verzoeken kunnen geen custom headers toevoegen zonder CORS

Best practices voor ontwikkelaars

Om CSRF-aanvallen effectief te voorkomen, moeten ontwikkelaars de volgende richtlijnen volgen:

  • Gebruik frameworks met ingebouwde CSRF-bescherming: Moderne frameworks zoals Django, Laravel en Ruby on Rails hebben standaard CSRF-protectie
  • Implementeer CSRF-tokens voor alle state-changing operaties: Vooral voor POST, PUT, DELETE en PATCH verzoeken
  • Valideer de Origin en Referer headers: Controleer of verzoeken van verwachte domeinen komen
  • Gebruik re-authenticatie voor gevoelige acties: Vraag wachtwoord of 2FA voor kritieke operaties
  • Implementeer rate limiting: Beperk het aantal verzoeken per tijdseenheid
  • Log en monitor verdachte activiteiten: Detecteer patronen die wijzen op CSRF-pogingen

CSRF-bescherming in populaire platforms

WordPress

WordPress heeft ingebouwde CSRF-bescherming via nonces:

  • Gebruik wp_nonce_field() in formulieren
  • Valideer met wp_verify_nonce() bij verwerking
  • Nonces zijn tijdgebonden en gebruikersspecifiek

E-commerce platforms

Webshops zoals WooCommerce en Shopify implementeren automatisch CSRF-bescherming:

  • Alle checkout-processen zijn beschermd met tokens
  • Betalingstransacties vereisen extra verificatie
  • Admin-panelen hebben versterkte CSRF-protectie

Testen op CSRF-kwetsbaarheden

Security professionals kunnen CSRF-kwetsbaarheden identificeren door:

  • Handmatige testing: Verwijder CSRF-tokens uit verzoeken en kijk of deze nog steeds worden geaccepteerd
  • Automated scanning: Gebruik tools zoals OWASP ZAP, Burp Suite of Acunetix
  • Code review: Controleer of alle state-changing endpoints CSRF-bescherming hebben
  • Penetration testing: Simuleer echte aanvallen in een gecontroleerde omgeving

Veelgestelde vragen

Hoewel beide aanvallen gebruikers misleiden om ongewenste acties uit te voeren, werken ze op verschillende manieren:

  • CSRF: De aanvaller stuurt een verborgen verzoek dat automatisch wordt uitgevoerd met de credentials van de gebruiker. De gebruiker hoeft niet direct te interacteren met de kwaadaardige content.
  • Clickjacking: De aanvaller plaatst een transparante laag over een legitieme website, waardoor gebruikers op verborgen elementen klikken. Dit vereist directe interactie van de gebruiker.

CSRF-bescherming richt zich op het valideren van de bron van verzoeken, terwijl clickjacking-bescherming gebruik maakt van X-Frame-Options headers om te voorkomen dat pagina's in iframes worden geladen.

GET-verzoeken zijn bijzonder kwetsbaar voor CSRF-aanvallen om de volgende redenen:

  • Gemakkelijk uit te voeren: GET-verzoeken kunnen worden geactiveerd via een simpele image tag, link of automatische redirect
  • Browser prefetching: Browsers kunnen GET-verzoeken automatisch uitvoeren voor performance optimalisatie
  • Logging in browserggeschiedenis: GET-parameters worden opgeslagen in browsergeschiedenis en server logs
  • RESTful best practices: Volgens HTTP-standaarden zouden GET-verzoeken alleen voor het ophalen van data moeten worden gebruikt

Gebruik altijd POST, PUT of DELETE voor acties die data wijzigen, en implementeer CSRF-tokens voor deze verzoeken.

Je kunt je website op verschillende manieren testen op CSRF-kwetsbaarheden:

Handmatige test:

  • Log in op je website en inspecteer een formulier met browser developer tools
  • Kopieer het POST-verzoek en verwijder of wijzig de CSRF-token
  • Verstuur het aangepaste verzoek en kijk of het wordt geaccepteerd
  • Als het verzoek slaagt zonder geldige token, ben je kwetsbaar

Geautomatiseerde tools:

  • OWASP ZAP: Gratis security scanner met CSRF-detectie
  • Burp Suite: Professionele tool voor security testing
  • CSRFTester: Gespecialiseerde tool voor CSRF-testing

Code review:

Controleer je broncode op de volgende punten:

  • Alle POST/PUT/DELETE endpoints hebben CSRF-validatie
  • Tokens worden correct gegenereerd en gevalideerd
  • SameSite cookie-attributen zijn correct geconfigureerd
  • Geen state-changing operaties via GET-verzoeken

Auteur & updates

Auteur: Wouter
Publicatiedatum: 16-02-2026
Laatste update: 16-02-2026