Cross-Site Request Forgery (CSRF)

Cross-Site Request Forgery (CSRF) — po polsku „fałszowanie żądań między witrynami”, znane też jako XSRF lub session riding — to podatność aplikacji internetowych. Pozwala napastnikowi sprawić, że zalogowany użytkownik nieświadomie wykona jakąś operację: zmieni hasło, zrobi przelew, nada komuś uprawnienia. Sztuczka opiera się na tym, że przeglądarka do każdego żądania automatycznie dokłada ciasteczko sesyjne ofiary. Serwer widzi ważną sesję i wykonuje polecenie, bo ufa zalogowanemu użytkownikowi — nie sprawdza, czy żądanie naprawdę wyszło z jego własnej strony.

Kiedy atak CSRF jest w ogóle możliwy?

Według klasyfikacji firmy PortSwigger muszą zaistnieć jednocześnie trzy warunki:

• Jest ważna akcja do wykonania. W aplikacji istnieje operacja, na której napastnikowi zależy — zmiana e-maila, zmiana hasła, przelew, nadanie uprawnień.
• Sesja opiera się tylko na ciasteczku. Aplikacja rozpoznaje użytkownika wyłącznie po ciasteczku sesyjnym, które przeglądarka wysyła sama. W żądaniu nie ma żadnego dodatkowego, trudnego do zgadnięcia sekretu.
• Wszystkie parametry żądania da się przewidzieć. Napastnik zna lub potrafi odgadnąć każdą potrzebną wartość. W żądaniu nie ma nic nieprzewidywalnego, np. tokenu CSRF ani bieżącego hasła.

Jak działa atak CSRF?

Serwer ufa zalogowanej sesji ofiary — a właściwie jej przeglądarce. CSRF nadużywa tego zaufania. Typowy przebieg wygląda tak:

1. Ofiara jest zalogowana w jakiejś aplikacji i ma w przeglądarce ważne ciasteczko sesyjne.
2. Napastnik przygotowuje stronę z ukrytym żądaniem do tej aplikacji — na przykład formularz, który sam się wysyła przez JavaScript, albo znacznik <img> wskazujący na podatny adres.
3. Ofiara — wciąż zalogowana — wchodzi na tę stronę. Trafia tam z linku w e-mailu, posta na forum albo reklamy.
4. Przeglądarka wysyła żądanie do aplikacji i — jak zwykle — sama dokłada ciasteczko sesyjne ofiary.
5. Serwer widzi prawidłową sesję i wykonuje operację, jakby zlecił ją świadomie sam użytkownik.

Ważny szczegół: napastnik nie widzi odpowiedzi serwera — blokuje to reguła same-origin policy (zasada tego samego źródła). CSRF służy więc do wywołania akcji, a nie do podejrzenia danych. Atak działa „na ślepo” i tym różni się od kradzieży informacji.

CSRF przez GET czy POST?

Sposób podrzucenia żądania zależy od tego, jaką metodę przyjmuje podatny adres:

• GET — najłatwiejszy do wykorzystania. Wystarczy znacznik <img src="https://bank.example/transfer?to=attacker&amount=1000">. Przeglądarka próbuje pobrać „obrazek” i przy okazji wysyła żądanie razem z ciasteczkami. Operacje zmieniające dane nigdy nie powinny być dostępne przez GET.
• POST — wymaga automatycznego wysłania ukrytego formularza, zwykle JavaScriptem. Samo POST nie chroni przed CSRF — to częsty mit.

Osobnym wariantem jest Login CSRF. Tu napastnik wymusza zalogowanie ofiary na swoje konto, żeby później podejrzeć to, co ofiara tam wpisze — np. historię czy zapisaną kartę.

Czym grozi udany atak CSRF?

• Zmianą e-maila lub hasła, a w efekcie przejęciem konta.
• Nieautoryzowanym przelewem lub inną transakcją.
• Zmianą uprawnień, usunięciem konta, zmianą ustawień bezpieczeństwa.
• Przejęciem kontroli nad całą aplikacją, gdy ofiarą jest administrator — jedno żądanie potrafi zmienić jej konfigurację.

Czym CSRF różni się od XSS?

To dwie różne podatności, które łatwo pomylić:

• XSS (Cross-Site Scripting) wstrzykuje i uruchamia obcy skrypt na zaufanej stronie. Daje napastnikowi kontrolę nad zachowaniem strony i pozwala czytać dane — w tym tokeny CSRF.
• CSRF nie uruchamia żadnego kodu i nie czyta odpowiedzi. Tylko wymusza wysłanie sfałszowanego żądania w już istniejącej sesji.

Ta różnica jest ważna dla obrony: XSS pokonuje każde zabezpieczenie anty-CSRF. Skrypt działający po stronie ofiary może odczytać token i wysłać prawidłowe żądanie. Dlatego usunięcie podatności XSS jest warunkiem, żeby ochrona przed CSRF w ogóle miała sens.

Jak zapobiegać atakom CSRF?

