CSRF: de actie die buiten u om wordt afgedwongen

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¹.

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¹.

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¹.

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¹.

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¹. In beide gevallen is de getoonde pagina alledaags en vindt de actie elders plaats.

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². 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².

Volgens OWASP werken verschillende verdedigingsideeën niet¹:

• 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³. Zonder token kan de aanvaller geen geldig verzoek maken³.
• Voor software zonder toestand een double-submit-cookie gebruiken, bij voorkeur ondertekend³.
• Het attribuut SameSite instellen op sessiecookies³. 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⁴. Bij none is er geen enkele bescherming⁴.
• De herkomst controleren met standaardheaders, met name Sec-Fetch-Site, dat sinds maart 2023 door alle grote browsers wordt ondersteund³.
• Geen GET-verzoeken gebruiken voor handelingen die de toestand wijzigen³.

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². Oudere browsers passen SameSite mogelijk niet toe². 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¹³. 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⁴.

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¹. 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⁵. 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⁵. 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⁵.