token dostępowy bez możliwości ograniczenia zakresu

Token dostępowy bez możliwości ograniczenia zakresu przyznaje szersze uprawnienia niż faktycznie potrzebne.

Token dostępowy bez ograniczenia zakresu uprawnień

Token dostępowy bez możliwości ograniczenia zakresu to poświadczenie, którego używa aplikacja lub użytkownik do uzyskania dostępu do zasobów, ale jego wydawca nie pozwala wskazać, jakie dokładnie operacje i dane mają być dostępne. Zakres uprawnień, określany często jako scope, permission albo claims, nie jest wtedy zawężany do konkretnej funkcji. Token może więc umożliwiać wykonywanie większej liczby operacji niż wymaga tego zadanie, na przykład odczyt i modyfikację danych zamiast samego odczytu.

Samo wystawienie tokenu nie oznacza jeszcze, że każda aplikacja automatycznie otrzymuje pełny dostęp do całego systemu. Rzeczywiste uprawnienia zależą od sposobu weryfikacji tokenu przez usługę, przypisania konta do ról oraz reguł kontroli dostępu po stronie serwera. Problem polega na tym, że token bez ograniczalnego zakresu utrudnia zastosowanie zasady najmniejszych uprawnień. Jeżeli taki token zostanie skopiowany, wykradziony z konfiguracji albo zapisany w niebezpiecznym miejscu, osoba dysponująca jego wartością może próbować wykorzystać wszystkie operacje akceptowane dla danego tokenu.

Różnica między brakiem scope a szeroką rolą

Brak możliwości ograniczenia zakresu nie jest dokładnie tym samym co nadanie tokenowi szerokiej roli. Rola jest decyzją modelu autoryzacji, na przykład przypisaniem konta do grupy administratorów, operatorów albo użytkowników tylko do odczytu. Scope natomiast opisuje zakres dostępu konkretnego tokenu lub konkretnej zgody. System może mieć szczegółowe role, ale jeżeli podczas wystawiania tokenu nie da się wybrać ograniczonego zakresu, aplikacja nadal może otrzymać więcej uprawnień, niż potrzebuje.

W tokenach formatu JSON Web Token uprawnienia mogą być zapisane w claims, takich jak scope, roles lub niestandardowe pola używane przez konkretną usługę. JWT jest jednak tylko podpisaną strukturą danych; o znaczeniu tych pól decyduje serwer, który token weryfikuje. Nie wolno zakładać, że zmiana tekstowej zawartości tokenu po stronie klienta ograniczy dostęp, ponieważ prawidłowo skonfigurowana usługa sprawdza podpis i odrzuca zmodyfikowany token. Ograniczenie powinno zostać ustalone podczas wydawania tokenu oraz egzekwowane przy każdym żądaniu do chronionego zasobu.

Skutki użycia zbyt szerokiego poświadczenia

Najpoważniejszym skutkiem jest zwiększenie zasięgu incydentu po ujawnieniu tokenu. Token zapisany w kodzie programu, pliku konfiguracyjnym, historii poleceń lub logu może zostać użyty przez osobę nieuprawnioną do wywoływania tych samych endpointów co legalna aplikacja, dopóki token pozostaje ważny i nie zostanie unieważniony. Jeżeli token pozwala na zapis, usuwanie albo zmianę ustawień, konsekwencje są większe niż w przypadku poświadczenia ograniczonego do odczytu.

Szeroki token komplikuje także analizę logów. Wpis wskazujący, że określony token wykonał żądanie, nie wyjaśnia sam przez się, czy operacja była zgodna z przeznaczeniem aplikacji. Dlatego przy ocenie konfiguracji należy sprawdzić nie tylko samą obecność tokenu, lecz także jego właściciela, czas ważności, sposób przechowywania, możliwość rotacji i listę akceptowanych operacji po stronie usługi. Warto osobno przeanalizować, czy aplikacja używa jednego wspólnego tokenu dla wielu funkcji. Taki układ utrudnia odebranie dostępu jednej funkcji bez przerywania działania pozostałych.

Weryfikacja konfiguracji i bezpieczna obsługa tokenu

Podczas diagnostyki należy ustalić, gdzie token jest tworzony, gdzie jest przekazywany oraz które komponenty sprawdzają jego uprawnienia. Trzeba porównać wymagania funkcji z faktycznie przyznanymi możliwościami: operacja odczytu powinna korzystać z poświadczenia pozwalającego na odczyt, a funkcja administracyjna powinna wymagać odrębnej, kontrolowanej autoryzacji. Jeżeli dostawca nie obsługuje ograniczania zakresu, praktycznym zabezpieczeniem jest rozdzielenie tokenów według zastosowań, skrócenie ich czasu życia, regularna rotacja i natychmiastowe unieważnianie po podejrzeniu wycieku.

Nie należy umieszczać wartości tokenu w komunikatach diagnostycznych ani przesyłać jej w zgłoszeniu serwisowym. W logach można zapisywać identyfikator poświadczenia, jego właściciela lub skrócony odcisk, o ile takie informacje nie pozwalają odtworzyć sekretu. Przy sprawdzaniu aplikacji na laptopie lub komputerze PC trzeba zweryfikować pliki konfiguracyjne, zmienne środowiskowe, menedżer poświadczeń oraz historię procesów, ale bez kopiowania sekretu do nowych dokumentów. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów i komputerów PC, dlatego w przypadku problemów z aplikacją można zlecić sprawdzenie lokalnej konfiguracji, logów oraz sposobu uruchamiania programu.