IDOR — czym jest Insecure Direct Object Reference i jak się bronić?

Bezpieczeństwo aplikacji webowych opiera się na fundamentalnej zasadzie: użytkownik powinien mieć dostęp wyłącznie do tych zasobów, do których jest uprawniony. Brzmi banalnie, a jednak naruszenie tej zasady stanowi najczęstszą kategorię podatności w aplikacjach webowych według OWASP Top 10. IDOR (Insecure Direct Object Reference) to klasyczny przykład takiego naruszenia — prosty w koncepcji, ale niezwykle powszechny w praktyce i potencjalnie katastrofalny w skutkach.

W tym artykule szczegółowo wyjaśnimy, czym jest IDOR, jak atakujący wykorzystują tę podatność, jakie konsekwencje może mieć jej eksploatacja oraz — przede wszystkim — jak skutecznie zabezpieczyć aplikacje i API przed tego typu atakami.

Czym jest IDOR?

IDOR (Insecure Direct Object Reference — niezabezpieczone bezpośrednie odwołanie do obiektu) to podatność bezpieczeństwa, która występuje, gdy aplikacja udostępnia użytkownikowi bezpośredni dostęp do wewnętrznych obiektów (rekordów w bazie danych, plików, zasobów) na podstawie identyfikatora dostarczonego przez użytkownika, bez odpowiedniej weryfikacji uprawnień.

Mówiąc prościej: aplikacja ufa, że jeśli użytkownik podaje identyfikator obiektu (np. numer zamówienia, ID użytkownika, nazwę pliku), to ma prawo do tego obiektu. Atakujący może zmienić ten identyfikator i uzyskać dostęp do danych innych użytkowników — bez łamania haseł, omijania firewalli czy wykorzystywania złożonych exploitów.

IDOR w kontekście OWASP Top 10

IDOR od lat jest jedną z najczęściej raportowanych podatności. W aktualnej edycji OWASP Top 10 (2021) IDOR wchodzi w skład kategorii A01:2021 Broken Access Control, która zajmuje pierwsze miejsce na liście — awansując z piątej pozycji w edycji 2017. Statystyki OWASP wskazują, że 94% testowanych aplikacji wykazuje jakąś formę błędu kontroli dostępu, a w danych z programów bug bounty Broken Access Control jest najczęściej zgłaszaną kategorią.

Wcześniej IDOR miał własną kategorię w OWASP Top 10 (A4 w edycji 2013), co świadczy o tym, że problem jest rozpoznawany od ponad dekady — mimo to nadal powszechnie występuje w produkcyjnych aplikacjach.

Dlaczego IDOR jest tak powszechny?

Przyczyn powszechności IDOR jest kilka. Po pierwsze, wiele frameworków i ORM-ów domyślnie używa sekwencyjnych identyfikatorów numerycznych (auto-increment), co czyni identyfikatory przewidywalnymi. Po drugie, developerzy często skupiają się na uwierzytelnianiu (czy użytkownik jest zalogowany?), zapominając o autoryzacji (czy zalogowany użytkownik ma prawo do tego konkretnego zasobu?). Po trzecie, testy funkcjonalne rzadko obejmują scenariusze, w których jeden użytkownik próbuje uzyskać dostęp do zasobów innego użytkownika — testy zazwyczaj weryfikują „happy path” z perspektywy jednego konta.

Jak działa atak IDOR?

Mechanizm ataku IDOR jest koncepcyjnie prosty, co paradoksalnie czyni go jeszcze bardziej niebezpiecznym — nie wymaga zaawansowanej wiedzy technicznej ani specjalistycznych narzędzi.

Przewidywalne identyfikatory

Podstawowy scenariusz ataku IDOR opiera się na przewidywalności identyfikatorów. Rozważmy aplikację bankową, w której URL do wyświetlenia szczegółów konta wygląda następująco:

https://bank.example.com/account/details?id=10421

Użytkownik widzi swoje konto o identyfikatorze 10421. Co się stanie, jeśli zmieni wartość parametru na 10420 lub 10422? Jeśli aplikacja nie weryfikuje, czy zalogowany użytkownik jest właścicielem konta o podanym ID, atakujący zobaczy dane bankowe innego klienta. Iterując po kolejnych numerach (10419, 10418, 10417…), może pobrać dane wszystkich klientów banku.

