Atak CSRF (Cross-Site Request Forgery) – na czym polega i jak się przed nim chronić?

Atak CSRF (Cross-Site Request Forgery) polega na zmuszeniu uwierzytelnionego użytkownika do nieświadomego wykonania niepożądanej akcji w aplikacji internetowej, w której jest obecnie zalogowany. Ochrona przed nim sprowadza się przede wszystkim do wdrożenia jednorazowych tokenów kryptograficznych anti-CSRF oraz restrykcyjnego oznaczania ciasteczek sesyjnych flagą SameSite. To jest brutalna i ostateczna definicja. Reszta to kwestia technicznego wdrożenia i zrozumienia luk w protokole HTTP.

Przeglądarki internetowe mają zaprogramowany mechanizm automatycznego dołączania ciasteczek (cookies) do każdego żądania wysyłanego do danej domeny. Serwer otrzymuje żądanie, widzi prawidłowe ciasteczko sesyjne i traktuje operację jako autoryzowaną. Atakujący wykorzystuje tę mechanikę. Tworzy spreparowaną stronę internetową, ukryty formularz lub złośliwy link. Ofiara wchodzi na stronę hakera, a jej przeglądarka posłusznie wysyła żądanie do banku, panelu administracyjnego czy sklepu. Serwer to akceptuje. Pieniądze znikają. Hasła zostają zmienione. Tak to wygląda od kuchni.

Jak dokładnie działa atak CSRF w praktyce i dlaczego przeglądarki na to pozwalają?

Cała podatność Cross-Site Request Forgery opiera się na zjawisku tak zwanego „ambient authority”. Przeglądarka internetowa po prostu wysyła poświadczenia bez pytania użytkownika o zgodę przy każdym wywołaniu sieciowym. Twórcy specyfikacji webowych zrobili to dla wygody. Nikt nie chciał logować się ponownie przy przechodzeniu na każdą kolejną podstronę serwisu. Wygoda zawsze generuje koszty w bezpieczeństwie aplikacji webowych.

Zbudujmy wektor ataku z perspektywy napastnika. Potrzebujemy dwóch rzeczy. Po pierwsze, ofiara musi posiadać aktywną sesję w docelowej aplikacji. Po drugie, aplikacja nie może używać żadnych mechanizmów weryfikacji intencji żądania. Atakujący przygotowuje kod HTML na swoim serwerze.

Wrzuca na stronę niewinnie wyglądający przycisk. Pod nim ukrywa formularz POST kierujący na adres https://bank.pl/przelew. Użytkownik klika. Formularz leci w tle. Przeglądarka dokleja ciasteczko sesyjne. Serwer banku przetwarza żądanie. Koniec. To proste. Skuteczność zależy wyłącznie od socjotechniki.

Wielu analityków twierdzi, że problem dotyczy tylko starych systemów. To błąd. Podatności tego typu znajdujemy na masową skalę w nowoczesnych aplikacjach, które źle implementują zarządzanie stanem. Aplikacja bez tokenów to otwarte drzwi. Zawsze.

Przykłady z życia i błędy deweloperów (Mój przypadek z wdrożenia)

Teoria z dokumentacji OWASP to jedno, ale realia rynkowe bywają dużo bardziej brutalne. Wdrażaliśmy panel administracyjny dla małej hurtowni sprzętu na warszawskim Targówku w połowie 2021 roku. System działał w sieci lokalnej, ale miał wystawiony interfejs na zewnątrz dla handlowców. Frontendowiec z zewnętrznej agencji poszedł na skróty.

Zostawił endpoint oparty o metodę GET do zmiany adresu e-mail pracownika. Tak, metoda GET do zmiany stanu. Ktoś z konkurencji wrzucił ukryty tag obrazka <img src=”http://hurtownia.pl/api/[email protected]”> na branżowe forum, z którego korzystali handlowcy. Jeden z pracowników wszedł na forum będąc zalogowanym w systemie hurtowni. Przeglądarka spróbowała pobrać „obrazek”. Wysłała żądanie GET. Dodała ciasteczko sesyjne. E-mail w systemie został podmieniony w ułamku sekundy. Musieliśmy łatać to w nocy z piątku na sobotę, blokując dostęp z zewnątrz i przepisując routing. Zmiana wszystkich krytycznych operacji na metodę POST to absolutna podstawa. Ale POST też nie rozwiązuje problemu, jeśli nie wdrożysz dodatkowych zabezpieczeń.

Jak się chronić przed atakiem CSRF po stronie serwera za pomocą tokenów?

Jedyną w pełni ugruntowaną metodą obrony jest wdrożenie tokenów synchronizujących (Synchronizer Token Pattern). Aplikacja musi wygenerować unikalny, losowy ciąg znaków po stronie serwera i powiązać go z sesją użytkownika. Serwer przekazuje ten token do przeglądarki, najczęściej osadzając go w ukrytym polu formularza HTML.

