ABCDEFGHIJKLMNOPQRSTUVWXYZ
← Powrót

C

CSRF (Cross-Site Request Forgery)

Wprowadzenie

CSRF (Cross-Site Request Forgery), znany również jako atak XSRF, to rodzaj luki bezpieczeństwa, który zmusza zalogowanego użytkownika do wykonania niepożądanych akcji w aplikacji webowej, z którą jest już uwierzytelniony. Ataki CSRF wykorzystują zaufanie, jakie aplikacja docelowa pokłada w przeglądarce użytkownika, która automatycznie dołącza ciasteczka sesji do każdego żądania wysyłanego do zaufanej domeny. Istota ataku CSRF polega na tym, że atakujący nie poznaje danych logowania użytkownika ani nie ma bezpośredniego dostępu do sesji. Zamiast tego, manipuluje przeglądarką użytkownika tak, aby wysłała złośliwe żądanie, które wygląda jak legalna operacja zainicjowana przez samego użytkownika. To sprawia, że serwer nie jest w stanie odróżnić autoryzowanego żądania od tego wymuszonego, co może prowadzić do poważnych konsekwencji.

Jak działają ataki CSRF?

Mechanizm działania ataku CSRF opiera się na prostym, lecz skutecznym wykorzystaniu sposobu, w jaki przeglądarki internetowe zarządzają sesjami uwierzytelnionymi użytkowników. Typowy scenariusz ataku przebiega następująco: 1. **Uwierzytelnienie użytkownika:** Użytkownik loguje się do legalnej aplikacji webowej (np. bankowości elektronicznej, portalu społecznościowego). Aplikacja tworzy sesję i zapisuje dane uwierzytelniające (zazwyczaj w postaci ciasteczek sesyjnych) w przeglądarce użytkownika. Te ciasteczka są automatycznie dołączane do każdego kolejnego żądania wysyłanego do tej samej domeny. 2. **Zwabienie na złośliwą stronę:** Atakujący tworzy złośliwą stronę internetową lub umieszcza złośliwy kod na innej, pozornie niewinnej stronie. Ta strona zawiera element (np. ukryty formularz HTML, znacznik `<img>` z adresem URL akcji, żądanie JavaScript `fetch()`), który automatycznie wysyła żądanie HTTP do legalnej aplikacji, do której użytkownik jest zalogowany. 3. **Wymuszone żądanie:** Gdy użytkownik odwiedzi złośliwą stronę, jego przeglądarka automatycznie wykonuje żądanie do legalnej aplikacji. Co kluczowe, do tego żądania dołączane są również ciasteczka sesyjne uwierzytelniające użytkownika, ponieważ żądanie jest kierowane do domeny, dla której ciasteczka są ważne. 4. **Wykonanie nieautoryzowanej akcji:** Legalna aplikacja odbiera żądanie, interpretuje je jako pochodzące od uwierzytelnionego użytkownika (ponieważ zawiera prawidłowe ciasteczka sesji) i wykonuje wskazaną akcję. Atakujący może w ten sposób wymusić np. zmianę adresu e-mail, hasła, wykonanie przelewu bankowego, opublikowanie posta lub inną operację, którą użytkownik mógłby wykonać samodzielnie.

Główne zalety i charakterystyka

Ataki CSRF, choć są luką bezpieczeństwa, charakteryzują się kilkoma cechami, które czynią je szczególnie niebezpiecznymi i trudnymi do wykrycia dla użytkownika końcowego. Po pierwsze, ich skuteczność polega na wykorzystaniu zaufania, jakim aplikacja darzy przeglądarkę użytkownika. Atakujący nie musi przełamywać zabezpieczeń serwera ani poznawać danych logowania. Po drugie, atak może być całkowicie przezroczysty dla ofiary – wystarczy, że użytkownik odwiedzi złośliwą stronę, a żądanie zostanie wysłane automatycznie, często bez żadnej widocznej interakcji poza samym załadowaniem strony. Po trzecie, brak jawnej akcji ze strony użytkownika, innej niż zwykłe przeglądanie internetu, sprawia, że wykrycie, że stał się ofiarą ataku, jest niezwykle trudne aż do momentu zaobserwowania skutków, takich jak nieautoryzowane zmiany na koncie.

Zastosowania w praktyce

  • Nieautoryzowana zmiana danych profilowych użytkownika (np. adresu e-mail, numeru telefonu, hasła) w aplikacji webowej.
  • Wykonywanie transakcji finansowych (np. przelewy bankowe, zakupy) bez zgody użytkownika, jeśli bankowość lub sklep internetowy jest podatny na CSRF.
  • Wysyłanie wiadomości, postów lub komentarzy w imieniu użytkownika na portalach społecznościowych lub forach.
  • Zmiana ustawień prywatności lub bezpieczeństwa konta użytkownika, co może prowadzić do dalszych ataków.
  • Usunięcie konta użytkownika lub innych ważnych danych bez jego zgody.
  • Wykonywanie operacji administracyjnych w panelach CMS lub innych systemach zarządzania, jeśli administrator jest zalogowany i podatny na atak.

Porównanie z innymi strukturami danych