Horizontal privilege escalation (eskalacja pozioma)

Eskalacja pozioma to sytuacja, w której atakujący uzyskuje dostęp do zasobów innego użytkownika o tym samym poziomie uprawnień. To najczęstsza forma IDOR. Przykłady:

• Użytkownik A zmienia ID zamówienia w URL i widzi zamówienie użytkownika B
• Pracownik działu sprzedaży podmienia identyfikator i odczytuje raporty innego handlowca
• Pacjent w portalu medycznym zmienia numer w URL i widzi wyniki badań innego pacjenta

Eskalacja pozioma jest szczególnie niebezpieczna, ponieważ atakujący operuje w ramach swoich normalnych uprawnień — zmienia tylko kontekst (czyje dane widzi), nie podwyższając swoich ról ani przywilejów. To sprawia, że ataki tego typu są trudniejsze do wykrycia przez systemy monitoringu, które szukają anomalii w poziomie dostępu.

Vertical privilege escalation (eskalacja pionowa)

Eskalacja pionowa jest poważniejsza — atakujący uzyskuje dostęp do zasobów wymagających wyższych uprawnień. Przykłady:

• Zwykły użytkownik zmienia parametr role=user na role=admin w żądaniu
• Klient zmienia ID w URL panelu administracyjnego i uzyskuje dostęp do funkcji zarządzania
• Użytkownik manipuluje identyfikatorem w endpoincie, który powinien być dostępny tylko dla pracowników supportu

Eskalacja pionowa przez IDOR często prowadzi do pełnego przejęcia kontroli nad aplikacją, ponieważ zasoby administracyjne zawierają funkcje zarządzania użytkownikami, konfiguracją i danymi.

Manipulacja URL i parametrów

Najprostszą techniką eksploatacji IDOR jest bezpośrednia manipulacja parametrami w URL. Atakujący może modyfikować:

• Parametry query string: ?user_id=123 → ?user_id=124
• Fragmenty ścieżki: /api/users/123/profile → /api/users/124/profile
• Parametry w ciele żądania POST: {"invoice_id": 5001} → {"invoice_id": 5002}
• Nagłówki HTTP: X-User-Id: 123 → X-User-Id: 124
• Wartości ciasteczek: user_session=base64(user_id=123) → dekodowanie, zmiana, ponowne kodowanie

Atakujący nie musi ograniczać się do sekwencyjnych numerów. Jeśli zna format identyfikatorów (np. daty, nazwy plików, numery PESEL), może generować prawidłowe wartości.

Przykłady ataków IDOR w praktyce

IDOR nie jest podatnością teoretyczną — regularnie prowadzi do poważnych naruszeń danych w rzeczywistych systemach. Poniższe przypadki ilustrują skalę problemu.

Przypadek: platformy finansowe

W 2019 roku badacz bezpieczeństwa odkrył IDOR w aplikacji jednego z amerykańskich banków, który pozwalał na pobranie wyciągów bankowych dowolnego klienta poprzez zmianę numerycznego identyfikatora w endpoincie API. Podatność istniała od kilku lat i potencjalnie narażała miliony klientów. Wystarczyło zmienić jeden parametr w żądaniu HTTP, aby uzyskać dostęp do pełnych danych finansowych — sald, historii transakcji i danych osobowych.

Przypadek: serwisy społecznościowe

W 2015 roku odkryto IDOR w jednym z największych serwisów społecznościowych, który pozwalał na usuwanie dowolnych zdjęć innych użytkowników. Mechanizm był prosty — endpoint do usuwania zdjęcia przyjmował ID zdjęcia bez weryfikacji, czy zalogowany użytkownik jest jego właścicielem. Badacz, który zgłosił podatność w ramach programu bug bounty, otrzymał nagrodę w wysokości 12 500 USD.

Przypadek: platformy e-commerce

Podatności IDOR są niezwykle powszechne w platformach e-commerce, gdzie obiekty takie jak zamówienia, faktury, adresy dostawy i dane płatnicze są dostępne pod przewidywalnymi identyfikatorami. W jednym z przypadków zmiana ID zamówienia w endpoincie REST pozwalała nie tylko na odczyt danych zamówienia innego klienta, ale także na modyfikację adresu dostawy — co umożliwiało przekierowanie paczki do atakującego.