Podstawowa zasada: każde żądanie zmieniające dane trzeba powiązać z sekretem, którego strona napastnika nie zna i nie potrafi dołączyć. Poniższe metody opisuje OWASP w dokumencie CSRF Prevention Cheat Sheet.

Token CSRF (Synchronizer Token Pattern)

Najczęstsza metoda dla aplikacji, które trzymają stan sesji po swojej stronie. Serwer losuje unikalny, kryptograficznie silny token (dla całej sesji albo dla pojedynczego żądania), zapisuje go u siebie i umieszcza w ukrytym polu formularza lub w nagłówku. Token nie jest zwykłym ciasteczkiem, a serwer odrzuca żądania bez poprawnej wartości. Strona napastnika nie odczyta tego tokenu — znów blokuje to same-origin policy — więc nie zbuduje prawidłowego żądania.

Double Submit Cookie (dla aplikacji bez stanu)

• Wariant prosty — ta sama losowa wartość trafia jednocześnie do ciasteczka i do parametru żądania, a serwer porównuje obie. Napastnik nie odczyta cudzego ciasteczka, więc nie powtórzy go w parametrze.
• Wariant podpisany (HMAC) — zalecany — token jest kryptograficznie związany z sesją. Chroni to przed podrzuceniem ciasteczka z subdomeny lub innego, słabiej odizolowanego miejsca.

Własne nagłówki żądań

Dobre dla interfejsów programistycznych (API) oraz żądań AJAX/XHR wysyłanych w tle. Klient dokłada własny nagłówek, np. X-CSRF-Token albo X-Requested-With. Dodanie takiego nagłówka między witrynami wymusza dodatkowe zapytanie sprawdzające (preflight CORS), którego prosta strona napastnika nie przejdzie. Nie trzeba przy tym przechowywać tokenu po stronie serwera.

Ciasteczka SameSite

Atrybut SameSite decyduje, czy ciasteczko dołącza się do żądań pochodzących z innej witryny:

• Strict — ciasteczko nie jest wysyłane przy żadnym żądaniu z innej witryny.
• Lax — domyślny w nowoczesnych przeglądarkach (w Chrome od 2021). Ciasteczko leci tylko przy zwykłym wejściu na stronę bezpieczną metodą (GET).
• None — ciasteczko wysyłane zawsze, ale wymaga atrybutu Secure.

SameSite to warstwa dodatkowa (defense-in-depth), a nie samodzielne rozwiązanie. Nie ochroni przed zmianami przez GET ani przed atakiem z tej samej witryny, np. z subdomeny. Trzeba ją łączyć z tokenem CSRF.

Sprawdzanie nagłówków Origin / Referer i Fetch Metadata

Serwer może porównywać nagłówki Origin i Referer z własnym adresem albo sprawdzać Sec-Fetch-Site i dla operacji zmieniających dane odrzucać wartość cross-site. Te nagłówki bywają jednak pomijane — przy przekierowaniach lub niektórych ustawieniach prywatności — więc traktuje się je jako kontrolę uzupełniającą, nie podstawową.

Dlaczego CSRF jest ważny dla monitorowania i wykrywania?

CSRF to atak na warstwę aplikacji, uruchamiany z przeglądarki ofiary. Samo żądanie wygląda jak zwykły ruch zalogowanego użytkownika — nie ma w nim sygnatury exploita ani widocznej anomalii na poziomie pakietów. Z perspektywy zespołu bezpieczeństwa (SOC) liczą się więc sygnały pośrednie i powiązania między zdarzeniami:

• Operacje zmieniające dane (zmiana e-maila, hasła, przelew), w których nagłówek Referer/Origin wskazuje obcą witrynę albo brakuje oczekiwanego tokenu.
• Nietypowe sekwencje żądań — wrażliwa akcja bez wcześniejszego pobrania formularza, który normalnie dostarcza token.
• Nagły wzrost ruchu na konkretne adresy zmieniające dane, zbieżny z wizytami na zewnętrznych domenach (dane z proxy, logów WAF i serwera aplikacji, telemetrii NetFlow/IPFIX).
• Działania niespójne w czasie lub geograficznie w obrębie jednej sesji.

Logi serwera aplikacji, logi WAF i telemetria sieciowa pozwalają wychwycić masowe lub powtarzalne próby CSRF, ustalić zasięg incydentu po fakcie i odróżnić sfałszowane żądania od zwykłej aktywności. To uzupełnia obronę wbudowaną w samą aplikację.

Dowiedz się więcej

• Podatność IDOR – jak wykryć atak na aplikacje webowe przez analizę ruchu HTTP — IDOR i CSRF to różne luki w aplikacjach webowych, często analizowane wspólnie w kontekście nadużyć HTTP.
• OWASP Top 10 — CSRF należy do klasycznych zagrożeń uwzględnianych w zestawieniach OWASP dla aplikacji webowych.
• Application Layer Attack (L7) — CSRF jest atakiem warstwy aplikacji, bo wykorzystuje logikę HTTP i sesję użytkownika.