możliwość pobrania danych przez nieautoryzowany token

Pobranie danych przez nieautoryzowany token to podatność, w której API akceptuje klucz bez sprawdzenia jego uprawnień.

Na czym polega pobranie danych przez nieautoryzowany token

Możliwość pobrania danych przez nieautoryzowany token oznacza błąd w kontroli dostępu API. Token jest ciągiem znaków przedstawianym przez aplikację przy żądaniu do interfejsu programistycznego. Może potwierdzać tożsamość użytkownika, aplikacji albo konkretnej sesji, ale samo jego przesłanie nie powinno automatycznie oznaczać prawa do odczytu wszystkich zasobów. Podatność występuje wtedy, gdy serwer przyjmuje token bez prawidłowego sprawdzenia jego ważności, zakresu uprawnień, odbiorcy, czasu obowiązywania albo powiązania z żądanym zasobem.

W praktyce atakujący może uzyskać token ujawniony w kodzie aplikacji, historii przeglądarki, logu, parametrze adresu URL, pamięci procesu albo podczas przejęcia sesji. Następnie wysyła żądanie do właściwego punktu końcowego API. Jeżeli serwer sprawdza tylko obecność nagłówka autoryzacyjnego, lecz nie weryfikuje, czy token pozwala na wykonanie konkretnej operacji, odpowiedź może zawierać dane przeznaczone dla innego konta, roli lub użytkownika.

Różnica między uwierzytelnieniem a autoryzacją

Istotą tego problemu jest pomieszanie dwóch etapów bezpieczeństwa. Uwierzytelnienie odpowiada na pytanie, kto przedstawia token. Autoryzacja rozstrzyga, do jakich zasobów i operacji ta osoba lub aplikacja ma dostęp. Token może być poprawnie podpisany i należeć do istniejącego użytkownika, a mimo to nie dawać prawa do odczytu określonego rekordu. Bez oddzielnej kontroli uprawnień system może uznać ważny token za wystarczający dowód prawa do każdego żądania.

Typowym przykładem jest punkt końcowy przyjmujący identyfikator obiektu w adresie żądania. Serwer może sprawdzić, czy token ma prawidłowy format, ale pominąć sprawdzenie, czy użytkownik związany z tokenem może odczytać obiekt o podanym identyfikatorze. Podobny błąd pojawia się przy tokenach o zbyt szerokim zakresie, tokenach technicznych używanych przez wiele aplikacji oraz przy nieuwzględnieniu roli użytkownika po jej zmianie. W systemach używających JWT należy dodatkowo sprawdzać między innymi podpis, algorytm, wystawcę, odbiorcę, czas wygaśnięcia i zakresy zapisane w tokenie.

Objawy i bezpieczne sprawdzenie ścieżki API

Rozpoznanie podatności wymaga porównania zachowania API dla różnych, uprawnionych ról i zasobów testowych. Należy sprawdzić, czy żądanie bez tokenu kończy się odmową, czy token wygasły jest odrzucany oraz czy token o ograniczonym zakresie nie umożliwia pobrania danych spoza przydzielonego zakresu. Ważne jest również sprawdzenie próby dostępu do obiektu należącego do innego konta. Odpowiedź HTTP 200 nie powinna być zwracana wyłącznie dlatego, że nagłówek autoryzacyjny zawiera dowolną wartość.

Podczas analizy trzeba obserwować nie tylko kod odpowiedzi, lecz także treść odpowiedzi, nagłówki, identyfikator użytkownika zapisany w logach i decyzję mechanizmu autoryzacji. Błąd może być widoczny jako ujawnienie pól, których interfejs graficzny nie pokazuje, możliwość zmiany identyfikatora rekordu albo różnica między odpowiedzią dla tokenu administratora i tokenu zwykłego użytkownika. Testy powinny odbywać się wyłącznie na własnym środowisku lub na danych przeznaczonych do kontroli. Nie należy wykorzystywać znalezionego tokenu do pobierania cudzych informacji ani kopiować wrażliwych wartości do raportów.

Ograniczenie skutków i kontrola po poprawce

Naprawa polega na wprowadzeniu centralnej, jednoznacznej kontroli autoryzacji dla każdego chronionego zasobu i każdej operacji. Serwer powinien odrzucać token nieznany, nieważny, wygasły, przeznaczony dla innej usługi lub pozbawiony wymaganego zakresu. Sama walidacja tokenu musi być połączona ze sprawdzeniem relacji między tożsamością z tokenu, rolą, identyfikatorem zasobu i rodzajem operacji. Tokeny powinny mieć ograniczony czas życia, a po podejrzeniu należy je unieważnić lub wymienić. Warto także ograniczać zakres tokenów technicznych, unikać umieszczania ich w adresach URL i usuwać sekrety z logów.

Po zmianie kodu potrzebne są testy negatywne: brak tokenu, token wygasły, token podpisany nieprawidłowym kluczem, token z niewłaściwym odbiorcą, brak wymaganego zakresu oraz dostęp do zasobu przypisanego do innego konta. Należy sprawdzić każdy punkt końcowy, także taki, który nie jest używany przez główny interfejs programu. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i ich podzespołów, dlatego przy podejrzeniu problemu z aplikacją działającą na komputerze można rozpocząć od sprawdzenia stanu systemu, konfiguracji klienta, aktualizacji oprogramowania i zapisów lokalnych wskazujących na nieprawidłowe żądania.