Przypadek: systemy medyczne

Systemy ochrony zdrowia są szczególnie narażone na IDOR ze względu na wrażliwość danych medycznych. Raport z 2022 roku wykazał, że ponad 30% badanych portali pacjentów zawierało podatności IDOR umożliwiające dostęp do wyników badań, diagnoz i historii wizyt innych pacjentów. W świetle regulacji takich jak RODO, każdy taki incydent oznacza nie tylko naruszenie prywatności, ale także potencjalne kary finansowe sięgające milionów euro.

Przypadek: programy bug bounty

Platformy bug bounty takie jak HackerOne i Bugcrowd publikują statystyki, z których wynika, że IDOR konsekwentnie plasuje się wśród najczęściej zgłaszanych podatności. W raporcie HackerOne z 2023 roku IDOR stanowił około 15% wszystkich zgłoszonych podatności, a średnia nagroda za krytyczny IDOR wynosiła 3000-5000 USD. Niektóre zgłoszenia IDOR w aplikacjach obsługujących dane finansowe lub medyczne były wyceniane na kilkadziesiąt tysięcy dolarów.

Jak testować aplikacje pod kątem IDOR?

Skuteczne testowanie IDOR wymaga systematycznego podejścia i odpowiednich narzędzi. Poniżej przedstawiamy metodologię stosowaną przez profesjonalnych pentesterów.

Przygotowanie środowiska testowego

Przed rozpoczęciem testów IDOR potrzebne są co najmniej dwa konta użytkowników o tym samym poziomie uprawnień (do testowania eskalacji poziomej) oraz konta o różnych poziomach uprawnień (do testowania eskalacji pionowej). Kluczowe jest mapowanie wszystkich endpointów, które operują na identyfikatorach obiektów — zarówno w URL, jak i w ciele żądania.

Burp Suite — podstawowe narzędzie

Burp Suite to standard branżowy w testowaniu bezpieczeństwa aplikacji webowych i doskonałe narzędzie do wykrywania IDOR. Proces testowania wygląda następująco:

1. Przechwycenie żądań: Skonfiguruj Burp jako proxy przeglądarki i wykonaj normalne operacje na koncie użytkownika A — przeglądaj profil, zamówienia, pliki. Burp zapisze wszystkie żądania w historii.
2. Identyfikacja identyfikatorów: Przejrzyj przechwycone żądania i zidentyfikuj parametry zawierające identyfikatory obiektów — numeryczne ID, UUID, nazwy plików, tokeny.
3. Podmiana kontekstu: Zaloguj się na konto użytkownika B, skopiuj jego ciasteczko sesji i za pomocą Burp Repeater wyślij żądania użytkownika A z sesją użytkownika B, zachowując oryginalne identyfikatory obiektów użytkownika A.
4. Analiza odpowiedzi: Jeśli serwer zwraca dane użytkownika A mimo autoryzacji sesji użytkownika B — mamy IDOR.

Rozszerzenie Autorize dla Burp Suite automatyzuje ten proces, automatycznie powtarzając żądania z różnymi ciasteczkami sesji i porównując odpowiedzi.

Testowanie autoryzacji krok po kroku

Systematyczny test autoryzacji powinien obejmować:

• Dostęp do zasobów innych użytkowników: Zmień ID w każdym endpoincie i sprawdź, czy otrzymujesz dane innego użytkownika
• Modyfikacja cudzych zasobów: Spróbuj edytować, usunąć lub zmienić status obiektu należącego do innego użytkownika
• Dostęp bez uwierzytelnienia: Usuń ciasteczko sesji i sprawdź, czy endpointy zwracają dane bez logowania
• Eskalacja uprawnień: Spróbuj uzyskać dostęp do endpointów administracyjnych z konta zwykłego użytkownika
• Manipulacja identyfikatorami w różnych formatach: Testuj nie tylko URL, ale także parametry POST, nagłówki i ciasteczka

Automatyzacja testów

