--- id: CP-053 slug: csrf-afgedwongen-verzoek-tussen-sites lang: nl title: "CSRF: de actie die buiten u om wordt afgedwongen" description: Een besmette site of een bericht kan uw browser namens u laten handelen bij een dienst waar u bent ingelogd. Zo werkt het, en dit helpt ertegen. canonical_url: https://startbrain.io/cyberpedia/nl/articles/csrf-afgedwongen-verzoek-tussen-sites/ markdown_url: https://startbrain.io/cyberpedia/nl/articles/csrf-afgedwongen-verzoek-tussen-sites.md publisher: Brain (https://startbrain.io) license: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) cite_as: "Brain, “CSRF: de actie die buiten u om wordt afgedwongen”, Cyberpedia, 2026. https://startbrain.io/cyberpedia/nl/articles/csrf-afgedwongen-verzoek-tussen-sites/ (CC BY 4.0)" wing: 1 theme: understand_hacking reflex: cr-018 schema: G3 updated: "2026-11-03" translations: nl: https://startbrain.io/cyberpedia/nl/articles/csrf-afgedwongen-verzoek-tussen-sites/ fr: https://startbrain.io/cyberpedia/fr/articles/csrf-requete-forcee-inter-sites/ en: https://startbrain.io/cyberpedia/en/articles/csrf-cross-site-request-forgery/ de: https://startbrain.io/cyberpedia/de/articles/csrf-websiteuebergreifende-anfragefaelschung/ es: https://startbrain.io/cyberpedia/es/articles/csrf-falsificacion-peticiones-entre-sitios/ it: https://startbrain.io/cyberpedia/it/articles/csrf-richiesta-contraffatta-tra-siti/ sources: - "n": 1 title: Cross Site Request Forgery (CSRF) | OWASP Foundation publisher: OWASP url: https://community.owasp.org/attacks/csrf accessed: "2026-11-03" - "n": 2 title: Prevent Cross-Site Request Forgery (XSRF/CSRF) attacks in ASP.NET Core publisher: Microsoft url: https://learn.microsoft.com/en-us/aspnet/core/security/anti-request-forgery?view=aspnetcore-10.0 accessed: "2026-11-03" - "n": 3 title: Cross-Site Request Forgery Prevention - OWASP Cheat Sheet Series publisher: OWASP url: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html accessed: "2026-11-03" - "n": 4 title: SameSite | OWASP Foundation publisher: OWASP url: https://community.owasp.org/SameSite accessed: "2026-11-03" - "n": 5 title: "CWE - CWE-352: Cross-Site Request Forgery (5.0)" publisher: MITRE url: https://cwe.mitre.org/data/definitions/352.html accessed: "2026-11-03" --- # CSRF: de actie die buiten u om wordt afgedwongen CSRF (Cross-Site Request Forgery) is de Engelse naam voor een aanval die een gebruiker ongewilde handelingen laat uitvoeren in een webapplicatie waarin die al is ingelogd [1]. De aanvaller heeft het wachtwoord van het slachtoffer niet nodig: hij laat de browser van het slachtoffer handelen. Voor een medewerker is het typische scenario eenvoudig. In een tabblad staat een mailbox of een bankwebsite open. Een link uit een e-mail of een chatbericht leidt naar een andere pagina, en die pagina stuurt op de achtergrond een verzoek naar de dienst waar u nog bent ingelogd [1]. ## In 30 seconden - Waar het gebeurt: bij de meeste webdiensten zonder CSRF-bescherming, wanneer u in dezelfde browser een besmette link of pagina opent [1]. - Wat de aanvaller wil: een actie uitlokken die iets wijzigt, zoals een overschrijving of een wachtwoordwijziging [1]. - De reflex: log uit bij een dienst zodra u er klaar mee bent [2]. - Waar de zwakke plek vandaan komt: van de applicatie, niet van de gebruiker [2]. ## Directe vragen ### Steelt CSRF mijn wachtwoord? Nee, niet als zodanig. De aanval leent de identiteit en de rechten van het slachtoffer om namens hem een actie uit te voeren [1]. Hij richt zich op acties die de toestand van de dienst veranderen, zoals het wijzigen van het e-mailadres of het wachtwoord, of het kopen van iets. Het slachtoffer dwingen gegevens op te vragen levert de aanvaller niets op, want het antwoord gaat naar het slachtoffer, niet naar hem [1]. ### Waarom gehoorzaamt de dienst aan een verzoek dat ik niet wilde? Omdat hij het niet van een legitiem verzoek kan onderscheiden. Bij de meeste sites bevatten de verzoeken van de browser automatisch de gegevens die bij de site horen, zoals de sessiecookie [1]. Is de gebruiker ingelogd, dan kan de site het vervalste verzoek dus niet scheiden van het echte [1]. De CWE omschrijft de zwakte zo: de applicatie controleert niet, of kan niet controleren, dat een verzoek bewust is ingediend door de gebruiker die het heeft verstuurd [5]. ### Ben ik beschermd als de dienst HTTPS gebruikt? Nee. Volgens OWASP beschermt HTTPS alleen niet tegen CSRF, hoewel het een voorwaarde blijft om de andere maatregelen betrouwbaar te maken [1]. ### Ligt het probleem bij mij of bij de applicatie? Bij de applicatie. Microsoft zegt het ronduit: CSRF-kwetsbaarheden zijn in wezen een probleem van de webapplicatie, niet van de eindgebruiker [2]. Wat de gebruiker doet, beperkt alleen de blootstelling: uitloggen als u klaar bent en de cookies van de browser regelmatig wissen [2]. ## In de huid van de aanvaller De aanvaller begint met het opsporen van een verzoek dat iets wijzigt bij een dienst. Daarna maakt hij een adres of een script dat dit verzoek met zijn eigen waarden nabootst. OWASP geeft het voorbeeld van een fictieve bank: het legitieme verzoek maakt 100 dollar over aan een begunstigde, en de aanvaller vervangt de begunstigde door zichzelf en verhoogt het bedrag [1]. Dan moet het slachtoffer dat verzoek nog laden terwijl het is ingelogd. Twee methoden worden genoemd: een ongevraagde e-mail met HTML-inhoud, of een val op pagina's die het slachtoffer waarschijnlijk bezoekt terwijl het zijn onlinedienst gebruikt [1]. De aanval kan ook op de kwetsbare site zelf worden opgeslagen, bijvoorbeeld in een veld dat HTML accepteert. Dan wordt hij waarschijnlijker: het slachtoffer bekijkt liever een pagina van die site dan een willekeurige pagina op internet, en is daar vanzelfsprekend al ingelogd [1]. ## Wat u op het scherm ziet Vaak niets. De besmette link kan zijn vermomd als een gewone link, met een tekst als "bekijk mijn foto's". Hij kan ook de vorm hebben van een nepafbeelding van grootte nul: staat die in een e-mail, dan ziet het slachtoffer niets, maar de browser verstuurt het verzoek toch, zonder enig zichtbaar teken dat de handeling heeft plaatsgevonden [1]. ```text Geneutraliseerde illustratie, geen echt adres. Vermomde link: weergegeven tekst "Bekijk mijn foto's", verborgen adres hxxp://banque[.]exemple[.]invalid/virement?dest=[rekening van de aanvaller]&montant=[hoog] Variant: onzichtbare afbeelding in een e-mail, geladen zonder klik. ``` Verwacht de dienst een POST-verzoek, dan kan de aanvaller op zijn site een formulier met verborgen velden plaatsen. Het slachtoffer denkt dat het iets anders doet en klikt, of een script verstuurt het automatisch zodra de pagina laadt [1]. In beide gevallen is de getoonde pagina alledaags en vindt de actie elders plaats. ## Onder de motorkap Het mechanisme berust op normaal gedrag van browsers. Ze slaan de cookies op die een applicatie uitgeeft, waaronder de sessiecookies van ingelogde gebruikers, en ze sturen bij elk verzoek alle cookies van een domein mee, hoe dat verzoek in de browser ook is ontstaan [2]. Cookies zijn niet het enige probleem: ook authenticatie van het type Basic en Digest is kwetsbaar, omdat de browser de inloggegevens automatisch opnieuw verstuurt tot het einde van de sessie [2]. Volgens OWASP werken verschillende verdedigingsideeën niet [1]: - een geheime cookie, want alle cookies worden bij elk verzoek meegestuurd; - alleen POST-verzoeken accepteren, want een verborgen formulier volstaat om er een te vervalsen; - transacties in meerdere stappen, zolang de aanvaller elke stap kan voorspellen; - alleen de Referer-header controleren, want die kan worden vervalst en ontbreekt soms om privacyredenen. De aanbevolen beveiligingen aan de kant van de applicatie zijn de volgende. - Eerst nagaan of het framework al CSRF-bescherming biedt, en die gebruiken. Zo niet, anti-CSRF-tokens toevoegen aan alle verzoeken die de toestand wijzigen en ze aan de serverkant valideren [3]. Zonder token kan de aanvaller geen geldig verzoek maken [3]. - Voor software zonder toestand een double-submit-cookie gebruiken, bij voorkeur ondertekend [3]. - Het attribuut SameSite instellen op sessiecookies [3]. Bij de waarde strict stuurt de browser de cookie niet mee bij verzoeken tussen sites, ook niet bij het volgen van een gewone link. Bij lax stuurt hij de cookie wel mee voor een link die vanaf een andere site wordt gevolgd, maar houdt hij hem achter bij methoden die aan CSRF zijn blootgesteld, zoals POST [4]. Bij none is er geen enkele bescherming [4]. - De herkomst controleren met standaardheaders, met name Sec-Fetch-Site, dat sinds maart 2023 door alle grote browsers wordt ondersteund [3]. - Geen GET-verzoeken gebruiken voor handelingen die de toestand wijzigen [3]. Deze maatregelen hebben grenzen. SameSite=Lax laat GET-verzoeken voor navigatie op het hoogste niveau door: een eindpunt dat de toestand via GET wijzigt, blijft kwetsbaar [2]. Oudere browsers passen SameSite mogelijk niet toe [2]. En een XSS-kwetsbaarheid kan alle anti-CSRF-beveiligingen omzeilen; de Samy-worm gebruikte bijvoorbeeld een XMLHttpRequest om het CSRF-token te bemachtigen en verzoeken te vervalsen [1][3]. Het standaardgedrag van SameSite verschilt: in december 2024 was lax de standaardwaarde van Chrome, Edge en Opera, maar van geen enkele versie van Firefox of Safari, vandaar het advies om de waarde expliciet in te stellen [4]. ## Incidentanalyses ### 2008: de uTorrent-exploit OWASP noemt als echt voorbeeld van een CSRF-aanval op een applicatie die met GET-verzoeken werkt een exploit tegen uTorrent uit 2008. Die is op grote schaal gebruikt om malware te downloaden [1]. De bron zegt niet meer: niet hoeveel slachtoffers er waren, en niet hoe de exploit werd verspreid. ### Door de CWE gecatalogiseerde kwetsbaarheden (identifiers van 2004 tot 2009) CWE-352 geeft een gekozen lijst van waargenomen voorbeelden, die niet volledig is [5]. Verschillende berusten op een simpele URL in een img-tag: CVE-2004-1703 en CVE-2004-1995 maken het mogelijk gebruikersaccounts toe te voegen, CVE-2004-1842 om beheerdersrechten te krijgen [5]. Andere raken het beheer zelf: CVE-2009-3520 maakt het mogelijk het wachtwoord van de beheerder te wijzigen, en CVE-2009-3759 om wachtwoorden te wijzigen of een virtuele machine uit te schakelen via een webinterface [5]. ## Bronnen 1. OWASP, “Cross Site Request Forgery (CSRF) | OWASP Foundation”. https://community.owasp.org/attacks/csrf (geraadpleegd op 3 november 2026) 2. Microsoft, “Prevent Cross-Site Request Forgery (XSRF/CSRF) attacks in ASP.NET Core”. https://learn.microsoft.com/en-us/aspnet/core/security/anti-request-forgery?view=aspnetcore-10.0 (geraadpleegd op 3 november 2026) 3. OWASP, “Cross-Site Request Forgery Prevention - OWASP Cheat Sheet Series”. https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html (geraadpleegd op 3 november 2026) 4. OWASP, “SameSite | OWASP Foundation”. https://community.owasp.org/SameSite (geraadpleegd op 3 november 2026) 5. MITRE, “CWE - CWE-352: Cross-Site Request Forgery (5.0)”. https://cwe.mitre.org/data/definitions/352.html (geraadpleegd op 3 november 2026) --- Oorspronkelijke bron: Cyberpedia, de openbare encyclopedie over cyberveiligheid en AI van Brain. Canonieke versie: https://startbrain.io/cyberpedia/nl/articles/csrf-afgedwongen-verzoek-tussen-sites/ U mag deze tekst vrij hergebruiken onder de licentie CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/), mits u “Brain, Cyberpedia” vermeldt met een link naar bovenstaand adres.