niezabezpieczone endpointy API

Niezabezpieczone endpointy API to adresy dostępne bez uwierzytelnienia, umożliwiające pobranie lub zmianę danych.

Jak powstaje niezabezpieczony endpoint API

Niezabezpieczony endpoint API jest adresem obsługiwanym przez aplikację, który przyjmuje żądania bez skutecznego sprawdzenia tożsamości osoby lub programu wysyłającego żądanie. Taki adres może służyć do odczytu danych, utworzenia nowego rekordu, jego modyfikacji albo usunięcia. Sam fakt, że endpoint działa przez protokół HTTP lub HTTPS, nie oznacza jeszcze, że dostęp do niego został prawidłowo ograniczony. Szyfrowanie połączenia chroni dane podczas transmisji, ale nie zastępuje uwierzytelniania ani kontroli uprawnień.

Problem może pojawić się już na etapie projektowania interfejsu. Programista może pozostawić trasę bez middleware odpowiedzialnego za logowanie, błędnie zastosować warunek sprawdzający token albo skonfigurować wyjątek dla całej grupy adresów zamiast dla jednego, jasno określonego zasobu. Niezabezpieczenie bywa również skutkiem usunięcia kontroli dostępu podczas testów i niewłączenia jej ponownie przed wdrożeniem. Osobną kategorią jest endpoint, który wymaga zalogowania, ale nie sprawdza, czy zalogowany użytkownik ma prawo do konkretnego obiektu.

Uwierzytelnianie nie zastępuje autoryzacji

Uwierzytelnianie odpowiada na pytanie, kto wysyła żądanie, natomiast autoryzacja określa, jakie operacje ta osoba lub usługa może wykonać. Endpoint może więc wymagać poprawnego tokenu dostępu, a mimo to pozostawać logicznie niezabezpieczony, jeśli przyjmuje identyfikator dowolnego rekordu i nie porównuje go z zakresem uprawnień właściciela. Przykładem jest żądanie typu GET /api/orders/1842, które po samym sprawdzeniu ważności sesji zwraca zamówienie należące do innego konta.

W praktyce należy sprawdzać zarówno obecność i ważność poświadczeń, jak i ich zakres. Token powinien być weryfikowany pod kątem podpisu, wystawcy, odbiorcy oraz czasu ważności, jeżeli dany mechanizm takich pól używa. Następnie aplikacja powinna ustalić, czy wskazana rola, zakres lub relacja z zasobem pozwala na wykonanie konkretnej operacji. Kontrola musi obejmować wszystkie metody HTTP, ponieważ zabezpieczenie GET nie zabezpiecza automatycznie odpowiadających mu tras POST, PUT, PATCH i DELETE.

Skutki błędnej kontroli dostępu

Publicznie dostępny endpoint może ujawniać dane zwracane w odpowiedzi JSON, metadane zasobów, identyfikatory obiektów albo informacje diagnostyczne. Jeżeli pozwala także na zapis, osoba nieuprawniona może tworzyć rekordy, zmieniać ustawienia lub usuwać dane. Skala problemu zależy od tego, jakie operacje wykonuje dana trasa oraz czy backend korzysta z dodatkowych ograniczeń. Szczególnie ryzykowne są endpointy administracyjne, trasy obsługujące konta użytkowników i funkcje, które uruchamiają kosztowne albo nieodwracalne działania.

Błędu nie należy oceniać wyłącznie na podstawie tego, czy adres jest łatwy do odgadnięcia. Ukrycie endpointu pod nietypową ścieżką nie jest mechanizmem bezpieczeństwa, ponieważ adres może zostać ujawniony w kodzie aplikacji, dokumentacji, komunikatach błędów, historii przeglądarki lub logach. Znaczenie ma również możliwość masowego odpytywania. Brak limitu żądań może ułatwić automatyczne sprawdzanie identyfikatorów, pobieranie dużej liczby odpowiedzi albo wielokrotne wykonywanie operacji zmieniających stan aplikacji.

Weryfikacja endpointów i przywracanie kontroli dostępu

Diagnostyka powinna rozpocząć się od spisu tras, ich metod, wymaganych nagłówków oraz operacji wykonywanych po stronie serwera. Każdy endpoint należy sprawdzić w kilku wariantach: bez nagłówka autoryzacyjnego, z tokenem nieważnym, z tokenem użytkownika o ograniczonych uprawnieniach oraz z poprawnym tokenem właściciela zasobu. Należy porównać kody odpowiedzi, treść komunikatów i skutki uboczne, a przy operacjach zapisu potwierdzić, czy stan danych rzeczywiście się zmienił. Testy powinny obejmować także różne identyfikatory obiektów, aby wykryć brak kontroli dostępu na poziomie pojedynczego rekordu.

Naprawa polega na wymuszeniu uwierzytelniania w centralnym mechanizmie obsługi tras, dodaniu autoryzacji zależnej od operacji i zasobu oraz ograniczeniu danych zwracanych przez API do niezbędnych pól. Warto rozdzielić uprawnienia od samego faktu zalogowania, stosować jednoznaczne kody 401 dla braku poprawnego uwierzytelnienia i 403 dla odmowy dostępu po prawidłowym rozpoznaniu klienta. Po zmianach potrzebne są testy regresyjne dla wszystkich metod i scenariuszy negatywnych. Diagnostyka komputera używanego do pracy z aplikacją może wykazać problemy z konfiguracją środowiska, lecz przywrócenie ochrony endpointu wymaga sprawdzenia kodu, konfiguracji oraz działania samej aplikacji.