brak sprawdzania zakresu dostępu

Brak sprawdzania zakresu dostępu to luka bezpieczeństwa, w której system nie weryfikuje, czy operacja mieści się w przyznanych uprawnieniach.

Brak sprawdzania zakresu dostępu – czym jest ta luka bezpieczeństwa

Brak sprawdzania zakresu dostępu oznacza sytuację, w której aplikacja, system operacyjny, panel administracyjny albo usługa sieciowa przyjmuje żądanie bez dokładnego ustalenia, czy wskazany użytkownik, proces lub urządzenie może wykonać daną czynność na konkretnym zasobie. Sam fakt pomyślnego zalogowania nie powinien oznaczać dostępu do wszystkich danych i operacji. Uwierzytelnienie odpowiada na pytanie, kim jest osoba korzystająca z systemu, natomiast kontrola zakresu dostępu rozstrzyga, co wolno jej zrobić.

Problem pojawia się wtedy, gdy sprawdzane jest wyłącznie istnienie sesji, tokenu albo konta, a pomijane są szczegóły uprawnień. W takim przypadku użytkownik może próbować odczytać cudzy dokument, zmienić ustawienia innego konta, pobrać rekord należący do innego działu albo wykonać operację przeznaczoną dla administratora. Podobny błąd może dotyczyć programu działającego lokalnie: proces posiadający dostęp do jednego katalogu może uzyskać możliwość odczytu znacznie szerszego obszaru, ponieważ zakres nie został ograniczony na każdym etapie działania.

Nie jest to wyłącznie problem interfejsu. Ukrycie przycisku lub zakładki przed określoną osobą nie stanowi wystarczającej ochrony, jeżeli odpowiednie żądanie można wysłać bezpośrednio. Kontrola musi być wykonywana po stronie serwera, w warstwie obsługującej dane i operacje. W przeciwnym razie zmiana identyfikatora w adresie, parametru formularza albo treści zapytania może prowadzić do obejścia ograniczeń widocznych w aplikacji.

Brak sprawdzania zakresu dostępu a kontekst techniczny i porównania

W praktyce warto rozróżnić kilka powiązanych, ale odmiennych pojęć. Uwierzytelnienie potwierdza tożsamość, autoryzacja określa dozwolone działania, a kontrola zakresu dostępu sprawdza, czy działanie obejmuje właściwy zasób i właściwy kontekst. Konto może mieć prawo do edycji własnych danych, lecz nie powinno otrzymywać takiego samego prawa wobec profilu innej osoby. Użytkownik może mieć dostęp do dokumentów przypisanych do konkretnego projektu, ale nie do wszystkich dokumentów znajdujących się w tej samej bazie.

Przykładem błędu jest bezpośredni dostęp do obiektu na podstawie przewidywalnego identyfikatora. Jeżeli po zalogowaniu można otworzyć adres odnoszący się do dokumentu o numerze 101, a następnie zmienić numer na 102 i zobaczyć treść należącą do innego użytkownika, zakres dostępu nie jest wiarygodnie sprawdzany. Inny wariant polega na zaakceptowaniu parametru określającego rolę, właściciela lub grupę bez porównania go z informacjami zapisanymi po stronie serwera.

Istotna jest także różnica między kontrolą na poziomie funkcji a kontrolą na poziomie danych. Zablokowanie całej funkcji może być poprawne, gdy dana osoba nie ma prawa jej używać. Częściej jednak potrzebne jest dodatkowe ograniczenie: funkcja może być dostępna, ale tylko dla wybranych rekordów, folderów, urządzeń lub operacji. Sama rola użytkownika nie zawsze wystarcza, ponieważ dwóch użytkowników o tej samej roli może mieć różny zakres danych.

Ryzyko zwiększa się przy rozdzieleniu aplikacji na wiele modułów. Każdy moduł powinien samodzielnie sprawdzać uprawnienia do zasobu, ponieważ przekazanie zaufania wyłącznie interfejsowi lub innemu komponentowi może stworzyć drogę obejścia zabezpieczeń. Szczególnej uwagi wymagają funkcje eksportu, wyszukiwania, pobierania plików, zmiany właściciela, resetowania ustawień oraz wykonywania operacji zbiorczych.

Brak sprawdzania zakresu dostępu – typowe problemy w działaniu

Jednym z częstych symptomów jest możliwość odczytu danych po zmianie identyfikatora w adresie lub w treści zapytania. Zdarza się również, że można edytować rekord, którego nie powinno się nawet wyświetlać, albo usunąć plik należący do innego konta. Niekiedy problem ujawnia się dopiero przy użyciu mniej typowej ścieżki, na przykład mobilnego widoku, funkcji importu, starszej wersji formularza lub automatycznego mechanizmu synchronizacji.

Do błędów dochodzi także wtedy, gdy uprawnienia są sprawdzane tylko przy tworzeniu zasobu, lecz nie podczas jego późniejszego pobierania. Przykładowo dokument może zostać poprawnie przypisany do określonego właściciela, ale endpoint pobierający dokument może ignorować to przypisanie. Podobny problem powstaje przy zmianie uprawnień: odebranie dostępu może nie unieważnić już wystawionego tokenu, aktywnego linku albo zapisanej sesji.

