brak zabezpieczeń przed powtórzeniem żądania

Brak zabezpieczeń przed powtórzeniem żądania to luka bezpieczeństwa umożliwiająca wielokrotne przetworzenie tego samego, przechwyconego zapytania.

Brak zabezpieczeń przed powtórzeniem żądania – na czym polega problem

Brak zabezpieczeń przed powtórzeniem żądania oznacza sytuację, w której aplikacja przyjmuje ponownie ten sam komunikat i traktuje go tak, jakby był nową, prawidłową operacją. Nie musi przy tym dochodzić do zmiany treści żądania. Wystarczy, że wcześniej przesłany komunikat zostanie zapisany, skopiowany albo przechwycony, a następnie wysłany jeszcze raz w odpowiednim momencie. Jeżeli system nie rozpoznaje, że dana operacja została już wykonana, może ponownie zmienić stan konta, uruchomić działanie administracyjne, utworzyć kolejny rekord albo powtórzyć zlecenie.

Istotą luki nie jest samo ponowne wysłanie danych, ponieważ powtórzenia mogą występować także podczas zwykłych problemów z połączeniem. Kłopot zaczyna się wtedy, gdy po stronie aplikacji brakuje mechanizmu odróżniającego pierwszą próbę wykonania operacji od kolejnej próby dotyczącej dokładnie tego samego zdarzenia. Szczególne znaczenie ma to przy żądaniach, które nie tylko odczytują informacje, lecz także wywołują skutek: zapisują dane, zatwierdzają płatność, zmieniają uprawnienia, generują dokument lub wysyłają komunikat.

Podatność może wystąpić w aplikacji internetowej, programie instalowanym na komputerze, urządzeniu sieciowym, systemie obsługi zamówień oraz w usługach komunikujących się między sobą. Wykorzystanie nie zawsze wymaga przejęcia konta. W niektórych przypadkach wystarcza dostęp do własnej sesji, możliwość ponowienia własnego żądania albo obserwacja ruchu generowanego przez używany program. Z tego powodu problem powinien być traktowany jako kwestia integralności operacji, a nie wyłącznie jako błąd interfejsu.

Powtórzenie żądania a inne błędy obsługi operacji

Brak zabezpieczeń przed powtórzeniem żądania warto odróżnić od kilku podobnych zjawisk. Błąd uwierzytelniania dotyczy ustalenia, kto wykonuje operację, natomiast omawiana luka dotyczy tego, czy ta sama operacja może zostać zaakceptowana ponownie. Prawidłowo rozpoznana sesja użytkownika nie wystarcza, jeżeli aplikacja nie potrafi sprawdzić, czy komunikat oznaczony jako konkretne zdarzenie był już obsłużony.

Inny przypadek stanowi brak idempotencji. Operacja idempotentna po wielokrotnym wykonaniu prowadzi do tego samego stanu, choć technicznie komunikat może zostać przyjęty kilka razy. Przykładowo ponowne ustawienie tej samej wartości nie musi powodować szkody. Z kolei operacja polegająca na dodaniu elementu, zwiększeniu licznika lub wysłaniu dyspozycji może wywołać nowy skutek przy każdym powtórzeniu. Nie każda nieidempotentna funkcja jest wadliwa, ale powinna mieć wyraźnie zaprojektowany mechanizm kontroli ponowień.

Powtórzenie komunikatu może też wynikać z legalnego ponowienia po przekroczeniu czasu oczekiwania. Użytkownik może nie otrzymać odpowiedzi, mimo że pierwsza próba została już zapisana. Kliknięcie przycisku ponownie albo automatyczna próba po stronie programu może wtedy wykonać tę samą czynność drugi raz. Dojrzałe rozwiązanie nie zakłada, że klient zawsze wie, czy operacja się udała. Przyjmuje możliwość ponowienia i bezpiecznie rozstrzyga, czy należy zwrócić wcześniejszy rezultat, czy odrzucić kolejną próbę.

Nie powinno się również utożsamiać tego problemu z przechowywaniem historii żądań w dziennikach. Sam zapis zdarzenia pomaga w analizie, lecz nie chroni operacji. Potrzebna jest kontrola wykonywana przed ponownym zastosowaniem skutku, z uwzględnieniem użytkownika, rodzaju działania, identyfikatora operacji i czasu ważności. Dopiero połączenie tych elementów pozwala ograniczyć ryzyko wielokrotnego przetworzenia tego samego komunikatu.

Typowe problemy wywoływane przez wielokrotne żądanie

Skutki zależą od tego, co wykonuje aplikacja. Przy procesach zakupowych lub rozliczeniowych może dojść do podwójnego zapisania dyspozycji, powielenia zamówienia albo wielokrotnego naliczenia operacji. W obszarze obsługi użytkowników problem może skutkować utworzeniem wielu kont, ponownym wysłaniem wiadomości, wielokrotnym nadaniem uprawnienia lub niekontrolowanym zwiększeniem liczby zgłoszeń. W systemach magazynowych mogą pojawić się powielone dokumenty, rozbieżności stanów i trudne do odtworzenia różnice między rejestrem a rzeczywistym przebiegiem czynności.

Ryzyko rośnie, gdy żądanie zawiera trwałą zmianę, a odpowiedź nie pozwala jednoznacznie potwierdzić, czy zmiana została wykonana. Dotyczy to także operacji uruchamianych z aplikacji działających w tle. Przerwanie programu, uśpienie komputera, chwilowa utrata połączenia lub błąd pośredniego komponentu może spowodować ponowienie komunikatu bez pełnej wiedzy osoby korzystającej z systemu.