Oprócz testów manualnych warto wdrożyć automatyczne testy autoryzacji w pipeline CI/CD. Frameworki takie jak OWASP ZAP (Zed Attack Proxy) oferują tryb automatyczny, który potrafi wykryć podstawowe przypadki IDOR. Jednak ze względu na logikę biznesową specyficzną dla każdej aplikacji, testy automatyczne nie zastąpią pentestów manualnych — stanowią jedynie pierwszą linię obrony.

Czego szukać w kodzie (code review)

Podczas przeglądu kodu warto zwrócić uwagę na następujące wzorce, które mogą sygnalizować podatność IDOR:

• Zapytania do bazy danych, które pobierają obiekty wyłącznie na podstawie ID z żądania, bez filtrowania po identyfikatorze zalogowanego użytkownika
• Endpointy, które nie wywołują żadnej logiki autoryzacji przed zwróceniem danych
• Kontrolery, które przyjmują ID użytkownika jako parametr zamiast pobierać go z sesji
• Operacje na plikach, gdzie ścieżka do pliku jest konstruowana na podstawie danych wejściowych użytkownika

Jak zapobiegać IDOR?

Obrona przed IDOR wymaga wielowarstwowego podejścia obejmującego architekturę aplikacji, wzorce kodowania i procedury testowe. Żadne pojedyncze rozwiązanie nie eliminuje problemu — skuteczna ochrona to kombinacja kilku mechanizmów.

Indirect Object References (pośrednie odwołania do obiektów)

Zamiast eksponować wewnętrzne identyfikatory bazodanowe bezpośrednio w URL lub parametrach API, aplikacja może mapować je na tymczasowe, losowe identyfikatory powiązane z sesją użytkownika. Użytkownik operuje na identyfikatorze ref=a8f3e2, który jest ważny tylko w kontekście jego sesji i mapowany na wewnętrzne id=10421 po stronie serwera.

Takie podejście — znane jako indirect reference map — sprawia, że nawet jeśli atakujący zmieni identyfikator, trafi na mapowanie nieistniejące w jego sesji. Wadą jest dodatkowa złożoność po stronie serwera i konieczność zarządzania mapowaniami w pamięci sesji.

UUID zamiast sekwencyjnych identyfikatorów

Zastąpienie auto-incrementowanych ID (1, 2, 3…) identyfikatorami UUID v4 (np. 550e8400-e29b-41d4-a716-446655440000) eliminuje możliwość iterowania po kolejnych wartościach. UUID v4 generowany losowo ma przestrzeń 2^122 możliwych wartości — odgadnięcie prawidłowego identyfikatora jest praktycznie niemożliwe.

Należy jednak pamiętać, że UUID to obrona przed enumeracją, a nie przed IDOR jako takim. Jeśli atakujący pozna UUID (np. z wyciekniętego linku, logów, odpowiedzi API), nadal może uzyskać nieautoryzowany dostęp, jeśli aplikacja nie sprawdza uprawnień. UUID powinien być stosowany jako warstwa dodatkowa, nie jako jedyny mechanizm obrony.

Ważne zastrzeżenie: nie wszystkie wersje UUID są bezpieczne w tym kontekście. UUID v1 zawiera timestamp i adres MAC, co czyni go częściowo przewidywalnym. Zawsze używaj UUID v4 (losowy) lub UUID v7 (timestamp + random, sortable).

Sprawdzanie autoryzacji na poziomie obiektu (Object-Level Authorization)

To najważniejszy mechanizm obrony przed IDOR. Każde żądanie dostępu do zasobu musi zawierać jawne sprawdzenie, czy zalogowany użytkownik ma prawo do tego konkretnego obiektu. W pseudokodzie:

def get_order(request, order_id):
    order = db.get_order(order_id)
    if order is None:
        return 404
    if order.user_id != request.current_user.id:
        return 403  # Forbidden
    return order

Kluczowa jest kolejność operacji: najpierw pobierz obiekt, następnie zweryfikuj uprawnienia, dopiero potem zwróć dane. Wielu developerów popełnia błąd polegający na tym, że sprawdzenie uprawnień jest opcjonalne lub następuje zbyt późno w procesie przetwarzania żądania.

W bardziej złożonych systemach kontrola dostępu powinna być zrealizowana jako dedykowany middleware lub dekorator, który jest stosowany automatycznie do wszystkich endpointów operujących na zasobach użytkowników. Dzięki temu ryzyko pominięcia sprawdzenia w nowym endpoincie jest minimalne.

