CSRF (Cross-Site Request Forgery)

CSRF (Cross-Site Request Forgery) to atak zmuszający zalogowanego użytkownika do nieświadomego wysłania żądania, które zmienia stan jego konta albo witryny. Według MITRE podatność polega na tym, że aplikacja internetowa nie potrafi dostatecznie sprawdzić, czy żądanie zostało wysłane przez użytkownika celowo ^[1]. OWASP opisuje CSRF jako atak, który nakłania ofiarę do wysłania złośliwego żądania z wykorzystaniem jej uwierzytelnionej sesji ^[2]. W zestawieniu CWE Top 25 za 2025 rok słabość CWE-352 zajęła trzecie miejsce ^[6].

Jak działa

Przeglądarka dołącza do żądania ciasteczka przypisane do danej witryny, w tym ciasteczko z tokenem sesyjnym. Robi to także wtedy, gdy żądanie wywołała inna strona. OWASP zwraca uwagę, że skoro żądanie wysyła przeglądarka ofiary, to ona, a nie atakujący, otrzymuje odpowiedź ^[2]. Dlatego celem CSRF-a są żądania zmieniające stan, takie jak przelew, zmiana adresu e-mail albo hasła; zmuszanie ofiary do pobrania danych nic atakującemu nie daje ^[2].

Atak wymaga socjotechniki: ofiarę trzeba skłonić do otwarcia przygotowanej strony albo wiadomości. OWASP podaje jako przykład e-maile z treścią HTML i adresy podrzucone na stronach, które ofiara odwiedza ^[2]. Może to być również link w kampanii phishing. Przebieg ataku na panel administracyjny pokazuje schemat poniżej.

RYS. 1CSRF przeciw zalogowanemu administratorowi

MITRE zaznacza, że CSRF jest słabością złożoną: do jej powstania musi dojść jednocześnie kilka warunków, w tym brak weryfikacji pochodzenia żądania i niewystarczające wygasanie sesji ^[1].

Odmiany i błędne zabezpieczenia

CSRF ma wiele nazw. OWASP wymienia między innymi XSRF, „Sea Surf”, Session Riding, Hostile Linking i atak jednym kliknięciem (one-click attack) ^[2]. Opisuje też zabezpieczenia, które nie działają, choć bywają stosowane.

Nie należy mylić CSRF z SSRF. W SSRF to serwer jest nakłaniany do wysłania żądania, a w CSRF przeglądarka użytkownika.

W WordPressie

WordPress chroni formularze i adresy akcji tokenem nazywanym nonce. Dokumentacja wyjaśnia, że nonce w WordPressie nie jest liczbą jednorazową w ścisłym sensie, tylko skrótem złożonym z cyfr i liter, o ograniczonym czasie życia ^[4]. Przy domyślnym czasie 24 godzin token jest ważny w bieżącym i poprzednim „tyknięciu”, więc faktycznie żyje od 12 do 24 godzin ^[4]. Atakujący, który nie zna tokenu, nie może go umieścić w podrobionym żądaniu ^[4].

Dokumentacja podkreśla, że na nonce nigdy nie wolno polegać przy uwierzytelnianiu, autoryzacji ani kontroli dostępu; funkcje trzeba chronić wywołaniem current_user_can() ^[4]. Obsługa zapisu ustawień we wtyczce powinna więc łączyć oba sprawdzenia.

// formularz
wp_nonce_field( 'zapisz_ustawienia' );

// obsługa zapisu
check_admin_referer( 'zapisz_ustawienia' );
if ( ! current_user_can( 'manage_options' ) ) {
    wp_die( 'Brak uprawnień' );
}

Brak którejkolwiek z tych linii jest typowym źródłem luk; zob. podatność we wtyczce oraz brak kontroli uprawnień. Sprawdzenie uprawnień to weryfikacja uprawnień oparta na systemie, który opisują role i uprawnienia użytkowników.

Zagrożenia i skutki

Skutek CSRF-a zależy od uprawnień ofiary. MITRE wymienia nieautoryzowane operacje, ujawnienie danych i eskalację uprawnień, a przy ofierze z uprawnieniami administratora nawet przejęcie całej aplikacji ^[1]. Na stronie WordPress podrobione żądanie wysłane z przeglądarki administratora może na przykład zmienić ustawienia wtyczki albo założyć nieautoryzowane konto administratora.

CSRF bywa też ogniwem łańcucha. Jeśli podrobione żądanie trafia do funkcji podatnej na inny błąd, atakujący uruchamia ten błąd rękami zalogowanego użytkownika.

Jak się bronić

OWASP jako główne zabezpieczenie zaleca wzorzec tokenu synchronizującego: token unikalny dla sesji, tajny, nieprzewidywalny i sprawdzany po stronie serwera ^[3]. MITRE zaleca podobnie nieprzewidywalny nonce dla każdego formularza oraz osobne potwierdzenie operacji niebezpiecznych ^[1]. Obie organizacje odradzają zmienianie stanu żądaniami GET ^{[1] [3]}.

Warstwą uzupełniającą jest atrybut SameSite ciasteczek, jedna z flag ciasteczek. MDN podaje, że daje on pewną ochronę przed niektórymi atakami między witrynami, w tym przed CSRF ^[5]. Wartość Strict wysyła ciasteczko tylko w żądaniach z tej samej witryny, a Lax dopuszcza dodatkowo nawigację najwyższego poziomu metodą bezpieczną ^[5]. OWASP traktuje SameSite jako obronę uzupełniającą, a nie jedyną ^[3]. Jako lżejszą metodę dla nowszych przeglądarek wskazuje nagłówki Fetch Metadata, w tym Sec-Fetch-Site ^[3].

Ochrona przed CSRF zakłada brak XSS. OWASP ostrzega, że XSS może obejść wszystkie techniki ochrony przed CSRF ^[3], bo skrypt działający na stronie może odczytać token.

Historia i przykłady

CERT Polska 10 lipca 2024 roku opublikował informację o dwóch podatnościach w otwartym projekcie Phoniebox ^[7]. Luka CVE-2024-3798 pozwalała przez modyfikację parametru w żądaniach GET na wstrzyknięcie poleceń powłoki, a także na ataki Reflected XSS i Cross-Site Request Forgery ^[7]. Ponieważ urządzenie nie powinno być dostępne z internetu, scenariusz ataku zakładał, że użytkownik odwiedzi stronę wysyłającą żądania do hostów w jego sieci lokalnej ^[7]. To typowy wzorzec CSRF: przeglądarka ofiary staje się pośrednikiem. W katalogu CWE ta klasa podatności ma numer 352 ^[1].