IDOR : exploitation et détection des accès directs

IDOR, ou Insecure Direct Object Reference, désigne une faille de contrôle d'accès. Elle survient quand une application expose une référence directe à un objet interne (identifiant de base de données, nom de fichier, UUID) sans vérifier que l'utilisateur est autorisé à y accéder. L'exploitation des accès directs repose sur une manipulation simple : l'attaquant modifie un paramètre dans la requête HTTP pour atteindre une ressource qui ne lui appartient pas. Par exemple, changer user_id=1042 en user_id=1043 peut exposer les données d'un autre compte. L'IDOR est classé sous la catégorie OWASP A01 (Broken Access Control). Il touche aussi bien les applications web classiques que les API REST ou GraphQL. La faille est d'autant plus dangereuse que les objets référencés peuvent être des fichiers, des commandes, des documents médicaux ou des tokens de session. Elle résulte d'une absence de vérification côté serveur entre l'identité authentifiée et la ressource demandée. L'IDOR n'est pas un problème d'authentification : l'utilisateur est connecté, mais son niveau d'autorisation n'est pas contrôlé sur chaque requête.

La détection d'un IDOR côté SOC repose principalement sur l'analyse des logs applicatifs et des journaux d'accès aux API. Les principaux indicateurs sont des séquences de requêtes HTTP sur un même endpoint avec des identifiants incrémentaux ou aléatoires variants rapidement, générés par un seul compte utilisateur. Un volume anormalement élevé de requêtes GET ou POST vers des ressources distinctes en peu de temps est un signal fort. Les codes HTTP 200 renvoyés en réponse à ces requêtes confirment un accès effectif. Les outils SIEM comme Elastic ou Splunk permettent de corréler les user_id ou object_id avec le compte authentifié. Il faut surveiller les paramètres sensibles dans les URL (id, order_id, file, doc_id) et comparer leur valeur avec le contexte de session. Les WAF peuvent détecter des patterns d'énumération, mais ils ne remplacent pas la logique applicative. Côté audit, les logs doivent tracer chaque accès à une ressource avec l'identité de l'appelant. L'absence de logs granulaires au niveau des objets est elle-même un indicateur de risque. Un monitoring des erreurs 403 suivi d'un basculement vers des 200 après modification du paramètre révèle un contournement actif du contrôle d'accès.

En pentest, l'exploitation d'un IDOR commence par l'identification des endpoints exposant des références directes aux objets. L'outil Burp Suite est central : son module Intruder permet de fuzzer automatiquement les paramètres numériques ou alphanumériques. Les UUID ne sont pas une protection suffisante si leur génération est prédictible ou si l'application les expose dans d'autres réponses. Les attaques IDOR horizontales ciblent des ressources d'autres utilisateurs de même niveau. Les attaques verticales visent des ressources d'un rôle supérieur (admin, back-office). Les API REST sont particulièrement vulnérables sur les méthodes PUT, DELETE et PATCH. Les contre-mesures efficaces incluent l'implémentation d'une vérification d'autorisation côté serveur sur chaque requête, indépendamment du rôle de session. Il faut dissocier les identifiants internes des identifiants exposés à l'utilisateur, en utilisant des references indirectes ou des tokens opaques non prédictibles. Les frameworks modernes proposent des middlewares d'autorisation (policy-based authorization dans ASP.NET Core, CanCanCan en Rails). Les tests automatisés de régression doivent inclure des scénarios cross-account pour chaque endpoint sensible. Un IDOR non corrigé peut mener à une exfiltration massive de données personnelles, avec des conséquences directes sur la conformité RGPD.