współdzielony token między aplikacjami

Współdzielony token między aplikacjami zwiększa ryzyko, że przejęcie jednej z nich naraża pozostałe.

Czym jest współdzielony token między aplikacjami

Współdzielony token między aplikacjami to poświadczenie, które może zostać użyte przez więcej niż jeden program do potwierdzenia tożsamości użytkownika albo uzyskania dostępu do określonego zasobu. Token może mieć postać nieprzezroczystego ciągu znaków przechowywanego i sprawdzanego przez serwer albo podpisanego tokenu, takiego jak JSON Web Token (JWT), którego zawartość odczytuje usługa odbierająca żądanie. Sam fakt współdzielenia tokenu nie wskazuje jeszcze na konkretny protokół, ale w praktyce problem często dotyczy tokenów sesyjnych, tokenów OAuth 2.0, tokenów dostępu do API oraz tokenów odświeżających.

Token typu bearer, stosowany między innymi w systemach API, działa według prostej zasady: posiadacz tokenu może przedstawić go serwerowi, a serwer uznaje go za dowód uprawnienia. Zwykle nie jest wymagany dodatkowy sekret pozwalający odróżnić prawowitą aplikację od osoby lub programu, który token przejął. Dlatego token należy traktować podobnie jak tymczasowy klucz dostępu. Wspólne używanie jednego tokenu przez kilka aplikacji oznacza, że każda z nich staje się częścią tego samego obszaru zaufania.

Dlaczego przejęcie jednej aplikacji zwiększa ryzyko

Jeżeli kilka aplikacji korzysta z identycznego tokenu, atakujący, który odczyta go z pamięci procesu, pliku konfiguracyjnego, dziennika zdarzeń, pamięci podręcznej przeglądarki albo niebezpiecznego mechanizmu komunikacji międzyprocesowej, może próbować użyć go także wobec pozostałych usług. Skutki zależą od zakresu uprawnień tokenu. Jeśli token pozwala tylko odczytać jeden zasób, ryzyko jest ograniczone. Jeżeli obejmuje zapis, usuwanie danych, zmianę ustawień lub dostęp do wielu interfejsów, pojedynczy wyciek może rozszerzyć incydent na całą grupę aplikacji.

Ryzyko rośnie również wtedy, gdy aplikacje mają różny poziom zabezpieczeń. Program z błędem umożliwiającym wykonanie kodu, niezaszyfrowanym logiem debugowania albo podatnym dodatkiem może stać się miejscem kradzieży poświadczenia używanego następnie przez bezpieczniejsze aplikacje. Wspólny token utrudnia też ustalenie źródła nadużycia, ponieważ serwer widzi często ten sam identyfikator poświadczenia, a nie jednoznacznie rozróżnia poszczególne aplikacje. Obrót tokenami, czyli ich regularna wymiana, musi wtedy uwzględniać wszystkie zależne programy.

Zakres uprawnień, odbiorca i przechowywanie

Bezpieczniejszy projekt rozdziela tokeny według aplikacji, funkcji i odbiorcy. Token dostępu powinien mieć możliwie wąski zakres, na przykład uprawnienie tylko do odczytu konkretnego API, zamiast pełnego dostępu do konta. W systemach wykorzystujących JWT serwer może sprawdzać między innymi podpis, czas ważności, wystawcę oraz odbiorcę tokenu oznaczanego jako aud. Aplikacja nie powinna akceptować tokenu przeznaczonego dla innego serwisu tylko dlatego, że podpis jest poprawny. Poprawny podpis potwierdza autentyczność tokenu, ale nie dowodzi, że token jest przeznaczony dla każdej aplikacji.

Tokenów nie należy umieszczać w adresach URL, ponieważ mogą trafić do historii przeglądarki, nagłówka Referer albo logów serwera proxy. W komunikacji HTTP token dostępu zwykle przekazuje się w nagłówku Authorization z odpowiednim schematem, a połączenie powinno być chronione przez TLS. Po stronie klienta trzeba ograniczać dostęp do pamięci i plików zawierających poświadczenia oraz usuwać token z komunikatów diagnostycznych. W aplikacjach przeglądarkowych wybór miejsca przechowywania wymaga analizy modelu zagrożeń, ponieważ token dostępny dla kodu JavaScript może zostać odczytany po udanym ataku XSS.

Token odświeżający powinien być chroniony silniej niż krótkotrwały token dostępu, ponieważ umożliwia uzyskanie kolejnych tokenów. Warto stosować osobne poświadczenia dla aplikacji, ograniczać czas ich ważności, prowadzić możliwość unieważnienia oraz reagować na wylogowanie, zmianę hasła i podejrzenie wycieku. Samo skrócenie czasu ważności nie usuwa problemu, jeśli aplikacja może bez kontroli uzyskać następny token odświeżający.

Znaczenie podczas diagnostyki komputerów

Na komputerze użytkownika ślady współdzielonego tokenu mogą występować w ustawieniach aplikacji, rozszerzeniach przeglądarki, menedżerach sesji, plikach tymczasowych lub logach. Diagnostyka powinna ustalić, które programy korzystają z danego poświadczenia, jakie żądania mogą nim wykonywać oraz czy token został ujawniony w plikach i komunikatach błędów. Nie należy kopiować tokenu do zgłoszenia serwisowego ani umieszczać go w publicznym fragmencie logu. W razie podejrzenia przejęcia właściwym działaniem jest unieważnienie poświadczenia po stronie dostawcy usługi, ponowne uwierzytelnienie oraz sprawdzenie historii użycia.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i podzespołów, w tym diagnostyką problemów z aplikacjami, systemem operacyjnym oraz konfiguracją urządzenia. Przy takich pracach warto wcześniej wylogować konta, odłączyć nieużywane sesje i przekazać technikowi wyłącznie informacje potrzebne do odtworzenia problemu, bez haseł, tokenów dostępu i kodów odzyskiwania.

Rozdzielenie tokenów ogranicza zasięg ewentualnego incydentu, ale nie zastępuje aktualizacji systemu, ochrony konta i kontroli uprawnień. Każda aplikacja powinna otrzymywać tylko takie poświadczenie, jakie jest konieczne do wykonania jej zadania, a użytkownik powinien mieć możliwość jego odwołania i ponownego wydania. Dzięki temu awaria lub przejęcie jednego programu nie musi automatycznie oznaczać dostępu do pozostałych aplikacji.