Cross‑Site Request Forgery (CSRF)

Cross‑Site Request Forgery, w skrócie CSRF, to rodzaj ataku webowego, w którym atakujący podsyła ofierze żądanie HTTP do aplikacji internetowej, w której ofiara jest uwierzytelniona, w celu wykonania niepożądanej operacji. Atak polega na wykorzystaniu zaufania, jakie serwer ma do przeglądarki użytkownika.

Mechanizm działania

Podstawowy scenariusz ataku CSRF wygląda następująco:

Użytkownik zaloguje się do aplikacji bankowości internetowej i otrzyma sesję cookie z tokenem sesji.
Sesja pozostaje aktywna, a przeglądarka automatycznie dołącza cookie do każdego żądania skierowanego do domeny banku.
Użytkownik odwiedza stronę kontrolowaną przez atakującego lub otwiera w przeglądarce złośliwy e‑mail, który zawiera np. <img src="https://bank.example.com/transfer?amount=1000&to=attacker">.
Przeglądarka wyśle żądanie GET (lub POST przy użyciu formularza) do serwera banku, dołączając ciasteczko sesji.
Serwer, uznając żądanie za pochodzące od zalogowanego użytkownika, wykona operację – w tym przykładzie przelew pieniędzy.

Wektor ataku

W atakach CSRF najczęściej wykorzystywane są następujące techniki:

Wstawianie złośliwych <img>, <script> lub <iframe> w treści strony odwiedzanej przez ofiarę.
Wysyłanie e‑maili lub wiadomości w mediach społecznościowych z linkami prowadzącymi do złośliwych zasobów.
Wykorzystanie automatycznych żądań XMLHttpRequest (CORS) w przeglądarce, jeśli serwer nie ogranicza pochodzenia.

Różnice względem Cross‑Site Scripting (XSS)

Choć oba ataki wykorzystują zaufanie przeglądarki, CSRF nie wymaga wstrzykiwania kodu do strony ofiary, natomiast XSS polega na uruchomieniu dowolnego skryptu w kontekście ofiary. W CSRF atakujący nie ma kontroli nad odpowiedzią serwera – jedynie wymusza wykonanie żądania.

Środki ochrony

Do najskuteczniejszych metod zapobiegania atakom CSRF należą:

Tokeny anty‑CSRF – losowy, jednorazowy identyfikator generowany po stronie serwera i umieszczany w formularzach oraz w nagłówku X-CSRF-Token. Serwer weryfikuje jego obecność i zgodność.
Używanie nagłówka SameSite w ciasteczkach (HTTP), który ogranicza przesyłanie ciasteczek przy żądaniach pochodzących z innych domen.
Wymaganie POST (lub innej metody niesidłowej) dla operacji zmieniających stan aplikacji oraz stosowanie nagłówka Referer lub Origin do weryfikacji źródła żądania.
Włączenie HTTPS, aby utrudnić przechwycenie tokenów sesji przez atakującego.
Implementacja CORS z restrykcyjnymi zasadami, które nie akceptują żądań z nieautoryzowanych domen.

Przykłady ataków w praktyce

W 2008 roku został wykryty atak CSRF przeciwko serwisowi Twitter, w którym atakujący mógł publikować tweety w imieniu zalogowanego użytkownika, wykorzystując jedynie link https://twitter.com/home?status=spam. W 2012 roku atak CSRF doprowadził do nieautoryzowanego przeniesienia pieniędzy w aplikacji bankowej w Japonii.

Testowanie podatności

W ramach audytu bezpieczeństwa aplikacji webowych zaleca się:

Używanie specjalistycznych narzędzi, takich jak OWASP ZAP lub Burp Suite, które automatycznie wykrywają brak tokenów anty‑CSRF.
Ręczne przeglądanie formularzy pod kątem brakujących csrf_token i sprawdzanie, czy serwer akceptuje żądania bez nich.
Symulowanie żądań pochodzących z zewnętrznych domen (np. poprzez własną stronę testową) i obserwowanie reakcji aplikacji.