CSRF wykorzystuje wygodę przeglądarki: automatyczne wysyłanie twoich poświadczeń
W klasycznym CSRF napastnik nie musi znać hasła ani nawet odczytać ciasteczka sesyjnego ofiary. Wystarczy, że przeglądarka zalogowanego użytkownika zostanie nakłoniona do wysłania żądania do innej strony, a mechanizmy przeglądarki automatycznie dołączą odpowiednie ciasteczka sesyjne. OWASP opisuje dokładnie ten mechanizm: jeśli serwis nie odróżnia legalnego żądania od żądania wywołanego z obcej strony, może wykonać operację z uprawnieniami ofiary. To przewrotna podatność, bo atak wykorzystuje funkcję zaprojektowaną dla wygody — przeglądarka „pamięta”, że użytkownik jest zalogowany — i obraca ją przeciwko aplikacji.
Napastnik korzysta z sesji ofiary, a nie z własnych poświadczeń
Po zalogowaniu serwis zwykle wydaje przeglądarce token sesji w ciasteczku. Przy kolejnych żądaniach do tej domeny przeglądarka automatycznie dołącza cookie zgodnie z jego regułami. Dzięki temu użytkownik nie wpisuje hasła przy każdym kliknięciu. CSRF pojawia się wtedy, gdy zewnętrzna strona potrafi sprowokować żądanie zmieniające stan, a serwer uznaje samo obecne cookie za wystarczający dowód intencji użytkownika.
Same-origin policy nie rozwiązuje wszystkiego
Polityka tego samego pochodzenia utrudnia obcej stronie odczytywanie odpowiedzi z innej domeny, ale historycznie nie zabraniała wszystkich form wysyłania żądań. Formularze, obrazy i nawigacje mogą inicjować komunikację cross-site w określonych warunkach. Atakujący często nie potrzebuje odpowiedzi — wystarczy, że bank, panel administracyjny czy aplikacja wykona operację. Brak możliwości odczytu wyniku nie oznacza braku możliwości wywołania skutku.
Token CSRF dodaje informację, której przeglądarka nie wysyła automatycznie każdemu
Klasyczna obrona polega na wymaganiu dodatkowej wartości powiązanej z sesją, którą prawidłowa strona potrafi umieścić w formularzu lub nagłówku, ale obca strona nie może jej po prostu odczytać i odtworzyć. OWASP opisuje synchronizer token pattern oraz podpisane double-submit cookies. Kluczowa idea jest wspólna: serwer chce zobaczyć coś więcej niż poświadczenie dołączane automatycznie do żądania.
SameSite zmienił krajobraz, ale nie usuwa potrzeby rozumienia modelu
Współczesne ciasteczka mają atrybut SameSite, który ogranicza ich wysyłanie w kontekstach cross-site. Tryby Lax i Strict mogą blokować wiele klasycznych scenariuszy CSRF. OWASP traktuje jednak SameSite jako jedną z warstw obrony i omawia wyjątki, kompatybilność oraz potrzebę tokenów lub innych kontroli w zależności od architektury. To kolejny przykład, że bezpieczeństwo zależy od precyzyjnych reguł przeglądarki, a nie od jednego magicznego nagłówka.
CSRF pokazuje różnicę między uwierzytelnieniem a intencją
Cookie może prawidłowo powiedzieć „to jest sesja Alice”, ale nie odpowiada na pytanie „czy Alice chciała wykonać tę konkretną operację z tej konkretnej strony?”. Mechanizm uwierzytelnienia użytkownika został użyty w kontekście, którego serwer nie rozróżnił. Dlatego bezpieczeństwo transakcji wymaga czasem dodatkowego dowodu pochodzenia żądania lub świadomej interakcji. Uwierzytelnienie tożsamości nie jest automatycznie uwierzytelnieniem intencji.
Zmiana metody z GET na POST nie usuwa CSRF
Źródłem problemu nie jest sam adres URL ani to, czy parametry są widoczne w pasku przeglądarki. Formularz na obcej stronie może wysłać część żądań POST, a przeglądarka nadal może dołączyć do nich poświadczenia związane z celem. Dlatego operacje zmieniające stan powinny nie tylko używać właściwej semantyki HTTP, lecz także wymagać dowodu intencji, którego obca strona nie potrafi odtworzyć — np. tokenu CSRF — oraz korzystać z właściwości takich jak `SameSite` jako dodatkowej warstwy. OWASP podkreśla model obrony wielowarstwowej. CORS również nie jest prostym zamiennikiem, ponieważ część „prostych” żądań może zostać wysłana bez odczytywania odpowiedzi. CSRF pokazuje, że zakaz czytania odpowiedzi i zakaz wysłania żądania to dwie różne właściwości przeglądarki.
Token CSRF działa dlatego, że jest informacją związaną z właściwą sesją, której obca strona nie dostaje automatycznie
Przeglądarka może sama dołączyć cookie sesyjne do żądania, ale strona pochodząca z innej domeny nie powinna móc po prostu odczytać treści chronionej aplikacji i skopiować z niej losowego tokenu dzięki polityce same-origin. Aplikacja może więc wymagać jednocześnie automatycznego poświadczenia sesji oraz dodatkowej wartości umieszczanej w formularzu lub nagłówku przez własny kod. Atakujący potrafi sprowokować wysłanie części żądań, lecz nie zna tej drugiej wartości. To subtelne odwrócenie problemu: skoro cookie jest zbyt automatyczne, dokładamy element, który nie jest wysyłany automatycznie przez przeglądarkę w każdym cross-site request. SameSite dodatkowo ogranicza sytuacje, w których cookie podróżuje między kontekstami witryn.