Ataki CSRF – czym są i jak się przed nimi chronić
CSRF (Cross-Site Request Forgery) to rodzaj ataku na aplikacje webowe, który pozwala atakującemu wymusić wykonanie niepożądanego działania w imieniu zalogowanego użytkownika. W przeciwieństwie do XSS, CSRF nie polega na wstrzyknięciu kodu do strony, lecz na wykorzystaniu zaufania serwera do użytkownika. Skutkiem może być zmiana danych, wykonanie przelewów, modyfikacja ustawień konta czy inne nieautoryzowane operacje.
W tym artykule przedstawimy, jak działają ataki CSRF, jakie są ich skutki oraz jak skutecznie chronić systemy przed tym zagrożeniem.
Jak działa CSRF?
Atak CSRF wykorzystuje fakt, że przeglądarka użytkownika automatycznie przesyła ciasteczka sesyjne podczas logowania. Atakujący tworzy specjalnie spreparowany link lub formularz, który wysyła żądanie do serwera ofiary, np.:
<img src="https://example.com/change_email?email=hacker@example.com">
Jeżeli użytkownik jest zalogowany na example.com, serwer może wykonać żądanie, zakładając, że jest autoryzowane.
Skutki ataków CSRF
- Zmiana danych konta użytkownika (email, hasło, profil),
- Nieautoryzowane transakcje finansowe w serwisach bankowych,
- Wysyłanie spamu lub wiadomości w imieniu użytkownika,
- Modyfikacja ustawień administracyjnych w panelach CMS,
- Utrata zaufania użytkowników i kompromitacja danych.
Jak zabezpieczyć aplikacje przed CSRF?
1. Tokeny CSRF
Najskuteczniejszym sposobem ochrony jest stosowanie unikalnych tokenów CSRF, które są generowane dla każdej sesji lub formularza. Token musi być przesłany w żądaniu, a serwer weryfikuje jego poprawność.
Przykład w PHP:
// Generowanie tokena
$_SESSION['csrf_token'] = bin2hex(random_bytes(32));
// W formularzu
<input type="hidden" name="csrf_token" value="<?php echo $_SESSION['csrf_token']; ?>">
// Weryfikacja po stronie serwera
if ($_POST['csrf_token'] !== $_SESSION['csrf_token']) {
die("Nieautoryzowane żądanie!");
}
2. Sprawdzenie nagłówków Origin i Referer
Serwer może weryfikować nagłówki HTTP Origin lub Referer, aby upewnić się, że żądanie pochodzi z zaufanej domeny.
if ($_SERVER['HTTP_ORIGIN'] !== 'https://example.com') {
die("Nieautoryzowane żądanie!");
}
3. Metody HTTP
- Wrażliwe operacje powinny używać POST, PUT, DELETE, a nie GET,
- GET powinien służyć wyłącznie do odczytu danych.
4. SameSite Cookies
Ustawienie flagi SameSite dla ciasteczek ogranicza ich przesyłanie w żądaniach zewnętrznych stron.
Set-Cookie: sessionId=abc123; SameSite=Strict; Secure; HttpOnly
5. Regularne testy bezpieczeństwa
- Skany automatyczne pod kątem CSRF przy użyciu narzędzi takich jak OWASP ZAP, Burp Suite,
- Testy penetracyjne aplikacji, aby wykryć brak zabezpieczeń w formularzach i API.
Praktyczne wskazówki
- Nigdy nie ufaj automatycznie ciasteczkom sesyjnym w kontekście operacji wrażliwych,
- Tokeny CSRF powinny być trudne do przewidzenia i zmieniać się dla każdej sesji/formularza,
- Separuj operacje odczytu od zapisu – GET do odczytu, POST/PUT/DELETE do zmian,
- Wdrażaj polityki bezpieczeństwa w całej aplikacji, a nie tylko w wybranych formularzach.
Podsumowanie
Ataki CSRF wykorzystują zaufanie serwera do zalogowanego użytkownika i mogą prowadzić do poważnych naruszeń bezpieczeństwa w aplikacjach webowych. Skuteczna ochrona wymaga kombinacji tokenów CSRF, kontroli nagłówków, odpowiednich metod HTTP i ustawień ciasteczek SameSite.
Stosując te praktyki, można znacząco zmniejszyć ryzyko ataku CSRF i chronić użytkowników oraz integralność aplikacji.
Automatyzacja Zarządzania Poprawkami Bezpieczeństwa w Windows Server: WSUS vs. Chmurowe Rozwiązania Zarządzanie poprawkami bezpieczeństwa (patch management) to jeden z najważniejszych, Czytaj dalej
Oszustwa i dezinformacja w mediach społecznościowych – jak je rozpoznać i unikać? Wstęp Media społecznościowe stały się głównym źródłem informacji Czytaj dalej
