Kwetsbaarheden op het web zijn ongebreideld en nemen voortdurend toe. Het handhaven van de veiligheid en privacy van je gebruikers is belangrijker dan ooit. Het niet aanpakken van webkwetsbaarheden kan leiden tot een geruïneerde reputatie en fikse boetes van toezichthouders, en je zult ook het vertrouwen van je gebruikers verliezen.

Websites en webapplicaties zijn kwetsbaar voor malware, spam en andere aanvallen – dit artikel richt zich op één zo’n aanvalsvector – Cross-Site Request Forgery (CSRF) aanvallen. CSRF aanvallen zijn bijzonder verontrustend omdat ze kunnen plaatsvinden zonder dat de gebruiker het weet. Ze zijn ook moeilijk op te sporen door een developer of website eigenaar, omdat de kwaadaardige verzoeken sterk lijken op echte verzoeken.

Dit artikel onderzoekt een CSRF aanval, hoe die werkt, en de stappen die je kunt nemen om je erop voor te bereiden.

Bekijk onze videohandleiding om alles te begrijpen over CSRF aanvallen

Wat is een CSRF aanval?

Een Cross-Site Request Forgery aanval, ook bekend als een CSRF aanval, verleidt een geauthentiseerde gebruiker tot het uitvoeren van onbedoelde acties door kwaadaardige verzoeken in te dienen zonder dat hij zich dat realiseert.