Ataki CSRF często są mylone z innymi rodzajami luk bezpieczeństwa webowego, takimi jak XSS (Cross-Site Scripting) czy Clickjacking, ale fundamentalnie różnią się mechanizmem i celem. **XSS (Cross-Site Scripting)** to atak, w którym atakujący wstrzykuje złośliwy skrypt do strony internetowej, który następnie jest wykonywany w przeglądarce ofiary. XSS atakuje zaufanie przeglądarki do zawartości strony, umożliwiając np. kradzież ciasteczek sesyjnych (co następnie może prowadzić do przejęcia sesji), modyfikację strony czy przekierowanie użytkownika. CSRF natomiast nie wymaga wstrzykiwania kodu. Wykorzystuje zaufanie serwera do żądań pochodzących z przeglądarki użytkownika, która automatycznie dołącza ciasteczka sesji. Główna różnica: XSS atakuje użytkownika, aby uzyskać kontrolę nad jego sesją lub danymi w przeglądarce; CSRF atakuje aplikację (serwer) poprzez przeglądarkę użytkownika, aby wymusić wykonanie akcji w jego imieniu. **Clickjacking** (UI Redressing) to technika, która nakłada niewidzialną warstwę (np. iframe) na pozornie nieszkodliwą stronę internetową, aby ukryć elementy sterujące, które użytkownik zamierza kliknąć. W rezultacie użytkownik, myśląc, że klika element złośliwej strony, w rzeczywistości klika element ukrytej, legalnej strony, np. przycisk 'Potwierdź transakcję'. Clickjacking skupia się na manipulowaniu interfejsem użytkownika i jego kliknięciami, podczas gdy CSRF operuje na poziomie żądań HTTP, bez konieczności interakcji z ukrytym elementem interfejsu (choć może być połączony ze swego rodzaju 'klikiem' użytkownika na złośliwej stronie).

Najlepsze praktyki (2026)

  • **Tokeny anty-CSRF (Synchronizer Token Pattern):** Najskuteczniejsza metoda. Polega na generowaniu unikalnego, nieprzewidywalnego tokena dla każdej sesji użytkownika i umieszczaniu go w ukrytym polu formularza lub nagłówku żądania. Serwer weryfikuje ten token przy każdym wrażliwym żądaniu. Jeśli token jest nieobecny lub nieprawidłowy, żądanie jest odrzucane.
  • **Nagłówek SameSite Cookie:** Ustawienie atrybutu `SameSite` dla ciasteczek sesyjnych na `Lax` lub `Strict`. W trybie `Lax`, ciasteczka są wysyłane tylko w żądaniach GET inicjowanych przez nawigację top-level (np. kliknięcie linku). W trybie `Strict`, ciasteczka są wysyłane tylko, gdy żądanie pochodzi z tej samej domeny, co ciasteczko, co skutecznie blokuje ataki CSRF, ale może ograniczyć funkcjonalność (np. przy logowaniu przez zewnętrzne strony).
  • **Weryfikacja nagłówka Referer lub Origin:** Sprawdzanie nagłówków `Referer` (dla żądań POST) lub `Origin` (dla żądań CORS) w celu upewnienia się, że żądanie pochodzi z zaufanej domeny. Metoda ta jest mniej niezawodna, gdyż nagłówek `Referer` może być zablokowany przez przeglądarkę, a `Origin` nie zawsze jest obecny.
  • **Wymaganie ponownego uwierzytelnienia:** Dla krytycznych operacji (np. zmiana hasła, wykonanie przelewu) należy wymagać od użytkownika ponownego wprowadzenia hasła. Zapewnia to dodatkową warstwę ochrony, nawet jeśli token CSRF zostałby w jakiś sposób ominięty.
  • **Dobre praktyki projektowe:** Unikanie używania żądań HTTP GET do wykonywania operacji zmieniających stan na serwerze, ponieważ żądania GET są łatwiejsze do sfałszowania (np. poprzez tag `<img>`). Operacje zmieniające stan powinny zawsze używać POST, PUT lub DELETE.
  • **CORS (Cross-Origin Resource Sharing):** Poprawna konfiguracja nagłówków CORS może pomóc w zapobieganiu niektórym typom ataków CSRF, zwłaszcza tym wykorzystującym JavaScript do wysyłania żądań. Ograniczanie domen, które mogą wysyłać żądania cross-origin, minimalizuje ryzyko.

Typowe błędy i pułapki

  • **Brak tokenów anty-CSRF:** Najczęstszy błąd, pozostawiający aplikację całkowicie bezbronną.
  • **Nieprawidłowa walidacja tokenów:** Tokeny są generowane, ale serwer nie sprawdza ich poprawności lub istnienia przy odbieraniu żądań.
  • **Tokeny CSRF w ciasteczkach lub URL-ach:** Umieszczanie tokenów CSRF w ciasteczkach, które są automatycznie wysyłane z każdym żądaniem, lub w adresach URL (co naraża je na wyciek przez logi, Referer itp.), niweczy ich cel.
  • **Użycie `SameSite=None` bez atrybutu `Secure`:** Ciasteczka z `SameSite=None` są wysyłane z żądań cross-site, ale wymagają atrybutu `Secure` (czyli HTTPS). Bez niego mogą być narażone na przechwycenie.
  • **Opieranie się wyłącznie na nagłówku Referer/Origin:** Nagłówki te mogą być pominięte, zablokowane przez użytkownika lub manipulowane w niektórych scenariuszach, co sprawia, że nie są wystarczającą ochroną.
  • **Używanie żądań GET dla operacji zmieniających stan:** Umożliwia łatwe wykonanie ataku CSRF przez proste umieszczenie linku lub obrazka z odpowiednim adresem URL.