możliwość samodzielnej zmiany roli przez użytkownika

Samodzielna zmiana roli przez użytkownika to podatność umożliwiająca eskalację uprawnień w obrębie systemu.

Na czym polega samodzielna zmiana roli przez użytkownika

Możliwość samodzielnej zmiany roli przez użytkownika oznacza błąd w kontroli dostępu, w którym konto może zmodyfikować własne uprawnienia bez zatwierdzenia przez administratora albo bez spełnienia warunków przewidzianych przez aplikację. Użytkownik, który powinien mieć rolę zwykłego operatora, klienta lub autora, uzyskuje możliwość przypisania sobie roli administracyjnej, moderatorskiej albo innej roli zapewniającej szerszy dostęp. Taka sytuacja jest przykładem eskalacji uprawnień, ponieważ konto otrzymuje możliwości wykraczające poza zakres przydzielony podczas tworzenia lub konfiguracji konta.

Podatność może wynikać z niewłaściwej obsługi danych przesyłanych przez formularz, parametrów adresu URL, żądań AJAX albo bezpośredniego wywołania interfejsu API. Przykładowo aplikacja może wyświetlać pole wyboru roli wyłącznie administratorowi, ale jednocześnie akceptować parametr role=admin przesłany ręcznie w żądaniu HTTP. Innym wariantem jest zapisanie wartości roli w profilu użytkownika bez sprawdzenia, czy osoba wykonująca operację ma uprawnienie do zarządzania rolami. Ukrycie pola w interfejsie nie jest zabezpieczeniem, ponieważ klient może zmodyfikować dane przed ich wysłaniem.

Weryfikacja uprawnień po stronie serwera

Podstawowym zabezpieczeniem jest kontrola uprawnień wykonywana po stronie serwera przy każdej operacji zmieniającej rolę. Serwer powinien ustalić tożsamość użytkownika na podstawie poprawnie zweryfikowanej sesji lub tokenu, odczytać jego aktualne uprawnienia z zaufanego źródła i sprawdzić, czy może on wykonać konkretną czynność. Sam fakt zalogowania nie może być traktowany jako zgoda na modyfikowanie roli. W praktyce uprawnienie do zmiany ról powinno być oddzielone od uprawnienia do edycji własnych danych profilu.

Sprawdzenie powinno obejmować zarówno identyfikator konta docelowego, jak i nową rolę. Aplikacja nie powinna pozwalać zwykłemu użytkownikowi na zmianę własnej roli, ale także nie powinna ufać wartości przesłanej przez przeglądarkę, takiej jak nazwa roli, poziom dostępu czy flaga administratora. Dozwolone role należy wybierać z kontrolowanego zbioru, a przejścia między rolami powinny być zgodne z regułami systemu. W systemie wykorzystującym tokeny po zmianie uprawnień trzeba również uwzględnić już wydane tokeny: jeżeli zawierają stare uprawnienia i pozostają ważne, użytkownik może nadal korzystać z poprzedniego zakresu dostępu do czasu ich wygaśnięcia lub unieważnienia.

Objawy i skutki błędnej kontroli dostępu

Objawem podatności jest możliwość wysłania żądania zmiany roli i otrzymania odpowiedzi oznaczającej powodzenie, mimo że konto nie ma uprawnienia administracyjnego. Weryfikacja nie powinna ograniczać się do wyglądu panelu użytkownika. Należy sprawdzić zachowanie serwera po usunięciu pola z interfejsu, zmianie identyfikatora konta, ponowieniu żądania oraz wywołaniu tego samego endpointu bez korzystania z graficznego panelu. Ważne są również odpowiedzi po ponownym zalogowaniu, ponieważ chwilowa zmiana informacji wyświetlanej w przeglądarce nie musi oznaczać zmiany uprawnień zapisanych po stronie serwera.

Skutki zależą od zakresu nadanych praw. Rola administracyjna może umożliwiać tworzenie kolejnych kont uprzywilejowanych, zmianę konfiguracji aplikacji, odczyt informacji niedostępnych zwykłym użytkownikom, usuwanie danych albo modyfikowanie ustawień bezpieczeństwa. Nawet ograniczona zmiana roli może prowadzić do dalszej eskalacji, jeżeli nowa rola pozwala edytować profile innych osób lub przydzielać kolejne uprawnienia. W logach warto rejestrować identyfikator wykonującego operację, konto docelowe, starą i nową rolę, czas oraz wynik żądania. Sam zapis komunikatu „rola zmieniona” nie wystarcza, jeżeli nie można ustalić, kto wykonał operację i czy miał do niej uprawnienie.

Sprawdzenie zabezpieczeń podczas pracy serwisu

Analiza problemu powinna objąć kod obsługujący profil użytkownika, endpointy odpowiedzialne za role, reguły autoryzacji oraz mechanizm odświeżania sesji. Należy porównać uprawnienia zapisane w bazie z rolą prezentowaną w panelu i z uprawnieniami wynikającymi z aktywnej sesji. Test naprawy powinien potwierdzić, że zwykłe konto otrzymuje odmowę przy próbie zmiany własnej roli, a uprawniony administrator może wykonać tylko dozwolone przejścia. Trzeba także sprawdzić, czy po odmowie nie następuje częściowy zapis oraz czy użytkownik nie uzyskuje dostępu przez wcześniej otwartą sesję.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i ich podzespołów, a w przypadku problemów z aplikacjami może pomóc w podstawowej diagnostyce środowiska użytkownika. Przy podejrzeniu nieuprawnionej zmiany roli warto zabezpieczyć logi, zanotować czas zdarzenia, wylogować aktywne sesje i zmienić dane uwierzytelniające kont uprzywilejowanych. Naprawa wymaga usunięcia możliwości modyfikowania roli przez nieuprawnione żądanie, wdrożenia kontroli po stronie serwera oraz ponownego przetestowania wszystkich ścieżek prowadzących do zmiany uprawnień.