Do sygnałów ostrzegawczych należą duplikaty danych powstające bez świadomego działania, różne rezultaty po wysłaniu identycznego komunikatu, powtarzające się wpisy w historii, wielokrotne wiadomości potwierdzające tę samą czynność oraz rozbieżność między liczbą prób a liczbą zapisanych operacji. Niepokój powinno wzbudzić również to, że po odświeżeniu strony lub ponownym uruchomieniu programu operacja zostaje wykonana jeszcze raz, zamiast zostać rozpoznana jako już zakończona.

Ocena skutków wymaga prześledzenia całego przebiegu: utworzenia komunikatu, jego przesłania, odebrania, zapisania, wykonania oraz zwrócenia odpowiedzi. Błąd może znajdować się zarówno w aplikacji użytkownika, jak i w komponencie przyjmującym dane. Samo usunięcie duplikatów po fakcie nie rozwiązuje przyczyny, ponieważ kolejne powtórzenie może ponownie doprowadzić do niespójności.

Praktyczne wskazówki dotyczące zabezpieczenia przed powtórzeniem żądania

Podstawowym rozwiązaniem jest nadawanie każdej operacji unikatowego identyfikatora, który pozostaje związany z konkretnym działaniem. Przy ponownym otrzymaniu tego samego identyfikatora system powinien sprawdzić, czy operacja została już wykonana. Jeżeli tak, można zwrócić zapisany rezultat albo czytelny komunikat o wcześniejszym przetworzeniu. Sam identyfikator nie powinien być jedynym zabezpieczeniem, ponieważ trzeba jeszcze powiązać go z właściwym użytkownikiem, zakresem uprawnień oraz parametrami operacji.

Ważne jest atomowe zapisywanie informacji o przetwarzaniu. Oznacza to, że kontrola identyfikatora i utworzenie zapisu nie powinny być rozdzielone w sposób umożliwiający dwóm równoczesnym żądaniom przejście przez tę samą kontrolę. Należy także ustalić czas przechowywania identyfikatorów, zasady obsługi nieudanych prób oraz sposób postępowania, gdy pierwsza operacja jest jeszcze wykonywana. W niektórych przypadkach przydatny będzie stan „w toku”, który powstrzyma równoległe wykonanie tej samej czynności.

W formularzach i aplikacjach użytkowych pomocne bywają blokowanie wielokrotnego kliknięcia, oznaczenie trwającego przetwarzania oraz bezpieczne przekierowanie po zapisaniu danych. Są to jednak środki uzupełniające. Nie można zakładać, że osoba korzystająca z programu kliknie przycisk tylko raz, ponieważ ponowienie może zostać wykonane automatycznie przez aplikację albo nastąpić wskutek problemu komunikacyjnego.

Podczas sprawdzania rozwiązania należy testować szybkie wielokrotne wysłanie tego samego komunikatu, ponowienie po opóźnieniu odpowiedzi, równoczesne próby z kilku okien, przerwanie połączenia po wysłaniu oraz ponowne uruchomienie programu. Warto porównać logi, zapisane rekordy i odpowiedzi zwracane klientowi. Test powinien obejmować zarówno poprawne wykonanie, jak i przypadki częściowej awarii, aby sprawdzić, czy system nie pozostawia operacji w stanie niejednoznacznym.

Kiedy zgłosić brak zabezpieczeń przed powtórzeniem żądania do serwisu

Do serwisu warto zgłosić się wtedy, gdy powielanie operacji występuje po ponownym kliknięciu, odświeżeniu strony, chwilowej utracie połączenia albo wznowieniu pracy programu. Pomocne będzie przygotowanie opisu kolejnych czynności, przybliżonego czasu wystąpienia, rodzaju używanego programu oraz informacji, czy powtórzenie pojawia się zawsze, czy tylko w określonych warunkach. Nie należy przesyłać haseł, kodów jednorazowych ani pełnych danych uwierzytelniających.

W przypadku komputera objawy mogą być mylone z awarią programu, uszkodzeniem profilu użytkownika, problemem z przeglądarką albo niestabilnością połączenia. Diagnostyka powinna więc objąć zachowanie aplikacji, stan systemu, zapisane komunikaty błędów i sposób ponawiania operacji. Jeżeli problem pojawia się tylko na jednym urządzeniu, trzeba sprawdzić konfigurację i oprogramowanie tego stanowiska. Jeżeli występuje na wielu urządzeniach, bardziej prawdopodobna staje się wada samej usługi lub jej sposobu przetwarzania żądań.

Warszawskie Pogotowie Komputerowe 24/7 może pomóc w uporządkowaniu objawów dotyczących laptopa i komputera PC, przygotowaniu materiału do dalszej analizy oraz sprawdzeniu, czy źródłem problemu jest urządzenie, program lub sposób komunikacji. Przed przekazaniem sprzętu zaleca się wykonanie kopii ważnych danych i zanotowanie dokładnego przebiegu zdarzenia. Dzięki temu łatwiej odtworzyć warunki, w których pojawia się wielokrotne przetworzenie komunikatu, a następnie przekazać administratorowi lub twórcy aplikacji precyzyjną informację o zaobserwowanej luce.