Wat is CSRF en hoe bescherm je je applicatie?
Auteur: Redactie Domeny.ForSale Gepubliceerd
In het kort: CSRF is een aanval waarbij een externe website de browser van een ingelogde gebruiker ertoe aanzet een ongewenst verzoek naar een andere website te sturen. Als die website alleen controleert of de gebruiker is ingelogd, kan ze een handeling uitvoeren zonder dat de gebruiker daar bewust toestemming voor heeft gegeven. De basis van de bescherming ligt in de applicatie: CSRF-tokens, juiste cookie-instellingen en controle van de herkomst van verzoeken.
Hoe werkt CSRF? Een voorbeeld met een webshopbeheeromgeving
CSRF staat voor Cross-Site Request Forgery: het vervalsen van verzoeken tussen websites. De aanval maakt gebruik van het feit dat de browser automatisch een sessiecookie kan meesturen met verzoeken aan een bepaalde website. Met zo’n cookie kan de server een ingelogde gebruiker herkennen zonder opnieuw om een wachtwoord te vragen.
Stel dat je een webshop beheert en de beheeromgeving open hebt staan. In een tweede tabblad bezoek je een pagina die door een aanvaller is gemaakt. Die pagina probeert een verzoek naar de beheeromgeving te sturen om het e-mailadres van je account te wijzigen.
Als de browser de sessiecookie meestuurt en de beheeromgeving niet ook de echtheid van het verzoek controleert, kan de server het verzoek als jouw keuze beschouwen. De aanvaller hoeft je wachtwoord niet te kennen of de cookie uit te lezen: het is voldoende dat de browser de cookie gebruikt bij het versturen van het verzoek.
Het is alsof iemand een opdracht ter uitvoering aanbiedt waar automatisch jouw stempel op is gezet. Het systeem herkent de stempel, maar controleert niet of je die specifieke handeling daadwerkelijk wilt uitvoeren.
Wanneer kan de aanval slagen en wat houdt hem niet tegen?
Een typische CSRF-aanval vereist enkele voorwaarden: de gebruiker heeft een actieve sessie, de browser stuurt automatisch authenticatiegegevens mee en de applicatie accepteert een voorspelbaar verzoek dat de toestand van het account wijzigt. Dat kan gaan om het wijzigen van gegevens, het toevoegen van een gebruiker of het verwijderen van een bericht. De gevolgen hangen af van de beschikbare handelingen en de rechten van het slachtoffer.
De aanvaller hoeft het antwoord van de server meestal niet te kunnen lezen. De browser kan een externe website verbieden gegevens uit de beheeromgeving te lezen, terwijl het versturen van bepaalde verzoeken nog wel mogelijk is. Daarom vervangt het same-originbeleid, dat de toegang van scripts tot bronnen van andere websites beperkt, geen bescherming tegen CSRF.
Ook HTTPS lost dit probleem niet op. Het versleutelt de verbinding en beschermt gegevens onderweg, maar bevestigt niet dat de gebruiker bewust opdracht heeft gegeven voor de handeling. Alleen POST gebruiken in plaats van GET is evenmin voldoende: een externe website kan een gewoon POST-formulier versturen.
CSRF is niet hetzelfde als XSS. Bij XSS wordt ongewenste code uitgevoerd binnen de context van een vertrouwde website. CSRF maakt daarentegen misbruik van het vertrouwen dat een website stelt in verzoeken uit de browser van de gebruiker. Een XSS-kwetsbaarheid kan de bescherming tegen CSRF wel ondermijnen, bijvoorbeeld doordat de aanvaller een token kan uitlezen.
Hoe bescherm je een applicatie tegen CSRF?
Het veiligste uitgangspunt is de ingebouwde bescherming van het framework dat je gebruikt. Schakel die in en controleer of ze alle handelingen omvat die gegevens wijzigen, niet alleen het inlogformulier.
- Controleer het CSRF-token. Dit is een onvoorspelbare waarde die de applicatie in een formulier opneemt of meegeeft om in de juiste header te versturen. De server controleert die waarde voordat hij de handeling uitvoert. In een veelgebruikte variant is het token gekoppeld aan de sessie; een externe website mag het niet kunnen uitlezen of raden. Het token mag niet in de URL terechtkomen.
- Stel het SameSite-attribuut van de sessiecookie in. Dit beperkt het meesturen van de cookie bij verzoeken tussen websites. De varianten Lax en Strict bieden verschillende niveaus van beperking. Test daarom of je keuze goed werkt met inloggen en integraties. SameSite is een extra beschermingslaag, geen vervanging die het token onder alle omstandigheden overbodig maakt.
- Controleer de herkomst van het verzoek. De header Origin, en bij een goed ontworpen controlemechanisme ook Referer, helpt vast te stellen waar het verzoek vandaan komt. Vergelijk de herkomst met exact vastgelegde toegestane adressen, in plaats van alleen te zoeken naar een deel van de domeinnaam.
- Wijzig geen gegevens via GET. Het openen van een link mag geen account verwijderen of bestelling bevestigen. Handelingen die gegevens wijzigen, moeten de juiste methoden gebruiken en nog steeds op CSRF worden gecontroleerd.
Voeg voor bijzonder gevoelige handelingen hernieuwde authenticatie of een aparte bevestiging toe. Sessiecookies moeten ook de juiste attributen Secure en HttpOnly hebben, al voorkomt geen van beide op zichzelf CSRF.
Heeft een API ook bescherming nodig?
Een API, een interface waarmee programma’s met elkaar communiceren, kan eveneens kwetsbaar zijn voor CSRF als de authenticatie van de sessie via een cookie verloopt. Alleen een antwoord in JSON-formaat biedt geen veiligheid.
Als de client expliciet een toegangstoken toevoegt aan de header Authorization en de browser dat token niet automatisch meestuurt, is het gebruikelijke CSRF-mechanisme doorgaans niet van toepassing. Dat betekent echter niet dat de applicatie bestand is tegen tokendiefstal of XSS. Ook CORS, het mechanisme dat toegang tussen verschillende origins regelt, is op zichzelf geen bescherming tegen CSRF.
Wat controleer je op je eigen website?
Begin met één handeling, bijvoorbeeld het wijzigen van een e-mailadres. Controleer met een testaccount, in je eigen omgeving of met toestemming van de eigenaar, of een verzoek zonder CSRF-token of met een ongeldig token wordt geweigerd en daadwerkelijk geen gegevens wijzigt. Controleer daarna de cookie-instellingen en de overige routes waarmee dezelfde handeling kan worden uitgevoerd.
Gebruik je een kant-en-klaar systeem, ga dan in de officiële documentatie van jouw versie en de geïnstalleerde uitbreidingen na hoe de bescherming werkt. Als gebruiker kun je ontbrekende beveiliging op de server niet verhelpen. Je kunt het risico wel beperken door uit te loggen nadat je in een gevoelige beheeromgeving hebt gewerkt. Begin als eigenaar van een applicatie met het nalopen van alle handelingen die gegevens wijzigen: daarbij moet worden gecontroleerd of het verzoek daadwerkelijk afkomstig is van een interface die deze handeling mag uitvoeren.
Zie ook: Wat betekent www?
Lees ook