Gdy użytkownik klika „Zapisz” lub „Wyślij”, token wraca do serwera w ciele żądania (body). Serwer porównuje otrzymany ciąg z tym, który przechowuje w pamięci dla danej sesji. Zgadza się? Operacja przechodzi. Różni się lub go brakuje? Serwer odrzuca żądanie z błędem HTTP 403 Forbidden. Atakujący z obcej domeny nie ma możliwości odczytania tego tokenu, ponieważ blokuje go polityka Same-Origin Policy (SOP). SOP pozwala na wysłanie żądania, ale kategorycznie zabrania odczytu odpowiedzi przez skrypty z innej domeny.

Istnieje też alternatywne podejście znane jako Double Submit Cookie. Stosujemy je tam, gdzie utrzymywanie stanu po stronie serwera jest niemożliwe. Serwer generuje kryptograficznie bezpieczny token. Wysyła go do przeglądarki jako osobne ciasteczko (niezwiązane z sesją) oraz umieszcza go w kodzie strony. Kiedy przeglądarka wysyła żądanie POST, wysyła ciasteczko, a skrypt frontendowy (np. w JavaScript) dorzuca ten sam token w nagłówku. Backend sprawdza tylko, czy wartość z ciasteczka i nagłówka jest identyczna. Proste i skuteczne.

Dobrym pomysłem jest zastosowanie dwóch kroków przy wdrażaniu tokenów:

• Generowanie kryptograficznie silnych wartości z użyciem bezpiecznych generatorów liczb pseudolosowych dla każdej nowej sesji, co pozwala uniknąć przewidywalności.
• Natychmiastowa weryfikacja na backendzie przed jakimkolwiek dotknięciem bazy danych.

Czy flaga SameSite w ciasteczkach załatwia sprawę fałszowania żądań?

Wprowadzenie atrybutu SameSite do specyfikacji ciasteczek mocno ograniczyło wektory ataków Cross-Site Request Forgery. To mechanizm obronny realizowany bezpośrednio przez silnik przeglądarki. Mówi on przeglądarce, kiedy ma dołączyć ciasteczko do żądania cross-origin. Mamy tu kilka opcji.

Wartość Strict oznacza, że ciasteczko zostanie wysłane tylko wtedy, gdy żądanie pochodzi dokładnie z tej samej witryny. Jeśli klikniesz link do banku na stronie z wiadomościami, ciasteczko nie poleci. Musisz zalogować się ponownie. Wartość Lax to kompromis. Ciasteczko nie jest wysyłane dla ryzykownych metod (POST, PUT, DELETE), ale przeglądarka dołączy je do bezpiecznych nawigacji najwyższego poziomu (np. kliknięcie w zwykły link GET). Od jakiegoś czasu nowoczesne przeglądarki traktują wszystkie ciasteczka bez zdefiniowanej flagi jako Lax domyślnie.

Wydaje się, że Lax chroni przed większością incydentów. Prawda jest zresztą absolutnie taka, że starsze przeglądarki całkowicie ignorują ten atrybut. Oparcie całego bezpieczeństwa aplikacji webowych wyłącznie na mechanizmie SameSite to błąd. To warstwa dodatkowa. Tokeny anty-CSRF nadal obowiązują w profesjonalnych wdrożeniach.

(Czasami siedzę w logach serwera produkcyjnego i widzę te sfabrykowane nagłówki od botów. Pół biedy, jak jakiś amator użyje gotowego skryptu z GitHuba do skanowania podatności. Wtedy widać to od razu po pustych polach w payloadzie. Zmęczenie materiału przy takich audytach jest ogromne, a szukanie ominięć zabezpieczeń to po prostu grzebanie w śmietniku po nocach na produkcji z zimną kawą w ręku. Totalna strata czasu i nerwów, jeśli zespół nie zaimplementował twardych tokenów na samym początku projektu).

Weryfikacja nagłówków Origin i Referer w walce z wymuszeniami

Kolejnym etapem obrony, nazywanym Defense in Depth, jest sprawdzanie pochodzenia żądania HTTP. Każda nowoczesna przeglądarka dokleja nagłówek Origin lub Referer do żądań modyfikujących stan. Serwer po prostu odczytuje ten nagłówek i sprawdza, czy domena źródłowa zgadza się z domeną docelową.

Mechanika ta działa świetnie jako szybki filtr. Odrzucasz wszystko, co nie pochodzi z Twojej domeny. Problem polega na tym, że nagłówek Referer może zostać zablokowany przez restrykcyjne polityki prywatności użytkownika (np. atrybut rel=”noreferrer” lub ustawienia korporacyjnych proxy). Origin jest znacznie bardziej wiarygodny, ale w rzadkich przypadkach specyficznych przekierowań 302 może go zabraknąć. Dlatego sprawdzanie nagłówków to wsparcie, a nie główny filar obrony przed sfałszowanymi żądaniami.

Architektura bezstanowa a CSRF – co z tokenami JWT?

Przejście na architekturę bezstanową i mikroserwisy mocno zmieniło sposób uwierzytelniania. Zamiast sesji trzymanej w pamięci serwera, aplikacje zaczęły masowo używać tokenów JWT (JSON Web Tokens). I tutaj pojawia się ogromne nieporozumienie w środowisku programistów.