Niebezpieczna bywa również nadmierna wiara w dane przesyłane przez przeglądarkę. Pole opisujące rolę, nazwę grupy lub identyfikator właściciela powinno być traktowane jako informacja pochodząca od użytkownika, a nie jako dowód uprawnienia. Decyzja powinna wynikać z danych kontrolowanych przez system, aktualnego stanu konta oraz reguł przypisanych do konkretnego zasobu.

Konsekwencje mogą obejmować ujawnienie informacji, nieautoryzowaną zmianę konfiguracji, utratę plików, naruszenie integralności dokumentacji i utrudnione ustalenie przebiegu zdarzeń. Jeżeli rejestrowane jest tylko samo żądanie, bez informacji o użytkowniku, zasobie i wyniku kontroli, późniejsza analiza może być niepełna. Z tego powodu ważne są zarówno reguły dostępu, jak i czytelne logowanie decyzji odmownych oraz nietypowych prób użycia.

Brak sprawdzania zakresu dostępu – praktyczne wskazówki ochrony

Podstawą jest zdefiniowanie zasobów oraz czynności, które mogą być wykonywane na każdym z nich. Dla każdej operacji powinno być jasne, kto może ją wykonać, wobec jakiego obiektu, w jakim stanie i w jakim zakresie. Reguły warto zapisywać w sposób możliwy do przetestowania, zamiast opierać je na domysłach wynikających z układu ekranów.

Kontrola powinna być umieszczona możliwie blisko miejsca, w którym następuje odczyt lub modyfikacja danych. W zapytaniu do bazy należy uwzględniać nie tylko identyfikator rekordu, ale także warunek przynależności do użytkownika, grupy albo dozwolonego obszaru. Przy operacjach zmieniających dane powinno się ponownie sprawdzić aktualny stan uprawnień, nawet jeżeli wcześniejszy etap aplikacji wykonał podobną kontrolę.

Warto stosować zasadę najmniejszych uprawnień. Konto, proces lub moduł powinien otrzymywać tylko taki zakres, jaki jest potrzebny do wykonania zadania. Uprawnienia tymczasowe powinny mieć określony czas obowiązywania, a ich odebranie powinno działać również wobec aktywnych sesji i wcześniej wygenerowanych odwołań. Należy też unikać wspólnych kont, ponieważ utrudniają przypisanie operacji do konkretnego użytkownika.

Bezpieczne testowanie obejmuje przypadki pozytywne i negatywne. Sprawdzane powinno być między innymi to, czy użytkownik nie może odczytać zasobu o innym właścicielu, zmienić parametrów wpływających na zakres, użyć starego tokenu po odebraniu uprawnień ani wykonać operacji przez alternatywny moduł. Testy powinny dotyczyć także pustych identyfikatorów, wartości granicznych, różnych formatów żądań oraz prób równoczesnego użycia kilku sesji.

Przydatne jest rozdzielenie błędów dla użytkownika od szczegółów zapisywanych w rejestrach. Odpowiedź nie powinna ujawniać nadmiarowych informacji o istniejących zasobach, natomiast log powinien zawierać wystarczający kontekst do analizy: konto, czas, typ operacji, identyfikator zasobu, decyzję oraz przyczynę odmowy. Regularny przegląd takich zapisów pomaga wykrywać nietypowe sekwencje prób.

Kiedy zgłosić brak sprawdzania zakresu dostępu do serwisu komputerowego

Do serwisu warto zgłosić komputer lub laptopa, gdy pojawiają się nieoczekiwane komunikaty o uprawnieniach, znikają ustawienia dostępu, nie da się poprawnie rozdzielić kont użytkowników albo po zmianie hasła nadal widoczne są zasoby, które powinny zostać ukryte. Konsultacja może być również potrzebna po podejrzanej instalacji, nieznanej zmianie konfiguracji, utracie kontroli nad kontem lokalnym lub problemach z dostępem do współdzielonych folderów.

Przed przekazaniem sprzętu warto zanotować objawy, czas ich wystąpienia, używane konto oraz zakres danych, który został nieoczekiwanie wyświetlony lub zmieniony. Nie powinno się kasować logów ani wielokrotnie powtarzać podejrzanych prób, ponieważ może to utrudnić ustalenie przyczyny. W przypadku danych wrażliwych potrzebne jest wcześniejsze określenie, które informacje mogą zostać udostępnione do analizy.

Warszawskie Pogotowie Komputerowe 24/7 może zostać wybrane do sprawdzenia konfiguracji komputera, kont użytkowników, lokalnych mechanizmów uprawnień oraz oznak nieprawidłowego działania aplikacji. Zakres prac powinien zostać ustalony na podstawie objawów i dostępnych informacji, a po analizie powinny zostać wskazane miejsca wymagające korekty oraz działania ograniczające ryzyko ponownego wystąpienia problemu.