Architektura „deny by default”

Architektura aplikacji powinna zakładać, że dostęp do zasobu jest domyślnie zabroniony, a musi zostać jawnie przyznany. Każdy nowy endpoint powinien wymagać jawnego zdefiniowania reguł autoryzacji — brak definicji oznacza brak dostępu. To odwrócenie typowego podejścia, w którym nowe endpointy są domyślnie otwarte, a developer musi pamiętać o dodaniu ograniczeń.

W praktyce oznacza to framework lub middleware, który:

• Blokuje każde żądanie, dla którego nie zdefiniowano polityki dostępu
• Wymusza deklarację uprawnień dla każdego endpointu
• Loguje przypadki, w których endpoint nie ma zdefiniowanej polityki (jako ostrzeżenie bezpieczeństwa)

Rate limiting i monitoring

Nawet jeśli IDOR istnieje w aplikacji, skuteczny monitoring może wykryć próbę eksploatacji. Automatyczne iterowanie po identyfikatorach generuje charakterystyczny wzorzec ruchu — setki lub tysiące żądań do tego samego endpointu z sekwencyjnie zmieniającymi się parametrami. Systemy WAF i SIEM powinny być skonfigurowane do wykrywania takich anomalii.

Rate limiting ogranicza liczbę żądań z jednego źródła w jednostce czasu, co spowalnia automatyczne enumerowanie, choć nie eliminuje problemu u źródła.

IDOR w API — REST i GraphQL

Interfejsy API są szczególnie narażone na IDOR, ponieważ operują bezpośrednio na identyfikatorach obiektów i są projektowane do programistycznego dostępu, co ułatwia automatyzację ataków.

IDOR w REST API

REST API z natury eksponuje identyfikatory obiektów w ścieżkach URL — /api/v1/users/123/orders/456 bezpośrednio wskazuje na użytkownika 123 i zamówienie 456. To sprawia, że każdy endpoint operujący na zasobach jest potencjalnym wektorem IDOR.

Typowe podatne wzorce w REST API:

GET /api/users/{user_id}/documents          # Lista dokumentów użytkownika
GET /api/invoices/{invoice_id}/pdf           # Pobranie faktury
PUT /api/orders/{order_id}/status            # Zmiana statusu zamówienia
DELETE /api/comments/{comment_id}            # Usunięcie komentarza

Każdy z tych endpointów musi weryfikować, czy zalogowany użytkownik ma prawo do operacji na obiekcie o podanym identyfikatorze.

Dodatkowy problem w REST API to relacje zagnieżdżone. Endpoint /api/users/123/orders/456 sugeruje, że zamówienie 456 należy do użytkownika 123, ale atakujący może spróbować /api/users/124/orders/456 — co powinno być odrzucone, ale nie zawsze jest. Walidacja musi obejmować nie tylko uprawnienia do obiektu końcowego, ale również spójność całej ścieżki.

IDOR w GraphQL

GraphQL wprowadza dodatkowe wyzwania ze względu na swoją elastyczność. Pojedyncze zapytanie GraphQL może pobierać dane z wielu powiązanych obiektów jednocześnie, co zwiększa powierzchnię ataku.

query {
  user(id: "123") {
    name
    email
    orders {
      id
      total
      items {
        name
        price
      }
    }
    paymentMethods {
      cardNumber
      expiryDate
    }
  }
}

Jeśli autoryzacja jest sprawdzana tylko na poziomie głównego obiektu user, ale nie na poziomie zagnieżdżonych orders i paymentMethods, atakujący może uzyskać dostęp do wrażliwych danych. Co więcej, introspection w GraphQL pozwala atakującemu odkryć wszystkie dostępne typy i pola, co ułatwia identyfikację potencjalnych celów IDOR.

Obrona w GraphQL wymaga autoryzacji na poziomie każdego resolvera — nie tylko na poziomie zapytania głównego. Każdy resolver pobierający dane powinien weryfikować, czy zalogowany użytkownik ma prawo do zwracanych obiektów.

BOLA — nomenklatura OWASP API Security

