nieautoryzowane wywołanie webhooka

Nieautoryzowane wywołanie webhooka to przyjęcie powiadomienia bez weryfikacji podpisu lub źródła żądania.

Jak rozpoznać nieautoryzowane wywołanie webhooka

Webhook jest żądaniem HTTP wysyłanym automatycznie przez jeden system do adresu URL udostępnionego przez drugi system. Może informować o utworzeniu zamówienia, zmianie statusu płatności, zakończeniu zadania albo wystąpieniu zdarzenia w aplikacji. Sam fakt odebrania żądania przez serwer nie potwierdza jednak, że zostało ono wysłane przez oczekiwanego nadawcę. Nieautoryzowane wywołanie webhooka występuje wtedy, gdy aplikacja przyjmuje dane bez sprawdzenia podpisu kryptograficznego, tokenu, adresu źródłowego lub innego mechanizmu przewidzianego w konfiguracji integracji.

Atakujący może wysłać żądanie bezpośrednio na publiczny adres webhooka, używając narzędzia takiego jak curl, przeglądarka z dodatkiem do modyfikowania żądań albo własny skrypt. Jeżeli endpoint nie sprawdza autentyczności nadawcy, może potraktować spreparowane dane jak prawdziwe zdarzenie. Skutkiem może być zmiana stanu rekordu, uruchomienie zadania, wysłanie powiadomienia, wielokrotne naliczenie operacji lub zapis nieprawidłowych informacji w bazie danych. Problem dotyczy więc nie tylko samego ruchu sieciowego, lecz także wszystkich czynności wykonywanych po pomyślnym odebraniu żądania.

Podpis żądania, sekret i kolejność weryfikacji

Najczęściej stosowanym mechanizmem ochrony jest podpis HMAC obliczany z użyciem wspólnego sekretu znanego nadawcy i odbiorcy. Nadawca wylicza skrót z dokładnego surowego ciała żądania, a następnie umieszcza wynik w nagłówku, na przykład X-Signature. Odbiorca musi użyć tego samego sekretu i tych samych bajtów danych. Nie powinien najpierw zmieniać formatowania JSON, kolejności elementów lub kodowania, a dopiero później obliczać podpisu, ponieważ nawet pozornie nieistotna zmiana powoduje inny wynik HMAC. W praktyce używa się funkcji z rodziny HMAC-SHA-256, jeżeli taki algorytm określa dokumentacja konkretnej integracji.

Weryfikację podpisu należy wykonać przed przetworzeniem danych i przed wywołaniem operacji powodującej zmianę stanu. Porównanie wartości powinno być odporne na różnice czasu wykonania, dlatego aplikacje stosują porównanie stałoczasowe, dostępne między innymi jako hmac.compare_digest w Pythonie. Oprócz podpisu można sprawdzać znacznik czasu i identyfikator zdarzenia. Ograniczenie dopuszczalnego czasu, na przykład do kilku minut zgodnie z wymaganiami dostawcy, utrudnia ponowne wykorzystanie przechwyconego żądania. Identyfikator zdarzenia pozwala odrzucić ten sam komunikat przesłany drugi raz, gdy integracja wymaga przetwarzania jednokrotnego.

Skutki błędnej obsługi endpointu HTTP

Nieautoryzowane wywołanie może być wynikiem kilku odrębnych błędów. Endpoint może nie wymagać żadnego uwierzytelnienia, akceptować podpis w dowolnym formacie, porównywać podpis z przetworzonym zamiast surowego ciała albo używać pustego, domyślnego lub ujawnionego sekretu. Błędem jest również uznawanie nagłówka Host, pola User-Agent lub adresu IP przesłanego w nagłówku X-Forwarded-For za samodzielny dowód tożsamości nadawcy. Takie wartości mogą zostać zmienione przez klienta, a nagłówki związane z przekazywaniem ruchu są wiarygodne dopiero wtedy, gdy aplikacja zna i kontroluje zaufane proxy.

Objawy problemu można znaleźć w logach aplikacji i serwera HTTP. Warto porównać kod odpowiedzi, metodę żądania, ścieżkę, czas, identyfikator zdarzenia, obecność nagłówka podpisu oraz wynik walidacji. Szczególną uwagę należy zwrócić na żądania zakończone kodem 2xx, mimo że podpis był pusty, niezgodny albo nie został w ogóle przesłany. Powtarzające się żądania z innym ciałem, lecz tym samym identyfikatorem zdarzenia, wskazują na brak ochrony przed replayem lub brak idempotencji. Sam adres IP nie wystarcza do potwierdzenia ataku, ale zestawienie go z niepoprawnym podpisem i wykonanymi operacjami pozwala odtworzyć przepływ danych.

Bezpieczne sprawdzenie konfiguracji na laptopie lub komputerze

Podczas diagnostyki z komputera użytkownika należy ustalić, która aplikacja wysyła lub odbiera żądania, jaki adres URL jest skonfigurowany oraz czy ruch odbywa się przez HTTPS. Można sprawdzić ustawienia integracji, certyfikat połączenia, reguły zapory i logi klienta, ale nie należy ujawniać sekretu webhooka w zgłoszeniu, zrzucie ekranu ani publicznym repozytorium. Test powinien używać środowiska testowego i kontrolnego komunikatu, a nie ponownie wysyłać produkcyjnego zdarzenia. Po zmianie sekretu trzeba zaktualizować obie strony integracji i zweryfikować, że stare podpisy są odrzucane.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i podzespołów, dlatego podczas problemów z aplikacją kliencką może sprawdzić lokalne połączenie sieciowe, konfigurację systemu, działanie przeglądarki oraz logi dostępne na urządzeniu. Taka diagnostyka pomaga rozdzielić awarię komputera lub sieci od błędu po stronie zdalnego endpointu webhooka. Jeżeli serwer przyjmuje niepodpisane żądania, konieczna jest również korekta konfiguracji i kodu po stronie systemu, który ten endpoint udostępnia. Prawidłowy rezultat testu to odrzucenie żądania z brakującym lub niepoprawnym podpisem przed wykonaniem jakiejkolwiek operacji biznesowej.