Jeśli przechowujesz JWT w pamięci lokalnej przeglądarki (localStorage) i wysyłasz go w nagłówku Authorization: Bearer przy użyciu JavaScriptu, jesteś całkowicie odporny na CSRF. Przeglądarka nie wysyła nagłówków niestandardowych automatycznie z formularzy HTML. Atakujący nie ma jak zmusić ofiary do wysłania takiego żądania z dołączonym tokenem. Podatność nie istnieje.

Ale jeśli ze względów bezpieczeństwa przed atakami XSS (Cross-Site Scripting) schowasz swój token JWT do ciasteczka z flagą HttpOnly, problem CSRF powraca natychmiast. Ciasteczko to ciasteczko. Przeglądarka wyśle je automatycznie. ZAPOMINA się o tym regularnie na wdrożeniach, traktując JWT jako magiczną tarczę na wszelkie zło. Jeśli JWT leży w ciastku, potrzebujesz tokena anti-CSRF tak samo jak przy klasycznej sesji PHP czy Java.

Rozwiązanie tego problemu w aplikacjach typu Single Page Application (SPA) polega zazwyczaj na użyciu niestandardowych nagłówków żądania (Custom Request Headers). Frontend oparty na React czy Angular wysyła każde wywołanie API z dodatkowym, sztucznym nagłówkiem, np. X-Requested-With: XMLHttpRequest. Z uwagi na zasady CORS (Cross-Origin Resource Sharing), przeglądarka nie pozwoli obcej domenie na wysłanie takiego niestandardowego nagłówka bez uprzedniego wykonania żądania preflight (OPTIONS). Serwer odrzuca preflight z obcej domeny. Atak zostaje zablokowany na poziomie silnika przeglądarki.

Architektura zabezpieczeń wymaga twardych decyzji. Mamy tu kilka dróg do wyboru na produkcji:

• Wymuszenie niestandardowych nagłówków HTTP dla każdego wywołania z użyciem bibliotek typu Axios, co automatycznie odrzuca tradycyjne formularze i wymusza pełne oparcie aplikacji o żądania asynchroniczne.
• Klasyczny token synchronizujący w ukrytym polu formularza.
• Architektura Double Submit Cookie polegająca na porównywaniu nagłówka z ciastkiem, bez obciążania pamięci bazy danych po stronie backendu.
• Rygorystyczne oznaczenie absolutnie wszystkich sesji flagą SameSite Strict, co z kolei powoduje, że użytkownicy z zewnętrznych linków e-mail muszą się w kółko logować na nowo, wywołując wściekłość działów obsługi klienta.

Decyzja o wyborze metody zawsze należy do architekta systemu. Weryfikuj dane z nagłówków. Nie ufaj ciasteczkom bez pokrycia w tokenach. Testuj żądania POST z zewnętrznych domen. Odcinaj metody GET od jakichkolwiek zmian w bazie danych. To jedyna droga, by nie budzić się w nocy z powodu wycieku danych klientów.

Zabezpieczenie aplikacji przed fałszowaniem żądań to sprawdzian z podstawowej higieny programistycznej. Sprawdź swoje formularze. Otwórz narzędzia deweloperskie w przeglądarce i spróbuj wykonać żądanie z innej karty. Jeśli przejdzie, masz poważny problem do rozwiązania przed poniedziałkiem.

Często zadawane pytania (FAQ)

• Co to jest atak CSRF?
  To wymuszenie na uwierzytelnionym użytkowniku wykonania niechcianej akcji w aplikacji webowej za pomocą spreparowanego żądania HTTP z obcej domeny.
• Jak działa token CSRF?
  To unikalny ciąg znaków generowany przez serwer i weryfikowany przy każdym żądaniu zmieniającym stan aplikacji. Brak zgodności powoduje odrzucenie żądania.
• Czy używanie tokenów JWT chroni przed CSRF?
  Jeśli JWT jest przesyłany w nagłówku Authorization, chroni. Jeśli zapiszesz JWT w ciasteczku HttpOnly, podatność nadal istnieje i wymaga dodatkowej obrony.
• Czy metoda GET jest bezpieczna?
  Żądania GET nigdy nie powinny zmieniać stanu aplikacji. Użycie GET do modyfikacji bazy danych to krytyczny błąd projektowy ułatwiający ataki.
• Czym różni się SameSite Lax od Strict?
  Lax pozwala na wysłanie ciasteczka przy bezpiecznej nawigacji najwyższego poziomu (np. kliknięcie w link). Strict całkowicie blokuje ciasteczka z obcych witryn.
• Czy CORS zapobiega CSRF?
  Nie. CORS zarządza prawem do odczytu odpowiedzi z obcej domeny. CSRF opiera się na samym fakcie wysłania żądania, a nie na odczytaniu jego wyniku.

Bibliografia:

1. Open Worldwide Application Security Project (OWASP) – https://owasp.org
2. Mozilla Developer Network (MDN Web Docs) – https://developer.mozilla.org
3. Baza Podatności MITRE (CVE) – https://cve.mitre.org
4. Internet Engineering Task Force (IETF) – https://ietf.org