CSRF tokens to tokeny zabezpieczające formularze i żądania przed wykonaniem niechcianej operacji z wykorzystaniem sesji użytkownika. Serwer sprawdza przesłaną wartość, zanim zaakceptuje chronioną zmianę. W sklepie internetowym pomaga to chronić na przykład zmianę danych konta. Komunikat o błędnym tokenie oznacza odrzucenie żądania, ale sam w sobie nie świadczy o ataku.
Dla właściciela sklepu ważne są zarówno skuteczność zabezpieczenia, jak i możliwość poprawnego wysłania formularza przez klienta. Jeśli błędy utrudniają zakupy lub obsługę kont, audyt bezpieczeństwa Magento może objąć sprawdzenie formularzy, sesji i działania dodatkowych modułów. Samo ukrycie komunikatu nie rozwiązuje przyczyny problemu.
Jak działają CSRF tokens w formularzu sklepu?
Przy otwieraniu chronionego formularza aplikacja udostępnia przeglądarce token. Po zatwierdzeniu formularza przeglądarka przesyła go razem z danymi, a serwer sprawdza jego poprawność. W zależności od rozwiązania wartość może znajdować się w ukrytym polu formularza albo w nagłówku żądania.
Token nie jest hasłem klienta ani potwierdzeniem jego uprawnień. Stanowi dodatkowy warunek przyjęcia operacji: aplikacja nadal musi rozpoznać użytkownika, sprawdzić dostęp do danych i zweryfikować przesłane informacje. Poprawny token nie daje prawa do edycji cudzego zamówienia.
Istotna jest kontrola po stronie serwera. Pole widoczne w kodzie formularza nie dowodzi, że zabezpieczenie działa, ponieważ aplikacja mogłaby je ignorować. Rzetelna weryfikacja obejmuje również sprawdzenie, czy żądanie bez wymaganej wartości lub ze zmienioną wartością zostaje odrzucone.
Na czym polega atak CSRF w sklepie internetowym?
CSRF to skrót od Cross-Site Request Forgery. Atak polega na skłonieniu przeglądarki użytkownika do wysłania niechcianego żądania do serwisu, w którym użytkownik ma aktywną sesję. Przeglądarka może dołączyć do takiego żądania dane sesji, jeśli pozwalają na to jej ustawienia oraz konfiguracja ciasteczek.
Przykładem jest próba wymuszenia zmiany danych konta po wejściu na przygotowaną przez napastnika stronę. Problem pojawia się wtedy, gdy sklep uznaje samą obecność zalogowanej sesji za wystarczające potwierdzenie zamiaru użytkownika. Token pomaga odróżnić żądanie zawierające wymagane potwierdzenie od żądania, które go nie ma.
Atakujący nie musi przy tym znać hasła ofiary. CSRF nie jest też tym samym co odczyt danych konta: jego celem jest przede wszystkim wywołanie operacji. Zakres możliwych szkód zależy od tego, jakie działania aplikacja przyjmuje bez odpowiedniej weryfikacji.
Kiedy formularz wymaga ochrony przed CSRF?
Szczególnej uwagi wymagają operacje zmieniające dane lub ustawienia, gdy aplikacja rozpoznaje użytkownika na podstawie automatycznie przesyłanych ciasteczek sesyjnych. Dotyczy to między innymi edycji adresu, zmiany danych konta i działań w panelu administracyjnym. Ochrona powinna obejmować również własne formularze dodane przez rozszerzenia.
Nie każde żądanie w sklepie korzysta jednak z identycznego mechanizmu. Integracja serwerowa uwierzytelniana osobnym kluczem ma inne warunki działania niż formularz otwarty w przeglądarce klienta. Dlatego decyzja o zabezpieczeniu wymaga ustalenia, kto wysyła żądanie, jak jest rozpoznawany i co może ono zmienić.
HTTPS chroni transmisję, ale sam nie potwierdza, że użytkownik chciał wykonać daną operację. Ustawienia ciasteczek SameSite i kontrola pochodzenia żądania mogą stanowić dodatkowe warstwy ochrony. Nie należy jednak zakładać, że obecność certyfikatu albo zapory automatycznie rozwiązuje problem CSRF we wszystkich formularzach.
Co oznaczają błędny token CSRF i CSRF token mismatch?
Komunikat o błędnym tokenie oznacza, że aplikacja nie mogła zaakceptować wartości przesłanej z formularzem. CSRF token mismatch wskazuje na niezgodność tokena z tym, czego oczekuje aplikacja. Dokładne znaczenie komunikatu zależy od zastosowanego mechanizmu i miejsca wystąpienia błędu.
Częstą sytuacją jest wysłanie formularza pozostawionego w otwartej karcie po zmianie lub zakończeniu sesji. Podobny efekt może dać formularz przywrócony przyciskiem Wstecz albo strona zawierająca nieaktualną wartość z pamięci podręcznej. Nie oznacza to, że każdy token musi mieć taki sam czas ważności lub zmieniać się przy każdym wysłaniu.
Problem może też wynikać z dodatkowego modułu, który nie przesyła wymaganego pola, albo ze skryptu wysyłającego formularz niezgodnie z mechanizmem platformy. Jeśli przeglądarka nie przekazuje oczekiwanego ciasteczka sesyjnego, serwer może nie powiązać żądania z właściwą sesją. Sam tekst błędu nie wystarcza do wyboru poprawki.
Co zrobić po zobaczeniu błędu podczas zakupów?
Klient potrzebuje przede wszystkim bezpiecznej drogi powrotu do zakupów. Przed ponownym zatwierdzeniem formularza warto ustalić, czy poprzednia operacja została wykonana, zwłaszcza gdy komunikat pojawił się przy składaniu zamówienia. Wielokrotne naciskanie przycisku nie jest dobrą metodą diagnozy.
- Sprawdź, czy zamówienie lub zmiana danych są już widoczne na koncie i czy pojawiło się potwierdzenie operacji.
- Otwórz ponownie stronę formularza, aby pobrać jego aktualną wersję. W razie zakończenia sesji zaloguj się ponownie.
- Wprowadź dane ponownie, jeśli jest to potrzebne, i wykonaj operację po sprawdzeniu jej wcześniejszego statusu.
- Jeśli błąd wraca, zgłoś obsłudze adres strony, wykonywaną czynność i treść komunikatu, bez przesyłania haseł ani tokenów.
Usuwanie ciasteczek może zakończyć sesję i zmienić zawartość koszyka, dlatego nie powinno być automatyczną pierwszą poradą dla każdego klienta. Podobnie test w innym oknie przeglądarki pomaga zawęzić problem, ale nie wyjaśnia jego przyczyny. Powtarzające się zgłoszenia wymagają sprawdzenia sklepu, nawet jeśli odświeżenie strony chwilowo pomaga.
Jak właściciel sklepu powinien zlecić diagnostykę?
Przydatne zgłoszenie opisuje przebieg czynności, a nie tylko zawiera zrzut komunikatu. Warto wskazać, czy problem dotyczy klienta zalogowanego, zakupów bez konta, panelu administracyjnego czy konkretnego formularza. Znaczenie ma też to, czy błąd pojawia się od razu, czy po pozostawieniu otwartej karty.
Należy zanotować, czy przed wystąpieniem problemu zmieniono szablon, dodano rozszerzenie albo ustawienia pamięci podręcznej. Taka zbieżność jest wskazówką do sprawdzenia, a nie dowodem winy danego elementu. Zgłoszenie nie powinno zawierać pełnych ciasteczek, tokenów ani danych klientów, jeśli nie są potrzebne do bezpiecznej analizy.
W przypadku sklepu opartego na WordPressie audyt działania WooCommerce może uwzględnić współpracę formularzy, wtyczek i mechanizmów sesji. W obu platformach warto przekazać wykonawcy konkretny scenariusz odtworzenia błędu. Informacja, że problem występuje po powrocie z innej zakładki, bywa bardziej użyteczna niż ogólne stwierdzenie, że koszyk nie działa.
Co sprawdzić w Magento i WooCommerce?
W Magento mechanizm ochrony formularzy wykorzystuje między innymi pole form_key. Własny moduł lub zmieniony szablon powinien współpracować z zabezpieczeniami platformy, zamiast je omijać. Kontrola powinna objąć zarówno obecność wymaganej wartości, jak i jej faktyczne sprawdzanie przy obsłudze operacji.
W WordPressie i WooCommerce spotkasz mechanizm nonce. Pomaga on zabezpieczać określone działania, ale nie zastępuje sprawdzania uprawnień i nie należy traktować go jako gwarancji jednokrotnego wykonania operacji. Nazwy pól i sposób przesyłania zabezpieczenia zależą od formularza oraz użytych rozszerzeń.
Jeśli problem ujawnił się po zmianie wyglądu sklepu, trzeba przetestować rzeczywiste wysyłanie formularzy, także obsługiwanych bez przeładowania strony. Sam poprawny wygląd przycisku lub koszyka nie potwierdza zgodności z mechanizmem sesji. Przy planowaniu aktualizacji sklepu Magento warto uwzględnić takie scenariusze w odbiorze prac.
Jak sprawdzić poprawkę bez osłabiania zabezpieczeń?
Odbiór poprawki powinien potwierdzać dwa zachowania: prawidłowe żądanie działa, a nieprawidłowe zostaje odrzucone. Najlepiej przeprowadzić próby w środowisku testowym, na kontach i danych przeznaczonych do weryfikacji. Sprawdzanie wyłącznie tego, czy zniknął komunikat, mogłoby przeoczyć wyłączenie ochrony.
Warto odtworzyć również sytuację, która wcześniej powodowała problem: dłużej otwartą kartę, zmianę sesji lub powrót do formularza. Jeżeli przyczyną była pamięć podręczna, poprawka powinna zapobiegać udostępnianiu niewłaściwych danych formularza innym sesjom. Zbiorcze wyłączenie pamięci podręcznej może ukryć objaw i pogorszyć działanie sklepu, zamiast naprawić konkretną konfigurację.
Nie należy usuwać walidacji tokena tylko dlatego, że blokuje część zamówień. Wyłączenie kontroli zamienia widoczny błąd w ryzyko przyjmowania niechcianych operacji. Poprawka powinna przywrócić zgodność formularza, sesji i kontroli serwera oraz pozostawić klientowi zrozumiały komunikat, gdy formularz wymaga ponownego otwarcia.
Jak SISL może pomóc?
SISL zajmuje się audytami, aktualizacjami i opieką nad sklepami Magento oraz WooCommerce. Jeśli błędy tokenów utrudniają zakupy, wsparcie techniczne Magento jest odpowiednią usługą do omówienia diagnostyki formularzy i modułów. Przy zgłoszeniu podaj miejsce wystąpienia błędu oraz czynności, które do niego prowadzą.
Najczęstsze pytania
Co to jest token CSRF?
Token CSRF jest wartością dołączaną do formularza lub żądania, którą serwer sprawdza przed wykonaniem chronionej operacji. Pomaga zablokować działania wymuszone przez obcą stronę z wykorzystaniem zalogowanej przeglądarki użytkownika. Nie zastępuje hasła ani sprawdzania uprawnień.
Co oznacza błędny token CSRF?
Komunikat oznacza, że aplikacja nie zaakceptowała wartości wymaganej do potwierdzenia żądania. Przyczyną może być nieaktualny formularz, zakończona sesja albo problem z pamięcią podręczną. Sam komunikat nie dowodzi włamania ani nie wskazuje jednoznacznie uszkodzonego elementu sklepu.
Co znaczy CSRF token mismatch?
CSRF token mismatch oznacza niezgodność tokena przesłanego w żądaniu z wartością lub warunkami oczekiwanymi przez aplikację. Warto otworzyć formularz ponownie, a przed powtórzeniem zamówienia sprawdzić jego status. Jeśli błąd wraca, potrzebna jest diagnostyka sesji i formularza.
Na czym polega atak CSRF?
Atak CSRF polega na nakłonieniu przeglądarki użytkownika do wysłania niechcianego żądania do serwisu, w którym użytkownik jest zalogowany. Atakujący próbuje wykorzystać istniejącą sesję do wykonania operacji. Poprawnie sprawdzany token pomaga odrzucić takie żądanie.