Terug naar begrippenlijst

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.

Geschreven door Thijn de Haas

Zwaaiende emoji

Thijn Lead developer

Meer over Thijn

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.

Thijn de Haas Lead developer

Meer over Thijn

Mijn programmeeravontuur begon rond mijn twaalfde, toen ik ontdekte dat je met code vrijwel alles kunt maken. Ik begon met het bouwen van kleine projecten en startte al snel mijn eigen hostingdienst, wat me veel leerde over maatwerkcode, serverbeheer en het koppelen aan websites. Deze kennis pas ik nu dagelijks toe in mijn werk aan websites en applicaties.

Als student Applicatieontwikkelaar liep ik drie stages bij Wux, waarbij ik tijdens de eerste stage mijn eerste bedrijf startte, deels op advies van Bo. Deze ervaringen vormden het fundament van mijn rol als lead developer en mede-eigenaar van Wux. Met een constante interesse in nieuwe technieken en het meedenken naar de beste oplossingen, zet ik mijn expertise dagelijks in om complexe vraagstukken op te lossen samen met mijn team.

Twee mannen in overleg tijdens het werk achter hun computerschermen
Zwaaiende emoji

Thijn Back-end developer

Op zoek naar slimme software-oplossingen die jouw bedrijf efficiënter maken?

Het team van Wux ontwikkelt maatwerk software die aansluit bij jouw behoeften. Neem vandaag nog contact op en ontdek hoe we jouw bedrijf elke dag succesvoller kunnen maken.

Meer over software