Zapobieganie CSRF atakom

Zapobieganie atakom CSRF (Cross-Site Request Forgery) polega na stosowaniu tokenów zabezpieczających w formularzach, weryfikacji nagłówków żądań i odpowiedniej konfiguracji ciasteczek — to zadanie po stronie tworzenia i utrzymania aplikacji webowych, nie naprawy sprzętu.

Zapobieganie CSRF atakom — definicja i znaczenie

Zapobieganie CSRF atakom, czyli atakom typu Cross-Site Request Forgery, obejmuje działania ograniczające możliwość wykonania przez przeglądarkę użytkownika nieautoryzowanej operacji w serwisie internetowym. W takim scenariuszu osoba korzystająca z bankowości, panelu administracyjnego, sklepu lub innej aplikacji pozostaje zalogowana, a następnie odwiedza stronę przygotowaną przez napastnika. Przeglądarka może wtedy wysłać żądanie do wcześniej używanej usługi wraz z zapisanymi danymi sesyjnymi. Jeżeli aplikacja rozpoznaje wyłącznie aktywną sesję, bez sprawdzenia dodatkowego potwierdzenia intencji, może dojść do zmiany ustawień, wysłania formularza, utworzenia użytkownika albo wykonania innej operacji dostępnej na danym koncie.

Podstawową zasadą ochrony jest rozdzielenie samego faktu uwierzytelnienia od potwierdzenia, że konkretna czynność została rzeczywiście zainicjowana w prawidłowym interfejsie. W tym celu do formularzy i żądań zmieniających dane dołącza się losowy token CSRF, powiązany z sesją lub użytkownikiem. Wartość ta powinna być nieprzewidywalna, sprawdzana po stronie aplikacji i odrzucana po wykryciu braku, niezgodności albo próby ponownego użycia, jeżeli przyjęty mechanizm wymaga jednorazowości. Ochrona musi obejmować wszystkie operacje modyfikujące stan, a nie tylko logowanie czy najbardziej widoczne formularze.

Nie należy traktować ochrony CSRF jako zabezpieczenia przed każdym rodzajem przejęcia konta. Token przeciwdziała nakłonieniu przeglądarki do wysłania prawidłowo uwierzytelnionego żądania z obcej strony, lecz nie zastępuje ochrony przed kradzieżą haseł, złośliwym oprogramowaniem, przejęciem sesji, podatnościami XSS ani błędami uprawnień. Skuteczność zależy od spójnego stosowania zabezpieczeń w całej aplikacji, poprawnego zarządzania sesją oraz świadomego rozróżnienia żądań tylko odczytujących od tych, które powodują zmianę danych.

Mechanizmy ochronne i kontekst techniczny

Najczęściej stosowanym rozwiązaniem jest token synchronizujący, generowany po stronie aplikacji i przekazywany w formularzu albo w odpowiednim nagłówku żądania. Po odebraniu operacji serwer porównuje token z wartością zapisaną dla bieżącej sesji. Napastnik może próbować wymusić samo wysłanie formularza, ale zwykle nie zna wartości wygenerowanej dla konkretnego użytkownika. W aplikacjach korzystających z interfejsów opartych na JavaScript token może być przekazywany w nagłówku, którego nie da się swobodnie ustawić z obcej domeny z powodu zasad bezpieczeństwa przeglądarki. Nie zwalnia to jednak z prawidłowej konfiguracji reguł dostępu między źródłami.

Drugą warstwę stanowi sprawdzanie nagłówków Origin oraz, w określonych przypadkach, Referer. Nagłówek Origin wskazuje źródło żądania i może pomóc odrzucić operacje pochodzące z niezatwierdzonej domeny. Weryfikacja nie powinna polegać na prostym wyszukiwaniu fragmentu tekstu, ponieważ podobnie nazwany host lub odpowiednio spreparowany adres może prowadzić do błędnej akceptacji. Lista dozwolonych źródeł powinna być jednoznaczna, ograniczona do rzeczywiście wykorzystywanych adresów i aktualizowana wraz ze zmianami aplikacji.

Istotne znaczenie ma również ustawienie atrybutu SameSite dla ciasteczek sesyjnych. Wariant Lax ogranicza przekazywanie ciasteczka w części żądań między witrynami i często stanowi rozsądny poziom bazowy. Strict zapewnia bardziej rygorystyczne ograniczenie, ale może wpływać na wygodę przechodzenia do serwisu z zewnętrznych odnośników. Wartość None pozwala na wysyłanie ciasteczka w kontekście między witrynami, dlatego powinna być stosowana wyłącznie wtedy, gdy jest to uzasadnione, zawsze razem z atrybutem Secure. Niezależnie od konfiguracji ciasteczek powinien być stosowany token lub równoważny mechanizm kontroli żądania.

