nieaktualizowane sesje użytkowników

Nieaktualizowane sesje użytkowników to podatność, w której odebranie uprawnień nie kończy trwających połączeń.

Na czym polega problem z nieaktualizowanymi sesjami użytkowników

Nieaktualizowane sesje użytkowników to sytuacja, w której zmiana uprawnień konta nie wpływa natychmiast na już rozpoczęte połączenie. Użytkownik może zalogować się do aplikacji, otrzymać określony zestaw uprawnień, a następnie pozostawać aktywny mimo odebrania części dostępu przez administratora. Jeżeli aplikacja sprawdza uprawnienia wyłącznie podczas logowania, trwająca sesja może nadal korzystać ze starego stanu autoryzacji. W praktyce oznacza to, że wyłączenie konta, usunięcie go z grupy albo odebranie dostępu do funkcji nie musi zakończyć istniejącego połączenia.

Sesja jest utrzymywanym przez aplikację kontekstem uwierzytelnionego użytkownika. Może być reprezentowana przez identyfikator zapisany w ciasteczku, token przekazywany w nagłówku HTTP albo stan przechowywany po stronie serwera. Samo uwierzytelnienie odpowiada na pytanie, kim jest użytkownik, natomiast autoryzacja określa, jakie operacje wolno mu wykonywać. Błąd pojawia się wtedy, gdy system poprawnie rozpoznaje zmianę uprawnień w bazie kont, lecz nie odświeża lub nie unieważnia kontekstu już otwartej sesji.

Dlaczego odebranie uprawnień nie zawsze przerywa połączenie

W prostym modelu aplikacja pobiera role użytkownika podczas logowania i zapisuje je w sesji. Późniejsze żądania korzystają z zapamiętanych informacji, bez ponownego odczytu aktualnych uprawnień. Takie rozwiązanie ogranicza liczbę odwołań do bazy danych, ale tworzy opóźnienie pomiędzy zmianą konfiguracji konta a jej zastosowaniem. Jeżeli sesja ma długi czas życia, użytkownik może przez ten okres wykonywać czynności, do których nie powinien już mieć dostępu.

Podobny problem może wystąpić przy tokenach zawierających role lub zakresy dostępu. Token podpisany przez serwer może być poprawny kryptograficznie, ale nadal przedstawiać wcześniejszy stan uprawnień. Weryfikacja podpisu potwierdza, że token został wystawiony przez zaufany system i nie zmieniono jego treści; nie oznacza jednak, że uprawnienia zapisane w tokenie są nadal aktualne. Samo usunięcie użytkownika z grupy nie zmienia automatycznie wcześniej wydanego tokena. Jeżeli aplikacja nie stosuje dodatkowego mechanizmu unieważniania, token może działać aż do upływu jego ważności.

Ryzyko zależy od rodzaju zmiany. Odebranie dostępu do zwykłej funkcji może powodować problem organizacyjny, natomiast pozostawienie aktywnej sesji po blokadzie konta, zmianie roli administracyjnej albo podejrzeniu przejęcia poświadczeń może umożliwić dalsze działania niezgodne z decyzją administratora. Warto odróżniać wygaśnięcie sesji z powodu bezczynności od świadomego unieważnienia sesji. Limit bezczynności nie gwarantuje natychmiastowego odcięcia aktywnego połączenia.

Oznaki i sprawdzanie aktualności autoryzacji

Objawem problemu może być dostęp do funkcji, która została przed chwilą odebrana, możliwość odczytu danych po usunięciu użytkownika z grupy albo działające połączenie po zablokowaniu konta. W aplikacji internetowej należy sprawdzić, czy po zmianie roli przeglądarka nadal wysyła ten sam identyfikator sesji lub token oraz jak serwer odpowiada na żądania do wcześniej dostępnych zasobów. Samo przeładowanie strony nie jest dowodem poprawnego unieważnienia, ponieważ klient może automatycznie ponownie wykorzystać istniejące poświadczenie.

Kontrola powinna obejmować moment logowania, zmianę uprawnień, kolejne żądania i zakończenie sesji. W logach warto porównać identyfikator użytkownika, identyfikator sesji, czas wydania tokena, czas jego wygaśnięcia oraz decyzję autoryzacyjną serwera. Szczególnie istotne jest ustalenie, czy serwer rejestruje odrzucenie żądania po odebraniu dostępu, czy tylko zapisuje zmianę w tabeli użytkowników. Jeżeli logi pokazują udaną operację po zmianie roli, trzeba sprawdzić, czy była ona wykonana w ramach starej sesji, przez odświeżony token, czy przez inne konto.

Test należy wykonywać na koncie testowym i na funkcji, której dostęp można bezpiecznie zmienić. Najpierw otwiera się sesję, następnie odbiera uprawnienie w panelu administracyjnym, a potem wysyła nowe żądanie bez ponownego logowania. Prawidłowo zabezpieczona aplikacja powinna ponownie ocenić uprawnienia albo odrzucić sesję w mechanizmie centralnego unieważniania. W przypadku urządzenia używanego lokalnie podobne zjawisko może dotyczyć zapisanych sesji aplikacji, klientów pocztowych, przeglądarek lub programów z funkcją automatycznego logowania.

Unieważnianie sesji i znaczenie diagnostyki komputera

Rozwiązaniem jest powiązanie zmiany uprawnień z unieważnieniem aktywnych sesji albo z wymuszeniem ponownej oceny uprawnień przy każdym żądaniu wrażliwym. Stosuje się między innymi krótszy czas życia tokenów, identyfikator wersji sesji przechowywany przy koncie, centralną listę unieważnionych sesji oraz kontrolę aktualnego stanu konta po stronie serwera. Po zmianie roli należy unieważnić wcześniejsze konteksty, a po blokadzie konta odrzucać także sesje, które były aktywne przed blokadą. Mechanizm wylogowania powinien usuwać lub oznaczać jako nieważne dane sesyjne zarówno po stronie aplikacji, jak i klienta, w zakresie przewidzianym przez dane rozwiązanie.

Jeżeli problem wynika z konfiguracji laptopa, uszkodzonego profilu użytkownika, błędów przeglądarki albo nieprawidłowego działania programu, Warszawskie Pogotowie Komputerowe wykonuje profesjonalną naprawę laptopów i komputerów PC oraz diagnostykę oprogramowania. Podczas sprawdzania należy rozdzielić usterkę lokalnego urządzenia od błędu serwera aplikacji: komputer może prawidłowo przechowywać sesję, podczas gdy decyzja o jej unieważnieniu należy do systemu, który ją wystawił. Analiza logowania, ustawień przeglądarki, zapisanych danych sesyjnych i zachowania programu pozwala ustalić, na którym etapie przepływu informacji pozostaje nieaktualny dostęp.

Po wdrożeniu poprawki warto ponownie sprawdzić kilka scenariuszy: odebranie pojedynczej roli, usunięcie użytkownika z grupy, blokadę konta, zmianę hasła oraz ręczne wylogowanie ze wszystkich urządzeń. Każdy z tych przypadków może być obsługiwany innym mechanizmem. Test powinien potwierdzić nie tylko brak dostępu do interfejsu, lecz także odrzucenie bezpośrednich żądań do chronionych zasobów. Dopiero wtedy można uznać, że zmiana uprawnień została przeniesiona z konfiguracji konta do aktywnego przepływu autoryzacji.