Impact
Met Cross-Site Request Forgery (CSRF) kan een aanvaller de browser van een slachtoffer misleiden zodat hij ongewenste acties uitvoert op een andere website waarop het slachtoffer momenteel is geverifieerd. Omdat browsers automatisch omgevingsreferenties zoals cookies in verzoeken opnemen, kan een aanvaller statusveranderende handelingen uitvoeren, zoals het wijzigen van wachtwoorden, het verwijderen van gegevens of het initiëren van transacties, zonder medeweten van de gebruiker.
Oorzaak
De fundamentele oorzaak van CSRF is het standaardgedrag van de webbrowser, waarbij cookies worden verzonden die aan een domein zijn gekoppeld wanneer er een verzoek aan dat domein wordt gedaan, ongeacht de oorsprong van het verzoek. Zonder specifieke validatie dat een verzoek opzettelijk is geactiveerd vanuit de eigen gebruikersinterface van de applicatie, kan de server geen onderscheid maken tussen een legitieme gebruikersactie en een vervalste.
Django CSRF-beschermingsmechanismen
Django biedt een ingebouwd verdedigingssysteem om deze risico's te beperken via middleware en sjabloonintegratie [S2].
Middleware-activering
De django.middleware.csrf.CsrfViewMiddleware is verantwoordelijk voor CSRF-beveiliging en wordt doorgaans standaard ingeschakeld bij [S2]. Het moet vóór elke view-middleware worden geplaatst die ervan uitgaat dat CSRF-aanvallen al zijn afgehandeld [S2].
Sjabloonimplementatie
Voor alle interne POST-formulieren moeten ontwikkelaars de tag {% csrf_token %} opnemen in het <form>-element [S2]. Dit zorgt ervoor dat er een uniek, geheim token in het verzoek wordt opgenomen, dat de server vervolgens valideert aan de hand van de sessie van de gebruiker.
Risico's op tokenlekkage
Een cruciaal implementatiedetail is dat de {% csrf_token %} nooit mag worden opgenomen in formulieren die zijn gericht op de externe URL's [S2]. Als u dit wel doet, zou het geheime CSRF-token naar een derde partij lekken, waardoor de sessiebeveiliging [S2] van de gebruiker mogelijk in gevaar komt.
Bescherming op browserniveau: SameSite-cookies
Moderne browsers hebben het SameSite-attribuut voor de Set-Cookie-header geïntroduceerd om een laag van diepgaande verdediging [S1] te bieden.
- Strikt: De cookie wordt alleen verzonden in een first-party context, wat betekent dat de site in de URL-balk overeenkomt met het domein [S1] van de cookie.
- Lax: De cookie wordt niet verzonden bij cross-site subverzoeken (zoals afbeeldingen of frames), maar wordt verzonden wanneer een gebruiker naar de oorspronkelijke site navigeert, bijvoorbeeld door een standaardlink [S1] te volgen.
Hoe FixVibe erop test
FixVibe bevat nu CSRF-bescherming als een gated actieve controle. Na domeinverificatie inspecteert active.csrf-protection ontdekte statusveranderende formulieren, controleert op CSRF-tokenvormige invoer en SameSite-cookiesignalen, probeert vervolgens een inzending van vervalste oorsprong met weinig impact en rapporteert alleen wanneer de server deze accepteert. Cookiecontroles signaleren ook zwakke SameSite-kenmerken die de diepgaande CSRF-verdediging verminderen.