Inverkan
Cross-Site Request Forgery (CSRF) tillåter en angripare att lura ett offers webbläsare att utföra oönskade åtgärder på en annan webbplats där offret för närvarande är autentiserat. Eftersom webbläsare automatiskt inkluderar omgivande autentiseringsuppgifter som cookies i förfrågningar, kan en angripare förfalska tillståndsförändrande operationer – som att ändra lösenord, ta bort data eller initiera transaktioner – utan användarens vetskap.
Rotorsak
Den grundläggande orsaken till CSRF är webbläsarens standardbeteende att skicka cookies associerade med en domän när en begäran görs till den domänen, oavsett begärans ursprung [S1]. Utan specifik validering av att en begäran avsiktligt utlöstes från programmets eget användargränssnitt kan servern inte skilja mellan en legitim användaråtgärd och en förfalskad.
Django CSRF-skyddsmekanismer
Django tillhandahåller ett inbyggt försvarssystem för att mildra dessa risker genom middleware och mallintegrering [S2].
Middleware-aktivering
django.middleware.csrf.CsrfViewMiddleware är ansvarig för CSRF-skydd och är vanligtvis aktiverat som standard [S2]. Den måste placeras innan någon vymellanvara som antar att CSRF-attacker redan har hanterats [S2].
Mallimplementering
För alla interna POST-formulär måste utvecklare inkludera {% csrf_token %}-taggen inuti <form>-elementet [S2]. Detta säkerställer att en unik, hemlig token ingår i begäran, som servern sedan validerar mot användarens session.
Tokenläckagerisker
En viktig implementeringsdetalj är att {% csrf_token %} aldrig ska inkluderas i formulär som är inriktade på externa webbadresser [S2]. Om du gör det skulle den hemliga CSRF-token läcka till en tredje part, vilket potentiellt äventyrar användarens sessionssäkerhet [S2].
Försvar på webbläsarnivå: SameSite-cookies
Moderna webbläsare har introducerat SameSite-attributet för Set-Cookie-huvudet för att tillhandahålla ett lager av försvar på djupet [S1].
- Strikt: Cookien skickas endast i ett förstapartssammanhang, vilket innebär att webbplatsen i URL-fältet matchar cookiens domän [S1].
- Lax: Cookien skickas inte på underförfrågningar mellan webbplatser (som bilder eller ramar) utan skickas när en användare navigerar till ursprungswebbplatsen, till exempel genom att följa en standardlänk [S1].
Hur FixVibe testar det
FixVibe inkluderar nu CSRF-skydd som en gated aktiv kontroll. Efter domänverifiering inspekterar active.csrf-protection upptäckta tillståndsförändrande formulär, kontrollerar CSRF-tokenformade ingångar och SameSite-cookiesignaler, försöker sedan en inskickad inlämning av falskt ursprung och rapporterar bara när servern accepterar det. Cookiekontroller flaggar också svaga SameSite-attribut som minskar CSRF-försvaret på djupet.