Wpływ
Cross-Site Request Forgery (CSRF) umożliwia atakującemu oszukanie przeglądarki ofiary w celu wykonania niepożądanych działań w innej witrynie internetowej, w której ofiara jest aktualnie uwierzytelniona. Ponieważ przeglądarki automatycznie dołączają do żądań poświadczenia otoczenia, takie jak pliki cookie, osoba atakująca może sfałszować operacje zmieniające stan — takie jak zmiana hasła, usuwanie danych lub inicjowanie transakcji — bez wiedzy użytkownika.
Główna przyczyna
Podstawową przyczyną CSRF jest domyślne zachowanie przeglądarki internetowej polegające na wysyłaniu plików cookie powiązanych z domeną za każdym razem, gdy do tej domeny wysyłane jest żądanie, niezależnie od pochodzenia żądania [S1]. Bez szczegółowego sprawdzenia, czy żądanie zostało celowo wywołane z interfejsu użytkownika aplikacji, serwer nie jest w stanie odróżnić uzasadnionego działania użytkownika od sfałszowanego.
Mechanizmy ochrony Django CSRF
Django zapewnia wbudowany system obrony, który minimalizuje te zagrożenia poprzez integrację oprogramowania pośredniego i szablonów [S2].
Aktywacja oprogramowania pośredniego
django.middleware.csrf.CsrfViewMiddleware jest odpowiedzialny za ochronę CSRF i zazwyczaj jest domyślnie włączony [S2]. Należy go umieścić przed jakimkolwiek oprogramowaniem pośredniczącym widoku, które zakłada, że ataki CSRF zostały już obsłużone. [S2].
Implementacja szablonu
W przypadku wszelkich wewnętrznych formularzy POST programiści muszą umieścić znacznik {% csrf_token %} w elemencie <form> [S2]. Dzięki temu żądanie zawiera unikalny, tajny token, który następnie serwer sprawdza w odniesieniu do sesji użytkownika.
Ryzyko wycieku tokenu
Krytycznym szczegółem implementacji jest to, że {% csrf_token %} nigdy nie powinien być uwzględniany w formularzach kierowanych na zewnętrzne adresy URL [S2]. Spowodowałoby to wyciek tajnego tokena CSRF stronie trzeciej, potencjalnie narażając bezpieczeństwo sesji użytkownika [S2].
Ochrona na poziomie przeglądarki: pliki cookie SameSite
Nowoczesne przeglądarki wprowadziły atrybut SameSite dla nagłówka Set-Cookie, aby zapewnić warstwę dogłębnej ochrony [S1].
- Ścisłe: Plik cookie jest wysyłany wyłącznie w kontekście własnym, co oznacza, że witryna w pasku adresu URL odpowiada domenie pliku cookie [S1].
- Lax: Plik cookie nie jest wysyłany w ramach żądań podrzędnych między witrynami (takich jak obrazy lub ramki), ale jest wysyłany, gdy użytkownik przejdzie do witryny źródłowej, na przykład klikając standardowy link [S1].
Jak FixVibe to testuje
FixVibe zawiera teraz ochronę CSRF jako aktywną kontrolę bramkową. Po weryfikacji domeny active.csrf-protection sprawdza wykryte formularze zmieniające stan, sprawdza dane wejściowe w kształcie tokena CSRF i sygnały plików cookie SameSite, a następnie podejmuje próbę przesłania fałszywego pochodzenia o niewielkim wpływie i raportuje tylko wtedy, gdy serwer to zaakceptuje. Sprawdzanie plików cookie oznacza również słabe atrybuty SameSite, które zmniejszają głębokość obrony przed CSRF.