Co to jest IDOR?
Autor: Redakcja Domeny.ForSale Opublikowano
W skrócie: IDOR (Insecure Direct Object Reference) to luka, w której aplikacja pozwala uzyskać dostęp do cudzego zasobu przez wskazanie jego identyfikatora, bez właściwego sprawdzenia uprawnień. Przykładowo użytkownik zmienia numer faktury w adresie i widzi dokument innego klienta. Problemem nie jest sam numer w adresie, lecz to, że serwer nie sprawdza, czy dana osoba ma prawo do tej faktury.
Jak działa IDOR — prosty przykład
Wyobraź sobie panel klienta, w którym po zalogowaniu pobierasz własną fakturę. Przeglądarka wysyła do serwera żądanie dotyczące ścieżki /faktury/481, a aplikacja zwraca dokument o numerze 481.
Sam taki adres jest normalnym rozwiązaniem. Luka pojawia się wtedy, gdy zmiana ścieżki na /faktury/482 pozwala pobrać fakturę innego klienta, mimo że nie otrzymałeś do niej dostępu.
To przypomina szatnię, w której pracownik wydaje płaszcz każdemu, kto poda numer wieszaka, zamiast sprawdzić prawo do odbioru. Numer wskazuje przedmiot, ale nie potwierdza uprawnienia do jego otrzymania.
„Obiekt” w nazwie IDOR oznacza tutaj zasób aplikacji: dokument, zamówienie, zdjęcie, wiadomość albo konto. „Bezpośrednie odwołanie” oznacza wskazanie tego zasobu przez identyfikator. Nie musi to być kolejna liczba — może to być nazwa pliku, adres e-mail lub długi ciąg znaków.
Dlaczego samo zalogowanie nie wystarcza
Uwierzytelnianie odpowiada na pytanie: „Kim jesteś?”. Autoryzacja, czyli sprawdzanie uprawnień, odpowiada na inne: „Co wolno ci zrobić?”. Aplikacja może poprawnie rozpoznać zalogowanego użytkownika, a mimo to udostępniać mu cudze dane.
Bezpieczny serwer powinien sprawdzić nie tylko, czy faktura istnieje, lecz także, czy użytkownik może ją odczytać. Prawo dostępu może wynikać z własności dokumentu, roli w organizacji lub świadomego udostępnienia go innej osobie.
IDOR nie ogranicza się do podglądania informacji. Brak kontroli może umożliwić również zmianę lub usunięcie cudzego zasobu, na przykład adresu dostawy w zamówieniu. Uprawnienie do odczytu nie oznacza automatycznie prawa do edycji, dlatego każda operacja wymaga odpowiedniej kontroli.
Jeśli aplikacja obsługuje wiele firm, ważne są także granice między organizacjami. Administrator jednej firmy nie powinien uzyskać dostępu do danych drugiej tylko dlatego, że zna identyfikator jej dokumentu.
Gdzie może kryć się podatny identyfikator
Identyfikator nie musi być widoczny na pasku adresu. Może znajdować się w parametrach zapytania, treści żądania wysyłanego przez formularz albo w wywołaniu API, czyli interfejsu służącego do komunikacji między programami.
Typowe miejsca wymagające kontroli to:
- pobieranie faktur, załączników i eksportów danych;
- odczytywanie wiadomości, zgłoszeń i zamówień;
- aktualizowanie profilu lub ustawień konta;
- usuwanie plików i innych zasobów.
Nie każdy dostęp po zmianie identyfikatora oznacza błąd. Publiczny wpis na blogu powinien być dostępny dla wszystkich, a dokument współdzielony — dla uprawnionych współpracowników. O luce decyduje naruszenie zamierzonych zasad dostępu, nie sama możliwość wskazania innego obiektu.
Podobne błędy w API bywają opisywane jako BOLA (Broken Object Level Authorization), czyli nieprawidłowa kontrola uprawnień na poziomie konkretnego obiektu. Nazwy są blisko związane; praktyczne pytanie pozostaje takie samo: czy serwer sprawdza prawo użytkownika do wskazanego zasobu i działania?
Co naprawdę chroni przed IDOR
Podstawowym zabezpieczeniem jest kontrola uprawnień po stronie serwera przy każdym dostępie do zasobu. Ukrycie przycisku w interfejsie nie wystarcza, ponieważ żądanie można wysłać bez korzystania z tego przycisku.
W przykładzie z fakturami aplikacja powinna szukać dokumentu w zbiorze dostępnym danemu użytkownikowi albo sprawdzić uprawnienia przed jego zwróceniem. Nie powinna ufać przesłanemu przez przeglądarkę polu „właściciel” jako dowodowi własności.
Losowe identyfikatory, takie jak UUID, utrudniają zgadywanie adresów, ale nie zastępują autoryzacji. Jeśli identyfikator wycieknie, na przykład przez udostępniony odnośnik, serwer nadal musi odmówić dostępu osobie bez uprawnień.
Dobrą zasadą jest domyślna odmowa: jeśli aplikacja nie potrafi potwierdzić prawa do operacji, nie wykonuje jej. Kontrola powinna obejmować również pobieranie plików i eksporty, a nie tylko główny ekran dokumentu.
Jak bezpiecznie sprawdzić własną aplikację
Taki test wykonuj wyłącznie w systemie, który należy do ciebie lub na którego testowanie masz zgodę. Najlepiej użyć środowiska testowego i fikcyjnych danych, szczególnie przy operacjach zmiany oraz usuwania.
- Utwórz dwa konta testowe: A i B, bez wzajemnie udostępnionych zasobów.
- Na koncie A utwórz dokument i zanotuj jego identyfikator.
- Zaloguj się jako B i spróbuj odczytać ten dokument przez przewidziany interfejs lub API.
- Osobno sprawdź możliwość edycji, pobrania i usunięcia, jeśli takie działania istnieją.
- Zweryfikuj nie tylko komunikat odmowy, lecz także to, czy żadne dane nie zostały ujawnione lub zmienione.
Serwer powinien odmówić niedozwolonej operacji; może też celowo nie ujawniać, czy dokument istnieje. Taki scenariusz warto dodać do testów automatycznych, aby zmiana w kodzie nie przywróciła luki.
Zobacz też: Co to jest 2FA?
Przeczytaj także
