Co to jest CSRF?
Autor: Redakcja Domeny.ForSale Opublikowano
W skrócie: CSRF to atak, w którym cudza strona nakłania przeglądarkę zalogowanego użytkownika do wysłania niechcianego żądania do innego serwisu. Jeśli serwis sprawdza tylko, czy użytkownik jest zalogowany, może wykonać operację bez jego świadomej zgody. Podstawą ochrony są zabezpieczenia po stronie aplikacji: tokeny CSRF, właściwe ustawienia ciasteczek i kontrola pochodzenia żądań.
Jak działa CSRF — przykład z panelem sklepu
CSRF to skrót od Cross-Site Request Forgery, czyli fałszowania żądań między witrynami. Atak wykorzystuje fakt, że przeglądarka może automatycznie dołączać ciasteczko sesyjne do żądań kierowanych do danego serwisu. Takie ciasteczko pozwala serwerowi rozpoznać zalogowaną osobę bez ponownego pytania o hasło.
Wyobraź sobie, że zarządzasz sklepem internetowym i masz otwarty panel administratora. W drugiej karcie odwiedzasz stronę przygotowaną przez napastnika. Ta strona próbuje wysłać do panelu żądanie zmiany adresu e-mail przypisanego do twojego konta.
Jeśli przeglądarka dołączy ciasteczko sesyjne, a panel nie sprawdzi dodatkowo autentyczności żądania, serwer może potraktować je jak twoją decyzję. Napastnik nie musi znać hasła ani odczytywać ciasteczka — wystarczy, że przeglądarka wykorzysta je przy wysyłaniu żądania.
To trochę tak, jakby ktoś podsunął do realizacji dyspozycję z twoją automatycznie dołączoną pieczątką. System rozpoznaje pieczątkę, ale nie sprawdza, czy rzeczywiście chcesz wykonać tę konkretną operację.
Kiedy atak może się udać i co mu nie przeszkadza
Typowy CSRF wymaga kilku warunków: użytkownik ma aktywną sesję, przeglądarka automatycznie wysyła dane uwierzytelniające, a aplikacja przyjmuje przewidywalne żądanie zmieniające stan konta. Może chodzić o zmianę danych, dodanie użytkownika albo usunięcie wpisu. Skutki zależą od dostępnych operacji i uprawnień ofiary.
Napastnik zazwyczaj nie musi odczytać odpowiedzi serwera. Przeglądarka może zabronić obcej stronie czytania danych z panelu, ale samo wysłanie niektórych żądań jest nadal możliwe. Dlatego polityka tego samego pochodzenia, ograniczająca dostęp skryptów do cudzych zasobów, nie zastępuje ochrony przed CSRF.
HTTPS również nie rozwiązuje tego problemu. Szyfruje połączenie i chroni dane w drodze, lecz nie potwierdza, że użytkownik świadomie zlecił operację. Samo użycie metody POST zamiast GET także nie wystarcza: obca strona może wysłać zwykły formularz POST.
CSRF nie jest tym samym co XSS. XSS polega na uruchomieniu niepożądanego kodu w kontekście zaufanej witryny, natomiast CSRF wykorzystuje zaufanie serwisu do żądań z przeglądarki użytkownika. Podatność XSS może jednak podważyć zabezpieczenia przed CSRF, na przykład umożliwiając odczyt tokenu.
Jak zabezpieczyć aplikację przed CSRF
Najbezpieczniejszym punktem wyjścia jest wbudowana ochrona używanego frameworka. Trzeba ją włączyć i upewnić się, że obejmuje wszystkie operacje zmieniające dane, nie tylko formularz logowania.
- Weryfikuj token CSRF. To nieprzewidywalna wartość, którą aplikacja umieszcza w formularzu lub przekazuje do wysłania w odpowiednim nagłówku. Serwer sprawdza ją przed wykonaniem operacji. W popularnym wariancie token jest powiązany z sesją; obca strona nie powinna móc go odczytać ani odgadnąć. Token nie powinien trafiać do adresu URL.
- Ustaw atrybut SameSite ciasteczka sesyjnego. Ogranicza on wysyłanie ciasteczka w kontekstach między witrynami. Warianty Lax i Strict zapewniają różny poziom ograniczeń, więc wybór trzeba sprawdzić z logowaniem i integracjami. SameSite to warstwa ochrony, a nie bezwarunkowy zamiennik tokenu.
- Sprawdzaj pochodzenie żądania. Nagłówek Origin, a w odpowiednio zaprojektowanym mechanizmie również Referer, pomaga ustalić, skąd pochodzi żądanie. Porównuj go z dokładnie określonymi dozwolonymi adresami, zamiast szukać jedynie fragmentu nazwy domeny.
- Nie zmieniaj danych przez GET. Otwarcie linku nie powinno usuwać konta ani zatwierdzać zamówienia. Operacje zmieniające dane powinny korzystać z właściwych metod i nadal przechodzić kontrolę CSRF.
Dla szczególnie wrażliwych czynności dodaj ponowne uwierzytelnienie lub osobne potwierdzenie. Ciasteczka sesyjne powinny też mieć odpowiednie atrybuty Secure i HttpOnly, choć żaden z nich sam nie zapobiega CSRF.
Czy API też potrzebuje ochrony?
API, czyli interfejs służący do komunikacji między programami, również może być podatne na CSRF, jeśli korzysta z sesji uwierzytelnianej ciasteczkiem. Sama odpowiedź w formacie JSON nie zapewnia bezpieczeństwa.
Gdy klient jawnie dodaje token dostępu w nagłówku Authorization, a przeglądarka nie dołącza go automatycznie, typowy mechanizm CSRF zwykle nie ma zastosowania. Nie oznacza to jednak odporności na kradzież tokenu lub XSS. CORS, czyli mechanizm regulujący dostęp między pochodzeniami, także nie jest samodzielnym zabezpieczeniem przed CSRF.
Co sprawdzić we własnym serwisie
Zacznij od jednej operacji, na przykład zmiany adresu e-mail. Na koncie testowym, we własnym środowisku lub za zgodą właściciela, sprawdź, czy żądanie bez tokenu CSRF albo z błędnym tokenem zostaje odrzucone i rzeczywiście nie zmienia danych. Następnie skontroluj ustawienia ciasteczka oraz pozostałe ścieżki wykonujące tę samą operację.
Jeśli korzystasz z gotowego systemu, potwierdź sposób działania ochrony w oficjalnej dokumentacji jego wersji i zainstalowanych rozszerzeń. Jako użytkownik nie naprawisz braku zabezpieczeń serwera; możesz ograniczać ryzyko, wylogowując się po pracy z wrażliwym panelem. Jako właściciel aplikacji zacznij od przeglądu operacji zmieniających dane — to one wymagają kontroli, czy żądanie rzeczywiście pochodzi z uprawnionego interfejsu.
Zobacz też: Co oznacza www?
Przeczytaj także