Een illustratie van hoe Cross Site Request Forgeries (CSRF's) werken.
Hoe CSRF aanvallen werken. (Afbeelding Bron: Okta)

Doorgaans gaat het bij een CSRF aanval om verzoeken die van toestand veranderen omdat de aanvaller geen antwoord krijgt. Voorbeelden van zulke verzoeken zijn het verwijderen van een record, het wijzigen van een wachtwoord, het kopen van een product, of het versturen van een bericht. Deze kunnen allemaal zonder medeweten van de gebruiker plaatsvinden.

De kwaadwillende aanvaller gebruikt meestal social engineering om een nietsvermoedende gebruiker een link te sturen via chat of e-mail.

Als de gebruiker op de link klikt, voert hij de commando’s uit die de aanvaller heeft ingesteld.

Zo kan het klikken op een link bijvoorbeeld geld van de rekening van een gebruiker overmaken. Of hij kan het e-mailadres van een gebruiker veranderen, zodat die geen toegang meer krijgt tot zijn account.

Hoe werkt een CSRF aanval?

De eerste en meest cruciale stap bij een CSRF aanval is dat de gebruiker een verzoek tot statusverandering indient terwijl hij is ingelogd. Met CSRF aanvallen probeert de aanvaller een geauthentiseerde gebruiker onbewust een kwaadaardig webverzoek te laten indienen bij een website of webapplicatie. Deze verzoeken kunnen bestaan uit cookies, URL parameters en andere gegevenstypen die er voor de gebruiker normaal uitzien.

Om een CSRF aanval succesvol te laten zijn, moeten de volgende voorwaarden zich voordoen:

  • Een geauthentiseerde gebruiker moet ingelogd zijn op een webapplicatie die cookies gebruikt voor sessiebeheer.
  • Een aanvaller moet een vervalst verzoek creëren dat van toestand verandert.
  • Echte verzoeken die door de doelserver worden afgehandeld mogen geen onvoorspelbare parameters bevatten. Het verzoek mag bijvoorbeeld geen wachtwoord als parameter verwachten ter verificatie voordat het verzoek om statusverandering wordt gestart.

De meest voorkomende methode om CSRF aanvallen uit te voeren is het gebruik van cookies in applicaties met een zwak SameSite cookie beleid. Webbrowsers nemen cookies automatisch en vaak anoniem op, en ze slaan de door een domein gebruikte cookies op in elk webverzoek dat een gebruiker naar dat domein stuurt.

Het SameSite cookie beleid bepaalt hoe de browser in cross-site browsingcontexten de cookie behandelt. Indien ingesteld op strict, wordt de cookie niet gedeeld in cross-site browsingcontexten, wat CSRF aanvallen voorkomt. De browser koppelt de cookie in alle cross-site contexten als het is ingesteld op none. Dit maakt de applicatie kwetsbaar voor CSRF aanvallen.

Wanneer een gebruiker onbewust een kwaadaardig verzoek indient via een webbrowser, zorgen de opgeslagen cookies ervoor dat het verzoek legitiem lijkt voor de server. De server reageert dan op het verzoek door het account van de gebruiker te wijzigen, de sessiestatus te veranderen, of de gevraagde gegevens terug te sturen.

Laten we twee voorbeelden van CSRF aanvallen nader bekijken, de ene met een GET verzoek en de andere met een POST verzoek.

CSRF voor een GET verzoek

Denk eerst aan een GET verzoek dat gebruikt wordt door een financiële bankapplicatie, waarbij de aanval gebruik maakt van een GET verzoek en levering van een hyperlink.

Stel dat het GET verzoek om geld over te maken er ongeveer zo uitziet:

GET https://xymbank.com/online/transfer?amount=1000&accountNumber=547895 HTTP/1.1

In het echte verzoek hierboven verzoekt de gebruiker 1000 dollar over te maken naar een rekening bij 547895 als betaling voor gekochte producten.

Hoewel dit verzoek expliciet, eenvoudig en praktisch is, stelt het de rekeninghouder bloot aan een CSRF aanval. Dat komt omdat het verzoek geen details vereist die een aanvaller misschien niet kent. Om een aanval uit te voeren hoeft een aanvaller dus alleen maar de parameters van dit verzoek (het bedrag en het rekeningnummer) te veranderen om een uitvoerbaar vals verzoek te creëren.

Het kwaadaardige verzoek zou effectief zijn voor alle gebruikers van de bank, zolang ze door cookies beheerde sessies hebben.

Dit is hoe het valse verzoek om $500 over te maken naar de rekening van een hacker (hier nummer 654585) eruit zou zien. Merk op dat het onderstaande voorbeeld een sterk vereenvoudigde versie is van de stappen die bij een CSRF aanval komen kijken, om het beter uit te kunnen leggen.

GET https://xymbank.com/online/transfer?amount=500&accountNumber=654585 HTTP/1.1

Als dat klaar is, moet de aanvaller een manier bedenken om de gebruiker te misleiden om dit verzoek te versturen terwijl hij is ingelogd in zijn online bankierenapplicatie. Een van de manieren om dit te doen is het maken van een onschadelijke hyperlink die de aandacht van de gebruiker trekt. De link kan er als volgt uitzien:

<a
href="https://xymbank.com/online/transfer?amount=500&accountNumber=654585">Click here to get more information</a>.

Aangezien de aanvaller de juiste e-mailadressen van hun doelwitten heeft gevonden, kunnen ze dit via e-mail naar veel bankklanten sturen. Degenen die op de link klikken terwijl ze ingelogd zijn, zouden het verzoek triggeren om de aanvaller $500 van de ingelogde rekening te sturen.

CSRF voor een POST verzoek

Laten we eens kijken hoe dezelfde financiële instelling een CSRF zou ervaren als ze alleen POST verzoeken zouden accepteren. In dit geval zou de hyperlink levering die in het GET verzoek voorbeeld werd gebruikt niet werken. Voor een succesvolle CSRF aanval zou een aanvaller dus een HTML formulier moeten maken. Het echte verzoek om $1.000 te sturen voor een gekocht product zou er als volgt uitzien:

POST /online/transfer HTTP/1.1
Host: xymbank.com
Content-Type: application/x-www-form-urlencoded
Cookie: session=FRyhityeQkAPzeQ5gHgTvlyxHJYhg
amount=1000
account=547895

Dit POST verzoek vereist een cookie om de identiteit van de gebruiker te bepalen, het bedrag dat ze willen sturen, en de rekening die ze willen sturen. Aanvallers kunnen dit verzoek wijzigen om een CSRF aanval uit te voeren.

De aanvaller hoeft alleen maar een echte cookie toe te voegen aan een vervalst verzoek om de server de overdracht te laten verwerken. Dat kunnen ze doen door een onschuldig ogende hyperlink te maken die de gebruiker naar een trigger webpagina brengt die er zo uitziet:

<html>
<body>
<form action="https://xymbank.com/online/transfer" method="POST">
<input type="hidden" name="amount" value="500"/>
<input type="hidden" name="account" value="654585" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>

We hebben het bedrag en de rekeningparameters al ingesteld in het formulier hierboven. Zodra een geauthenticeerde gebruiker de pagina bezoekt, voegt de browser de sessiecookie toe voordat hij het verzoek doorstuurt naar de server. De server stuurt vervolgens $500 door naar de rekening van de hacker.

3 manieren om CSRF aanvallen tegen te gaan

Er zijn verschillende methoden om potentiële CSRF aanvallen op je website of webapplicatie te voorkomen en drastisch te beperken, waaronder:

  • Het gebruik van CSRF tokens
  • Het gebruik van de referrer header
  • Een op beveiliging gerichte hostingoplossing kiezen, zoals Kinsta

Zo voorkom je CSRF aanvallen met behulp van CSRF tokens

Een website die tegen CSRF beveiligd is, wijst bij elke sessie een uniek token toe en deelt dat met de server en de clientbrowser. Wanneer een browser een gevoelig verzoek verstuurt, verwacht de server dat dit het toegewezen CSRF token bevat. Als het een verkeerd token bevat, laat de server het vallen. Het CSRF token wordt om veiligheidsredenen niet opgeslagen in sessiecookies op de browser van de client.

Mogelijke kwetsbaarheden van CSRF tokens

Hoewel CSRF tokens een uitstekende beveiligingsmaatregel zijn, is deze methode niet aanvalsbestendig. Enkele van de kwetsbaarheden die bij CSRF tokens horen zijn:

  • Validatie omzeilen – Sommige applicaties slaan de verificatiestap over als ze geen token vinden. Als een aanvaller toegang krijgt tot code die een token bevat, kan hij dat token verwijderen en met succes een CSRF aanval uitvoeren. Bijvoorbeeld als een geldig verzoek aan een server dat er zo uitziet:
POST /change_password
POST body:
password=pass123&csrf_token=93j9d8eckke20d433

Een aanvaller hoeft alleen het token te verwijderen en het zo te versturen om de aanval uit te voeren:

POST /change_password
POST body:
password=pass123
  • Gepoolde tokens – Sommige applicaties houden een pool van tokens aan om gebruikerssessies te valideren in plaats van een specifiek token aan een sessie toe te wijzen. Een aanvaller hoeft slechts een van de tokens te bemachtigen die al in de pool zitten om zich voor te doen als een van de gebruikers van de site.

Een aanvaller kan inloggen op een applicatie met zijn account om een token te verkrijgen, zoals:

[application_url].com?csrf_token=93j9d8eckke20d433

En omdat de tokens gepoold zijn, kan de aanvaller datzelfde token kopiëren en gebruiken om in te loggen op een account van een andere gebruiker:

  • CSRF’s kunnen token kopiëren naar de cookie – Sommige applicaties kopiëren de parameters met betrekking tot een token naar de cookie van een gebruiker. Als een aanvaller toegang krijgt tot zo’n cookie, kan hij gemakkelijk een andere cookie maken, die in een browser plaatsen, en een CSRF aanval uitvoeren.

Een aanvaller kan dus inloggen op een applicatie met zijn account en het cookiebestand openen om het volgende te zien:

Csrf_token:93j9d8eckke20d433

Vervolgens kunnen ze deze informatie gebruiken om nog een cookie aan te maken om de aanval te voltooien

  • Ongeldige tokens – Sommige applicaties koppelen CSRF tokens niet aan een gebruikerssessie. In zulke gevallen kan een aanvaller echt inloggen in een sessie, een CSRF token verkrijgen zoals hierboven, en die gebruiken om een CSRF aanval uit te voeren op de sessie van een slachtoffer.

Zo voorkom je CSRF aanvallen met de referrer header

Een andere strategie om CSRF aanvallen te voorkomen is het gebruik van de referrer header. In HTTP geven referrer headers de herkomst van verzoeken aan. Ze worden meestal gebruikt voor analyse, optimalisatie en logging.

Je kunt ook het controleren van referrer headers aan de serverzijde inschakelen om CSRF aanvallen te voorkomen. De server controleert de bronherkomst van het verzoek en bepaalt de doelherkomst van het verzoek. Komen ze overeen, dan is het verzoek toegestaan. Is er een mismatch, dan laat de server het verzoek vallen.

Het gebruik van referrer headers is veel eenvoudiger dan het gebruik van tokens, omdat er geen individuele gebruikersidentificatie nodig is.

Mogelijke kwetsbaarheden van de referrer header

Net als CSRF tokens hebben referrer headers enkele belangrijke kwetsbaarheden.

Ten eerste zijn referrer headers niet verplicht, en sommige sites sturen verzoeken zonder. Als de CSRF niet het beleid heeft om verzoeken zonder headers af te handelen, kunnen aanvallers verzoeken zonder header gebruiken om toestandsveranderende aanvallen uit te voeren.

Bovendien is deze methode minder effectief geworden met de recente invoering van het referrer beleid. Deze specificatie voorkomt dat URL’s naar andere domeinen lekken, en geeft gebruikers meer controle over de informatie in de referrer header. Ze kunnen ervoor kiezen een deel van de referrer header informatie openbaar te maken of uit te schakelen door een metadatatag op de HTML pagina toe te voegen, zoals hieronder getoond:

<meta name="referrer" content="no-referrer">

Bovenstaande code verwijdert de referrer header voor alle verzoeken van deze pagina. Door dit te doen wordt het moeilijk voor applicaties die vertrouwen op referrer headers om CSRF aanvallen vanaf zo’n pagina te voorkomen.

Zo beschermt Kinsta tegen CSRF aanvallen

Naast het gebruik van de referrer header en CSRF tokens is er nog een derde en veel eenvoudigere optie: het kiezen van een veilige hostingservice zoals Kinsta voor je websites en webapplicaties biedt een veel sterkere en veiligere barrière tussen aanvallers en je gebruikers.

Bovenop kritieke beveiligingsfeatures zoals automatische backups, twee-factorauthenticatie en SFTP over SSH protocollen, biedt Kinsta’s Cloudflare integratie bescherming op bedrijfsniveau met op IP gebaseerde en op firewalls gebaseerde bescherming.

Specifiek heeft Kinsta momenteel ongeveer 60 custom firewallregels om kwaadaardige aanvallen te helpen voorkomen en ernstige niet-geauthentiseerde kwetsbaarheden in plugins en thema’s aan te pakken, waaronder specifieke regels die zoeken naar CSRF kwetsbaarheden.

Samenvatting

Cross-site request forgery (CSRF) is een aanval waarbij geauthentiseerde gebruikers onbedoeld toestandsveranderende verzoeken initiëren. Ze zijn gericht op applicaties die geen onderscheid kunnen maken tussen geldige en vervalste verzoeken.

CSRF kan alleen succesvol zijn op applicaties die vertrouwen op sessiecookies om ingelogde gebruikers te identificeren en een zwak SameSite cookiebeleid hebben. Ze hebben ook een server nodig die verzoeken accepteert die geen onbekende parameters zoals wachtwoorden bevatten. Hackers kunnen kwaadaardige aanvallen versturen via GET of POST.

Hoewel het gebruik van CSRF tokens of het afdwingen van referrer headerverificatie sommige CSRF aanvallen kan voorkomen, hebben beide maatregelen potentiële kwetsbaarheden die je preventieve maatregelen nutteloos kunnen maken als je niet oppast.

Migreren naar een veilig hostingplatform zoals Kinsta beveiligt je websites of webapps tegen CSRF aanvallen. Bovendien voorkomt Kinsta’s integratie met Cloudflare specifieke CSRF aanvallen.

Salman Ravoof

Salman Ravoof is een autodidactische webdeveloper, schrijver, creator en een groot bewonderaar van Free and Open Source Software (FOSS). Naast techniek is hij enthousiast over wetenschap, filosofie, fotografie, kunst, katten en eten. Lees meer over hem op zijn website en kom in contact met Salman op X.