Niebezpieczne operacje nie powinny być realizowane metodą GET, ponieważ żądania przeznaczone do pobierania danych mogą być wywoływane przez obrazy, odnośniki, przekierowania i inne elementy osadzane na stronie. Zmiana hasła, adresu, uprawnień, ustawień profilu, statusu zamówienia lub innych danych powinna wymagać metody przeznaczonej do modyfikacji oraz dodatkowej walidacji. Warto także stosować ponowne uwierzytelnienie przy czynnościach szczególnie wrażliwych, ograniczać czas życia sesji i rejestrować odrzucone próby walidacji tokenu.

Typowe problemy i błędy konfiguracyjne - Zapobieganie CSRF atakom

Częstym błędem jest zabezpieczenie tylko części formularzy. Jeżeli token sprawdzany jest przy edycji profilu, ale pominięto zmianę adresu dostawy, dodawanie odbiorcy przelewu, usuwanie zasobu lub operacje wykonywane z poziomu panelu administracyjnego, pozostaje praktyczna ścieżka do nadużycia. Przegląd powinien objąć wszystkie punkty końcowe, które zapisują dane, zmieniają uprawnienia, uruchamiają działania albo wywołują skutki biznesowe.

Ryzyko powstaje także wtedy, gdy token jest przewidywalny, stały dla wszystkich użytkowników, umieszczony w adresie URL lub akceptowany bez sprawdzenia jego związku z bieżącą sesją. Nie powinno się również uznawać obecności dowolnego pola o nazwie sugerującej token za wystarczającą ochronę. Wartość musi być generowana z użyciem bezpiecznego źródła losowości, przechowywana w sposób odpowiedni dla przyjętego modelu sesji i porównywana bez podatności na błędy implementacyjne.

Problematyczne bywają aplikacje korzystające z kilku domen, poddomen, bram pośredniczących lub różnych interfejsów. Zbyt szeroki zakres ciasteczka, niejednoznaczne reguły CORS, automatyczne przekazywanie danych uwierzytelniających oraz niespójne ustawienia protokołu mogą osłabić ochronę. Szczególnej uwagi wymagają żądania wykonywane asynchronicznie, formularze wieloetapowe i operacje uruchamiane z poziomu aplikacji mobilnej lub zewnętrznego klienta. Każdy kanał powinien mieć jasno określone zasady uwierzytelniania i potwierdzania intencji.

Sam token CSRF nie usuwa problemu podatności XSS. Jeżeli obcy kod może wykonywać skrypty w kontekście zabezpieczonej aplikacji, może również próbować odczytać token albo użyć dostępnego interfejsu w imieniu użytkownika. Dlatego potrzebne są równoległe działania: filtrowanie i kodowanie danych wyświetlanych w przeglądarce, właściwa polityka bezpieczeństwa treści, kontrola zależności, ograniczenie uprawnień oraz testy regresyjne po zmianach w formularzach i obsłudze sesji. Przydatne jest testowanie zarówno oczekiwanych żądań, jak i prób pozbawionych tokenu, zawierających token z innej sesji albo pochodzących z niedozwolonego źródła.

Kiedy trzeba przekazać urządzenie do naprawy - Zapobieganie CSRF atakom

Wsparcie serwisowe może być przydatne wtedy, gdy podejrzewa się, że problem z CSRF jest skutkiem nieprawidłowego działania przeglądarki, uszkodzonego profilu użytkownika, nieaktualnego oprogramowania zabezpieczającego albo infekcji wpływającej na pracę systemu. Objawami wymagającymi sprawdzenia mogą być samoczynne wysyłanie formularzy, otwieranie nieznanych kart, przekierowania na podejrzane strony, znikające rozszerzenia, nietypowe komunikaty bezpieczeństwa lub problemy z utrzymaniem sesji mimo prawidłowej konfiguracji aplikacji.

W warszawskim serwisie komputerowym można zlecić weryfikację laptopa pod kątem oprogramowania, ustawień przeglądarki, dodatków, aktualizacji i oznak niepożądanej ingerencji. Dla laptopa przewidziana jest darmowa diagnoza LAPTOPA, co pozwala najpierw ustalić, czy źródła problemu należy szukać w urządzeniu i jego środowisku, czy raczej w kodzie, konfiguracji i infrastrukturze samej aplikacji. Taki podział jest ważny, ponieważ mechanizm tokenów, walidacja nagłówków i ustawienia ciasteczek wymagają korekty po stronie twórców lub administratorów serwisu, natomiast zainfekowany system, nieaktualna przeglądarka albo przejęte rozszerzenie powinny zostać sprawdzone lokalnie.

Przed przekazaniem urządzenia do analizy nie powinno się podawać osobom postronnym haseł, kodów jednorazowych ani danych sesyjnych. Warto zanotować moment wystąpienia problemu, adres używanej aplikacji, rodzaj wykonywanej czynności oraz komunikaty pojawiające się na ekranie. Takie informacje ułatwiają oddzielenie błędu aplikacji od problemu z komputerem i pozwalają dobrać dalsze działania, na przykład aktualizację, usunięcie podejrzanego dodatku, zmianę haseł po oczyszczeniu systemu albo przekazanie administratorowi dokładnego opisu nieprawidłowego żądania.