podatność na injection (np. przez dane z webhooka)

Podatność na injection przez dane z webhooka to brak walidacji treści powiadomienia przed jej przetworzeniem.

Na czym polega injection w danych z webhooka

Webhook jest mechanizmem, w którym jedna aplikacja wysyła żądanie HTTP do adresu udostępnionego przez inną aplikację. Treść takiego żądania może zawierać nagłówki, parametry, dane JSON, identyfikator zdarzenia, nazwę użytkownika, opis operacji albo wartości pochodzące z formularza. Podatność na injection występuje wtedy, gdy odebrane dane są traktowane jako część polecenia lub wyrażenia wykonywanego przez inny komponent, zamiast jako zwykłe wartości. Sam fakt użycia webhooka nie powoduje injection; problemem jest sposób przetwarzania jego zawartości.

Przykładem jest połączenie wartości z webhooka z tekstem zapytania do bazy danych, komendy systemowej, wyrażenia szablonu lub zapytania do innego interpretera. Jeżeli aplikacja buduje taki tekst przez konkatenację, specjalnie przygotowany fragment danych może zmienić znaczenie całej instrukcji. Skutkiem może być odczyt nieprzewidzianych rekordów, zmiana danych, wykonanie dodatkowej operacji albo ujawnienie informacji w komunikacie błędu. Zakres skutków zależy od użytego interpretera, uprawnień procesu i tego, jakie działania wykonuje odbiorca webhooka.

Dlaczego walidacja samej treści powiadomienia ma znaczenie

Walidacja powinna sprawdzać, czy żądanie ma oczekiwany format, typy danych, długości pól i dopuszczalne wartości. Dla zdarzenia JSON można określić wymagane pola, odrzucać nieznane lub niepotrzebne elementy, ograniczyć długość tekstu oraz wymagać, aby identyfikatory miały określony format. Walidacja składni JSON nie wystarcza, ponieważ poprawny składniowo tekst może nadal zawierać znaki i wartości niebezpieczne dla kolejnego interpretera. Każde pole powinno być oceniane w kontekście miejsca, do którego później trafi.

Podpis cyfrowy lub podpis HMAC webhooka służy do sprawdzenia autentyczności i integralności żądania, ale nie zastępuje ochrony przed injection. Zaufany nadawca może przekazać dane wprowadzone wcześniej przez użytkownika, a poprawnie podpisana wiadomość nadal może zawierać tekst powodujący niepożądane działanie po stronie odbiorcy. Odbiorca powinien więc najpierw zweryfikować podpis zgodnie z dokumentacją dostawcy, a następnie zastosować walidację schematu i bezpieczne przekazywanie wartości do dalszych komponentów. Warto także kontrolować identyfikator zdarzenia oraz zabezpieczać się przed ponownym przetworzeniem tego samego powiadomienia.

Bezpieczne przekazywanie wartości do bazy, poleceń i logów

Przy pracy z bazą danych należy używać zapytań parametryzowanych albo mechanizmu przygotowanych instrukcji, w którym dane są przekazywane jako parametry, a nie dopisywane do tekstu zapytania. Zwykłe usuwanie pojedynczych znaków lub zastępowanie wybranych fragmentów tekstu nie daje takiej gwarancji, ponieważ poprawne zabezpieczenie zależy od konkretnego języka zapytań i sposobu jego użycia. Nazwy kolumn, sortowanie i inne elementy, których nie można przekazać jako parametrów, powinny być wybierane z zamkniętej listy dozwolonych wartości.

Jeżeli dane z webhooka są używane przy uruchamianiu programu, bezpieczniejszym rozwiązaniem jest przekazanie argumentów jako osobnych elementów tablicy do interfejsu procesu, bez uruchamiania pośredniej powłoki. Nie należy traktować odebranego tekstu jako fragmentu polecenia, nazwy pliku wykonywalnego ani ścieżki bez ścisłego sprawdzenia. Podobna zasada dotyczy szablonów, nagłówków HTTP, adresów URL i zapytań do innych usług: dane należy kodować lub przekazywać metodą właściwą dla danego kontekstu, a nie jednym uniwersalnym filtrem.

Logowanie również wymaga kontroli. Wartości z webhooka mogą zawierać znaki nowej linii, sekwencje sterujące albo tekst imitujący wpisy systemowe. Przed zapisaniem ich do logu należy ograniczyć format i długość oraz stosować strukturę, na przykład pola JSON obsługiwane przez narzędzie logujące. Log nie powinien być jedynym miejscem wykrywania problemu. Należy rejestrować odrzucenie nieprawidłowego żądania, wynik weryfikacji podpisu, identyfikator zdarzenia i bezpieczny kod błędu, bez zapisywania pełnych sekretów lub nieprzefiltrowanej treści.

Objawy podatności i działania naprawcze na komputerze

W praktyce podejrzenie injection może pojawić się, gdy odbiorca webhooka zwraca błędy interpretera po otrzymaniu określonej wartości, wykonuje operację inną niż wynika ze zdarzenia, zapisuje nietypowe wpisy w logach albo przetwarza pole zawierające znacznie dłuższy tekst niż przewiduje dokumentacja. Do sprawdzenia potrzebne są logi aplikacji, kod handlera webhooka, konfiguracja tras oraz informacje o tym, jakie biblioteki wykonują zapytania, polecenia lub renderowanie szablonów. Testy powinny odbywać się w kontrolowanym środowisku i na kopii danych, z użyciem nieszkodliwych wartości testowych.

Naprawa polega na rozdzieleniu danych od instrukcji, wprowadzeniu walidacji po stronie serwera, ograniczeniu uprawnień procesu i dodaniu testów negatywnych dla pól odbieranych z webhooka. Należy także sprawdzić, czy aplikacja poprawnie odrzuca nieprawidłowy typ danych, zbyt długi tekst, brak wymaganych pól, nieaktualny podpis i powtórzone zdarzenie.