Les références directes d'objets non sécurisées, communément appelées IDOR, restent l'une des classes de vulnérabilités applicatives les plus courantes et les plus dommageables. Bien qu'elles soient bien documentées et largement comprises au niveau conceptuel, elles continuent d'apparaître dans les systèmes de production réels, en particulier dans les applications modernes basées sur des API.
Une vulnérabilité IDOR se produit lorsqu'une application utilise un identifiant fourni par l'utilisateur pour accéder à un objet interne sans vérifier que l'utilisateur actuel est autorisé à accéder à cet objet spécifique. Ce problème s'inscrit dans la catégorie plus large du contrôle d’accès défaillant, mais il se distingue par sa manifestation et par la difficulté de l'éliminer complètement.
Les IDOR persistent non pas parce que les équipes n'en sont pas conscientes, mais parce qu'elles découlent de l'évolution des systèmes réels. Elles sont souvent introduites aux limites des workflows, lors de refactorisations, ou lorsque des hypothèses de propriété sont réutilisées à travers des étapes qui n'étaient pas initialement conçues pour être connectées. Cet article explique à quoi ressemblent les IDOR en pratique, pourquoi les approches courantes de tests de sécurité peinent à les détecter de manière fiable, et comment les techniques de test modernes valident les échecs de propriété dans les systèmes en cours d'exécution.
Qu'est-ce qu'une référence directe d'objet non sécurisée en pratique ?
Une vulnérabilité IDOR se produit lorsqu'une application accepte un identifiant qui référence un objet interne, tel qu'un enregistrement, un document ou un compte, et l'utilise directement sans appliquer de manière cohérente l'autorisation pour cet objet.
Les identifiants apparaissent couramment sous forme de :
- ID utilisateur dans les chemins d'URL
- IDs de commande ou de facture dans les paramètres de requête
- Identifiants de ressources dans les corps de requêtes
La vulnérabilité n'est pas l'identifiant lui-même. Elle réside dans l'hypothèse que l'identifiant appartient à l'utilisateur authentifié, sans revalider cette hypothèse sur le serveur.
Dans les applications modernes, cette hypothèse est souvent valable dans la plupart des cas, mais pas tous. C'est cette incohérence qui donne lieu aux vulnérabilités IDOR.
Pourquoi les vulnérabilités IDOR sont particulièrement dangereuses dans les API
Dans la littérature sur la sécurité des API, les IDOR sont souvent désignées sous le nom de Broken Object Level Authorization (BOLA), le risque le plus élevé du Top 10 de la sécurité des API de l'OWASP. L'OWASP a adopté le terme BOLA pour s'adapter à la conception moderne des API.
Les API exposent les fonctionnalités et les données essentielles des applications. Lorsqu'une vulnérabilité IDOR existe dans une API, les attaquants peuvent souvent l'exploiter à grande échelle.
Les impacts courants incluent :
- Accès à des données sensibles appartenant à d'autres utilisateurs
- Modification ou suppression de ressources détenues par d'autres
- Contournement des règles métier liées à la propriété ou au rôle
- Compromission des workflows tels que les approbations, la facturation ou la gestion de compte
Étant donné que les API sont conçues pour l'automatisation, un seul contrôle de propriété manquant peut compromettre de larges portions d'un système.
Types courants de vulnérabilités IDOR
IDOR est un terme générique. En pratique, les équipes rencontrent plusieurs schémas récurrents :
- IDOR horizontale : Un utilisateur accède aux objets d'un autre utilisateur au même niveau de privilège
- IDOR verticale : Les identifiants permettent d'accéder à des objets privilégiés ou administratifs
- IDOR aveugle : La réponse n'expose pas de données, mais l'action réussit sur l'objet de quelqu'un d'autre
Les IDOR aveugles sont particulièrement faciles à manquer avec des outils qui se concentrent sur l'exposition évidente de données. Elles nécessitent souvent une validation explicite pour confirmer l'impact.
Comment les vulnérabilités IDOR sont traditionnellement testées en pratique
Lors d'un test d'intrusion, le test des IDOR est généralement effectué par une relecture et une comparaison minutieuses des requêtes.
En pratique, cela implique :
- S'authentifier en tant qu'utilisateur légitime
- Exécuter des flux de travail via l'interface utilisateur
- Capturer les requêtes envoyées par le navigateur ou le client
- Rejouer ces requêtes avec un utilisateur authentifié différent
- Comparer les réponses pour voir si le comportement change
Par exemple, si une requête qui ne devrait renvoyer des données que pour l'utilisateur A renvoie les mêmes données lorsqu'elle est rejouée en tant qu'utilisateur B, cela indique un contrôle d’accès défaillant.
Cette approche est efficace et largement utilisée. Elle repose sur la compréhension de l'intention de l'application par le testeur et sur sa capacité à déterminer quelles requêtes sont sensibles en matière de sécurité.
Cependant, elle est également intrinsèquement manuelle et chronophage. Chaque workflow, rôle ou transition d'état supplémentaire multiplie le nombre de requêtes à capturer, rejouer et interpréter. À mesure que les applications deviennent plus complexes, il devient irréalisable d'appliquer cette comparaison de manière exhaustive sur tous les chemins possibles.
C'est pourquoi les tests manuels trouvent souvent des IDOR dans les zones qui reçoivent une attention particulière, mais ne peuvent garantir une couverture exhaustive.
Pourquoi les outils DAST manquent les véritables vulnérabilités IDOR
Les outils de Tests de sécurité des applications dynamiques opèrent au niveau de la requête. Ils explorent les endpoints, fuzzent les entrées et recherchent les réponses anormales. Ce qu'ils ne comprennent pas, c'est l'intention. Un scanner ne sait pas si une facture donnée appartient à l'utilisateur A ou à l'utilisateur B. Il ne raisonne pas sur la propriété, le contexte du workflow ou si une réponse est appropriée pour l'identité authentifiée. Tant que l'application répond correctement, souvent avec un 200 OK, un scanner peut considérer l'interaction comme réussie même lorsque des données sensibles sont exposées au mauvais utilisateur.
Cela rend le DAST utile pour les problèmes superficiels, mais fondamentalement limité en ce qui concerne les IDOR et autres échecs d'autorisation qui dépendent de la propriété des objets et du contexte. Cette limitation n'est pas spécifique à un seul outil. Elle reflète le fait que l'analyse au niveau de la requête, même bien implémentée, ne dispose pas d'un contexte suffisant pour raisonner sur la propriété des objets et l'intention du workflow.
Pourquoi l'analyse statique génère du bruit autour des IDOR
De nombreuses équipes s'appuient sur des outils d'analyse statique pour signaler les problèmes potentiels d'IDOR. Ces outils recherchent généralement des schémas où des identifiants sont passés à des gestionnaires (handlers) ou des contrôleurs sans vérifications d'autorisation évidentes à proximité.
Cela produit souvent un grand nombre de résultats.
En pratique, la plupart d'entre eux sont des faux positifs. Les vérifications d'autorisation existent fréquemment ailleurs dans la chaîne d'appels, dans des middlewares partagés, ou au niveau d'un framework. L'analyse statique ne peut pas déterminer de manière fiable si un identifiant est exploitable en temps d'exécution.
Ce problème est amplifié lorsque l'autorisation est implémentée implicitement ou distribuée sur plusieurs couches, notamment :
- Contrôle d'accès appliqué par des middlewares ou des décorateurs
- Vérifications implémentées dans des services partagés ou des méthodes de modèle
- Logique de permission répartie sur plusieurs fichiers et chemins d'appel
Dans ces cas, les outils statiques voient un identifiant et un chemin d'accès aux données, mais manquent le contexte d'autorisation complet. Le résultat est un volume élevé de résultats plausibles mais avec une faible confiance.
C'est une limitation fondamentale de l'analyse statique. Sans état d'exécution et contexte d'identité, aucune analyse au niveau du code ne peut déterminer de manière fiable si une référence d'objet est exploitable en pratique.
Même les outils d'analyse statique assistés par l'IA restent prédictifs. Ils raisonnent sur la structure du code, mais ne peuvent pas confirmer le comportement en temps d'exécution. En conséquence, les résultats de type IDOR ont souvent des taux de faux positifs dépassant cinquante pour cent, forçant les équipes à trier des problèmes théoriques tandis que les véritables échecs de propriété risquent d'être ignorés.
Le problème fondamental : la propriété est contextuelle
Les IDOR ne sont pas de simples vérifications manquantes. Ce sont des échecs d'autorisation contextuelle liés à la propriété des objets.
La propriété est établie par une combinaison de :
- État d'authentification
- Modèles de rôles et de permissions
- Progression du workflow
- État côté serveur créé plus tôt dans un processus
Si une partie de ce contexte est supposée plutôt que revalidée, une vulnérabilité IDOR peut apparaître.
Certaines vulnérabilités IDOR sont de second ordre. Un identifiant est accepté à une étape, stocké, et n'est utilisé que plus tard lorsque le contrôle d'accès n'est plus vérifié. Ces problèmes sont particulièrement difficiles à détecter car l'exploitation est séparée dans le temps et les étapes.
Tester les vulnérabilités IDOR de manière fiable nécessite de poser à plusieurs reprises une question simple : que se passe-t-il si cet identifiant appartient à quelqu'un d'autre ?
Les UUID n'empêchent pas les vulnérabilités IDOR
C'est une idée fausse courante de penser que passer des identifiants séquentiels aux UUID élimine le risque d'IDOR.
Les identifiants imprévisibles réduisent les attaques par force brute. Ils n'empêchent pas l'accès non autorisé si les vérifications de propriété sont absentes.
Dans les systèmes réels, les attaquants obtiennent des identifiants via le comportement normal de l'application, notamment :
- Références renvoyées par d'autres endpoints
- Liens et URL partagés
- Messages et notifications in-app
- Journaux, exports et historique de navigation
Si un attaquant peut obtenir un identifiant valide et que le backend n'applique pas la propriété, une vulnérabilité IDOR existe toujours.
Comment le pentest IA trouve les vulnérabilités IDOR que d'autres manquent
Le pentest IA adopte une approche différente pour identifier les échecs d'autorisation.
Plutôt que de s'arrêter à la détection, il teste activement des hypothèses sur la propriété et le contrôle d'accès dans une application en cours d'exécution.
Au sein d'Aikido, cette approche est mise en œuvre via Aikido Attack, un test d'intrusion autonome qui allie la créativité humaine à la vitesse des machines. Il est conçu pour évaluer les échecs d'autorisation et de propriété dans des environnements réels. Aikido Attack opère en utilisant de vraies identités, exécute des workflows de bout en bout et valide l'exploitabilité avant de signaler les découvertes.
Pour les vulnérabilités IDOR, ce processus implique :
- S'authentifier en tant qu'utilisateurs réels
- Exécuter des workflows complets de bout en bout
- Réutiliser les identifiants d'objets à travers les rôles et les contextes
- Tenter d'accéder ou de modifier des ressources appartenant à d'autres utilisateurs
- Valider si le comportement est exploitable et reproductible
Seuls les problèmes exploitables en pratique sont signalés. Les autres sont automatiquement écartés.
Cela réduit les faux positifs et garantit que les découvertes signalées représentent de réels échecs d'autorisation. Dans les situations où l'intention n'est pas claire, un testeur humain devrait normalement consulter le propriétaire de l'application. La validation en temps d'exécution résout ce problème directement.
Tests ciblés des hypothèses de propriété
Le pentest IA consacre des efforts dédiés à l'évaluation des hypothèses de propriété liées aux identifiants d'objets au sein d'une application.
Plutôt que de considérer les IDOR comme un effet secondaire des tests génériques, il se concentre explicitement sur :
- Les identifiants liés aux ressources appartenant à l'utilisateur
- Les transitions de workflow qui réutilisent des références d'objets
- Les endpoints backend qui s'appuient sur les hypothèses de propriété du frontend
Cela assure une couverture cohérente des parties d'un système où les IDOR se produisent réellement.
Exemple : IDOR dans un workflow d'approbation multi-étapes
Cet exemple illustre comment un IDOR peut émerger à travers plusieurs étapes de workflow, même lorsque les points de terminaison individuels semblent appliquer correctement le contrôle d'accès.
Contexte de l'application
L'application comprend un workflow d'approbation multi-étapes pour les actions sensibles. Un utilisateur crée une requête qui doit ensuite être examinée et approuvée. Chaque requête est liée à l'utilisateur qui l'a créée et est référencée par un identifiant utilisé à travers plusieurs appels d'API.
Seul le propriétaire d'une requête est censé la consulter ou la modifier avant approbation.
Ce que le système a observé
Le pentest IA s'est authentifié en tant qu'utilisateur standard et a exécuté le flux de création de requête. Au cours de ce processus, le système a stocké l'état intermédiaire du workflow sur le serveur et l'a réutilisé lors des étapes ultérieures.
Les vérifications initiales de propriété ont été correctement appliquées lors de la création de la requête.
Tests de propriété à travers le workflow
Des tests supplémentaires ont évalué comment l'identifiant de la requête était utilisé dans les étapes ultérieures. Il a été observé que :
- L'identifiant était réutilisé lors de la reprise d'une requête en attente
- Les appels d'API ultérieurs ont supposé la propriété basée sur une validation antérieure
- La propriété n'était pas revalidée lors de la reprise du workflow
En rejouant l'action de reprise avec un utilisateur authentifié différent et en substituant l'identifiant de la requête, le système a pu accéder et agir sur une requête qu'il ne possédait pas.
Pourquoi il s'agissait d'une vulnérabilité IDOR
Le problème ne provenait pas d'un simple contrôle manquant.
Il résultait d'une hypothèse selon laquelle la propriété avait déjà été validée plus tôt dans le workflow et n'avait pas besoin d'être revérifiée lors de la reprise de la requête. Cette hypothèse a échoué une fois que les identifiants d'objets ont été réutilisés entre utilisateurs.
Validation et reproductibilité
Avant de signaler le problème, le système :
- A rejoué la séquence complète plusieurs fois
- A confirmé un comportement cohérent
- A capturé des preuves d'accès non autorisé
Le problème n'a été signalé qu'après confirmation de sa reproductibilité et de son impact.
Pourquoi d'autres approches passeraient à côté
Chaque endpoint individuel se comportait correctement de manière isolée. La vulnérabilité n'est apparue que lorsque :
- Un workflow était partiellement achevé
- L'état côté serveur a été réutilisé
- Une étape ultérieure était invoquée en dehors du contexte utilisateur original
Cela a rendu le problème difficile à détecter par des tests manuels et invisible pour les outils de scan basés sur les requêtes.
Pourquoi le test continu est essentiel pour les vulnérabilités IDOR
Les IDOR sont souvent introduites par le changement.
Elles apparaissent fréquemment lorsque :
- De nouvelles fonctionnalités réutilisent des modèles de données existants
- Une logique d'autorisation est ajoutée à un endroit mais pas à un autre
- Les refactorisations contournent involontairement les vérifications de propriété antérieures
Un test ponctuel peut confirmer que la propriété est appliquée aujourd'hui, mais cette assurance se dégrade à mesure que l'application évolue.
Les tests continus basés sur l'IA maintiennent la confiance en réévaluant les hypothèses de propriété à mesure que le logiciel évolue. Les outils de pentest continu soutiennent cela en testant continuellement les workflows nouveaux et modifiés pour détecter les accès non autorisés aux objets.
Les vulnérabilités IDOR comme symptôme de la complexité des systèmes
Les IDOR ne sont pas des cas limites. Elles sont le résultat naturel de l'évolution des systèmes complexes au fil du temps.
À mesure que les applications se développent, la logique de propriété se répand à travers les services, les workflows et les couches. Les hypothèses s'accumulent, et le raisonnement sur l'accès au niveau des objets devient de plus en plus difficile.
Le pentest IA ne supprime pas cette complexité, mais il la rend testable.
En exerçant systématiquement les workflows, en suivant l'état et en validant la propriété dans le contexte, il transforme l'une des classes de vulnérabilités les plus persistantes en quelque chose qui peut être détecté plus tôt, plus régulièrement et avec une plus grande confiance.
Les équipes de sécurité accordent une priorité croissante aux IDOR et autres échecs d'autorisation car ils sont spécifiques au système, sujets aux régressions et difficiles à valider sans des tests en temps d'exécution qui tiennent compte des workflows.
Vous pourriez aussi aimer :
