Przejdź do głównej zawartości

Insecure Direct Object References (IDOR) & Broken Access Control

IDOR (Insecure Direct Object References) i Broken Access Control to jedne z najpoważniejszych podatności w aplikacjach webowych, umożliwiające nieautoryzowany dostęp do danych innych użytkowników poprzez manipulację parametrami.

Ataki na IDOR i manipulacja parametrami​

1️⃣ Na czym polega IDOR?​

IDOR występuje, gdy aplikacja udostępnia zasoby na podstawie identyfikatora (np. user_id), ale nie sprawdza, czy użytkownik ma do nich uprawnienia.

Przykładowy podatny endpoint​

GET /api/user/profile?user_id=123

Atakujący zmienia wartość user_id na inną:

GET /api/user/profile?user_id=456

Jeśli serwer zwraca profil innego użytkownika, to aplikacja jest podatna na IDOR.

2️⃣ Manipulacja parametrami ID w Burp Suite​

  1. Przechwyć żądanie w Burp Suite.
  2. Zmień wartość user_id na inną.
  3. Sprawdź, czy aplikacja zwraca dane innego użytkownika.

3️⃣ IDOR w operacjach zapisu​

Niektóre aplikacje pozwalają na edycję lub usuwanie cudzych danych:

POST /api/user/update?user_id=123&[email protected]

Jeśli można zmienić dane innego użytkownika, aplikacja jest podatna.

Narzędzia do wykrywania IDOR (Burp Suite, Autorize)​

1️⃣ Burp Suite – manualne testowanie IDOR​

Burp Suite umożliwia przechwytywanie i edytowanie żądań HTTP.

Kroki testowania:​

  1. Otwórz Burp Suite i przejdź do Proxy > Intercept.
  2. Przechwyć żądanie do API z identyfikatorem użytkownika.
  3. Zmień ID na inny i ponów żądanie.
  4. Sprawdź, czy aplikacja zwraca dane innego użytkownika.

2️⃣ Autorize – automatyczne wykrywanie IDOR​

Autorize to rozszerzenie do Burp Suite, które automatycznie testuje, czy użytkownik ma dostęp do nieautoryzowanych zasobów.

Jak używać Autorize?​

  1. Zainstaluj Autorize w Burp Suite.
  2. Przechwyć żądania autoryzowanego użytkownika.
  3. Uruchom testowanie z uprawnieniami gościa.
  4. Sprawdź, czy aplikacja nie zwraca wrażliwych danych.

3️⃣ Ffuf – automatyczne fuzzowanie IDOR​

Jeśli aplikacja używa sekwencyjnych ID:

ffuf -u "http://example.com/api/user/profile?user_id=FUZZ" -w id_list.txt

Sprawdza, które ID zwracają odpowiedzi.

Jak zabezpieczyć aplikację przed IDOR?​

✅ Weryfikacja uprawnień użytkownika na serwerze – nigdy nie ufaj parametrom z żądania. ✅ UUID jako obrona w głąb, nie zamiast kontroli – utrudnia rekonesans i ukrywa liczbę rekordów, ale nie jest kontrolą dostępu (patrz niżej). ✅ Ograniczenie dostępu do API na poziomie backendu – kontrola autoryzacji. ✅ Logowanie i monitorowanie podejrzanych zmian w parametrach – wykrywanie manipulacji.

🧭 Zasada: przewidywalny identyfikator nie jest podatnością — brak sprawdzenia jest. Odruch „zamień sekwencyjne ID na UUID” naprawia aplikację dokładnie do momentu, w którym identyfikator gdzieś wycieknie — a wycieka rutynowo: w nagłówku Referer, w logu proxy, w odpowiedzi innego endpointu, w linku z zaproszenia, przez Google dork. Losowy identyfikator jest utrudnieniem rekonesansu, nie kontrolą dostępu. Właściwa naprawa to sprawdzenie własności przy każdym odczycie i zapisie, najlepiej jednym zapytaniem „daj zasób id należący do bieżącego użytkownika”, a nie „daj zasób id, potem sprawdzę”. Konsekwencja dla testu: żeby udowodnić IDOR/BOLA, pokaż odpowiedź serwera na żądanie cudzego zasobu z własną sesją — sam zrzut z rosnącymi numerami niczego nie dowodzi. W Real-World Bug Hunting nawet triager HackerOne popełnił ten błąd, zamykając raport ACME jako „informative”, bo „ID nie do zgadnięcia” — dopiero wskazanie miejsca wycieku customer_id dało nagrodę. — Yaworski, Real-World Bug Hunting, rozdz. 16, s. 227–236; Ball, Hacking APIs

Ataki IDOR mogą prowadzić do wycieku wrażliwych danych i przejęcia kont użytkowników. Kolejnym krokiem będzie analiza podatności Security Misconfigurations i ataki na pliki!