W kontekście bezpieczeństwa API, OWASP API Security Top 10 (2023) używa terminu BOLA (Broken Object Level Authorization) jako odpowiednika IDOR. BOLA zajmuje pozycję API1:2023, co podkreśla, że jest to najpoważniejsza podatność w interfejsach API. Termin BOLA precyzyjniej opisuje naturę problemu — to nie „niezabezpieczone odwołanie” jest problemem, lecz brak autoryzacji na poziomie obiektu.

OWASP API Security Top 10 wyróżnia również pokrewną podatność BFLA (Broken Function Level Authorization) na pozycji API5:2023, która dotyczy braku autoryzacji na poziomie funkcji (np. zwykły użytkownik wywołuje endpoint administracyjny). BOLA i BFLA to dwie strony tego samego medalu — kontroli dostępu.

Best practices dla developerów

Poniższe rekomendacje stanowią zbiór najlepszych praktyk, które zespoły developerskie powinny wdrożyć, aby minimalizować ryzyko IDOR w swoich aplikacjach.

1. Autoryzacja jako warstwa architektoniczna

Kontrola dostępu nie powinna być implementowana ad hoc w każdym kontrolerze. Zamiast tego powinna stanowić dedykowaną warstwę architektoniczną — middleware, dekorator lub interceptor — która jest stosowana automatycznie do wszystkich endpointów. Centralny punkt autoryzacji ułatwia audyt, testowanie i utrzymanie spójności reguł dostępu.

# Zamiast tego (łatwo zapomnieć w nowym endpoincie):
@app.get("/orders/{order_id}")
def get_order(order_id: int, user: User):
    order = db.get(order_id)
    if order.user_id != user.id:  # Łatwo pominąć
        raise Forbidden()
    return order

# Lepiej tak (automatyczne sprawdzanie):
@app.get("/orders/{order_id}")
@require_ownership("order")  # Dekorator wymusza autoryzację
def get_order(order_id: int, user: User):
    return db.get(order_id)

2. Testy autoryzacji w CI/CD

Testy jednostkowe i integracyjne powinny zawierać scenariusze, w których jeden użytkownik próbuje uzyskać dostęp do zasobów innego użytkownika. Każdy endpoint operujący na zasobach powinien mieć test negatywny weryfikujący, że nieautoryzowany dostęp jest blokowany. Testy te powinny być uruchamiane automatycznie w pipeline CI/CD, aby zapobiec regresji.

Minimalny zestaw testów autoryzacji:

• Użytkownik A nie może odczytać zasobów użytkownika B (GET)
• Użytkownik A nie może modyfikować zasobów użytkownika B (PUT/PATCH)
• Użytkownik A nie może usuwać zasobów użytkownika B (DELETE)
• Użytkownik bez uprawnień admina nie może uzyskać dostępu do endpointów administracyjnych
• Niezalogowany użytkownik nie może uzyskać dostępu do chronionych zasobów

3. Pobieranie kontekstu z sesji, nie z żądania

Identyfikator zalogowanego użytkownika powinien być pobierany z sesji po stronie serwera, a nie z parametrów żądania. Endpoint nie powinien przyjmować user_id jako parametru — powinien pobierać go automatycznie z uwierzytelnionej sesji. To eliminuje możliwość podmiany tożsamości.

4. Logowanie i alerty

Każda próba dostępu do zasobu, która kończy się odmową (403 Forbidden), powinna być logowana ze szczegółami: kto próbował, do jakiego zasobu, kiedy i z jakiego adresu IP. Wielokrotne odmowy z tego samego źródła powinny generować alert bezpieczeństwa.

5. Minimalna ekspozycja identyfikatorów

Nie ujawniaj identyfikatorów obiektów, gdy nie jest to konieczne. Odpowiedzi API nie powinny zawierać identyfikatorów obiektów innych użytkowników. Na przykład lista zamówień nie powinna zawierać user_id właściciela — ta informacja jest zbędna z perspektywy klienta API i może ułatwić atakującemu identyfikację celów.

6. Spójne nazewnictwo i konwencje

Ustal konwencję, w której każdy endpoint operujący na zasobach używytkownika korzysta z tego samego mechanizmu autoryzacji. Niezależnie czy to /orders/{id}, /invoices/{id} czy /documents/{id} — logika sprawdzania uprawnień powinna być identyczna i wymuszona frameworkowo.

