Cross-Site Request Forgery (CSRF)
Stel je bent ingelogd op je bankomgeving of beheerpaneel. Ondertussen bezoek je een andere website en klik je op een link of opent er ongemerkt een afbeelding of script. Zonder dat je iets bevestigt of ziet, wordt er een geldtransactie uitgevoerd of een instelling gewijzigd op die andere site. Niet door een hack in het systeem zelf, maar omdat jouw browser automatisch je sessie en cookies meestuurt. Dat is CSRF in actie. Cross-Site Request Forgery is een aanval waarbij een kwaadwillende jouw browser gebruikt om onbedoelde acties uit te voeren op een site waar je al bent ingelogd.
Inhoudsopgave
Je browser voert gewoon uit
Het gevaar van CSRF zit in sessies en cookies. Als jij ergens bent ingelogd, stuurt je browser bij elk verzoek automatisch de bijbehorende sessie-informatie mee. Ook als dat verzoek vanaf een andere site komt. Zo kan een aanvaller bijvoorbeeld een formulier op zijn eigen site maken dat een verzoek uitvoert op een andere site, met jouw gegevens.
Voor de ontvangende server lijkt het alsof jij het verzoek doet. Want het is echt jouw browser die dit verzoek uitvoert, met je geldige sessie.
Wat je niet ziet, kan je wél raken
CSRF-aanvallen zijn vaak onzichtbaar. Ze komen via afbeeldingen, verborgen formulieren of automatisch geladen scripts. Als gebruiker zie je niets, tot het te laat is. Denk aan situaties waarin je zonder te weten iets verwijdert, een bestelling plaatst of gevoelige data aanpast.
Gelukkig zijn er goede manieren om je hiertegen te wapenen. En als developer kun je veel doen om je applicatie te beschermen.
Tokens tegen misbruik
De bekendste manier om Cross-Site Request Forgery tegen te gaan is het gebruik van tokens. Een CSRF-token is een unieke waarde die aan elke gebruiker of sessie wordt gekoppeld. Die token moet bij elk formulier of verzoek expliciet worden meegestuurd. Heb je geen geldige token? Dan kan je de toegang op je buik schrijven.
Daarnaast helpt het om belangrijke acties te beperken tot POST-verzoeken, CORS-strategieën toe te passen en cookies veilig te configureren, bijvoorbeeld met de SameSite-instelling.
Veelgestelde vragen
Nee. Bij CSRF voert de browser van de gebruiker een ongewenste actie uit. Bij XSS wordt er kwaadaardige code in de site zelf geïnjecteerd.
Niet per se. Alleen bij acties die iets wijzigen, zoals formulieren of API-calls met belangrijke gevolgen.
Nee, dat maakt je sessie niet minder kwetsbaar. Je hebt nog steeds bescherming nodig tegen ongewenste verzoeken.
In theorie wel, maar het komt vooral voor bij webapplicaties waar sessiebeheer via de browser loopt.