7. Regularne przeglądy bezpieczeństwa

Code review powinien zawierać obowiązkowy checklist bezpieczeństwa, w którym reviewer weryfikuje, czy nowe endpointy mają zaimplementowaną autoryzację na poziomie obiektu. Dodatkowo regularne testy penetracyjne przez zewnętrzny zespół pozwalają wykryć IDOR, który umknął wewnętrznym testom.

Najczęściej Zadawane Pytania (FAQ)

Czym dokładnie jest IDOR?

IDOR (Insecure Direct Object Reference) to podatność polegająca na tym, że aplikacja używa identyfikatorów obiektów podanych przez użytkownika (np. ID w URL) do bezpośredniego dostępu do zasobów, bez weryfikacji czy dany użytkownik ma do nich uprawnienia. Atakujący może zmienić identyfikator i uzyskać dostęp do cudzych danych.

Czy IDOR dotyczy tylko aplikacji webowych?

Nie. IDOR występuje wszędzie tam, gdzie aplikacja udostępnia zasoby na podstawie identyfikatorów kontrolowanych przez użytkownika — w aplikacjach webowych, mobilnych, API REST, GraphQL, a nawet w usługach chmurowych. Każdy system, który nie weryfikuje uprawnień przy dostępie do obiektów, może być podatny.

Czy użycie UUID zamiast numerycznych ID eliminuje IDOR?

Nie eliminuje, ale znacząco utrudnia eksploatację. UUID są trudne do odgadnięcia, co uniemożliwia proste iterowanie po identyfikatorach. Jednak UUID nie zastępuje kontroli autoryzacji — jeśli atakujący pozna UUID (np. z logów, URL-i w e-mailach), nadal może uzyskać nieautoryzowany dostęp bez odpowiednich sprawdzeń uprawnień.

Jak szybko można wykryć IDOR w aplikacji?

Podstawowe testy IDOR można przeprowadzić w kilka minut — wystarczy zalogować się na dwa konta, skopiować identyfikator zasobu jednego użytkownika i spróbować uzyskać do niego dostęp z drugiego konta. Kompleksowy audyt wymaga jednak systematycznego testowania wszystkich endpointów, co przy dużych aplikacjach może zająć od kilku godzin do kilku dni.

Gdzie w OWASP Top 10 znajduje się IDOR?

Od 2021 roku IDOR jest częścią kategorii A01:2021 Broken Access Control, która zajmuje pierwsze miejsce w OWASP Top 10. Wcześniej IDOR miał osobną kategorię (A4 w OWASP Top 10 2013). Przesunięcie na pozycję A01 odzwierciedla skalę problemu — błędy kontroli dostępu są najczęściej wykrywaną kategorią podatności w aplikacjach webowych.

Podsumowanie

IDOR to podatność, która łączy pozorną prostotę mechanizmu z potencjalnie katastrofalnymi konsekwencjami. Zmiana jednej cyfry w URL może prowadzić do wycieku danych milionów użytkowników, naruszenia prywatności pacjentów czy kradzieży danych finansowych. Fakt, że Broken Access Control — kategoria obejmująca IDOR — zajmuje pierwsze miejsce w OWASP Top 10, nie jest przypadkowy.

Skuteczna obrona wymaga podejścia wielowarstwowego: zastąpienia przewidywalnych identyfikatorów losowymi UUID, wdrożenia autoryzacji na poziomie każdego obiektu, automatycznych testów bezpieczeństwa w CI/CD oraz regularnych przeglądów kodu i testów penetracyjnych. Żaden z tych mechanizmów nie jest wystarczający sam w sobie — dopiero ich kombinacja zapewnia solidną ochronę.

Kluczowa zmiana perspektywy, jakiej wymaga obrona przed IDOR, to przesunięcie myślenia z uwierzytelniania na autoryzację. Odpowiedź na pytanie „czy użytkownik jest zalogowany?” to dopiero początek. Prawdziwe bezpieczeństwo zaczyna się od pytania „czy ten zalogowany użytkownik ma prawo do tego konkretnego zasobu?” — i konsekwentnego zadawania tego pytania przy każdym żądaniu, w każdym endpoincie, bez wyjątków.