Vulnérabilités IDOR expliquées : Pourquoi elles persistent dans les applications modernes

Les références directes à des objets non sécurisées, communément appelées IDOR, restent l'une des catégories de vulnérabilités applicatives les plus courantes et les plus dommageables. Bien qu'elles soient bien documentées et largement comprises sur le plan 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 des contrôle d’accès défaillant, mais il se distingue par la manière dont il se manifeste et par les raisons pour lesquelles il est difficile à éliminer complètement.

Les IDOR persistent non pas parce que les équipes les ignorent, mais parce qu'elles résultent de l'évolution des systèmes réels. Elles apparaissent souvent à la périphérie des flux de travail, lors de refactorisations ou lorsque les hypothèses de propriété sont réutilisées dans des étapes qui n'étaient pas initialement conçues pour être connectées. Cet article explique à quoi ressemblent les IDOR dans la pratique, pourquoi les approches courantes de test de sécurité ont du mal à les détecter de manière fiable et comment les techniques de test modernes permettent de valider les défaillances de propriété dans les systèmes en fonctionnement.

Qu'est-ce qu'une référence d'objet direct non sécurisée dans la pratique ?

Une vulnérabilité IDOR se produit lorsqu'une application accepte un identifiant qui fait 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 généralement sous la forme suivante :

• Identifiants utilisateur dans les chemins d'accès URL
• ID de commande ou de facture dans les paramètres de requête
• Identificateurs de ressources dans les corps de requête

La vulnérabilité ne réside pas dans l'identifiant lui-même. Elle réside dans l'hypothèse selon laquelle l'identifiant appartient à l'utilisateur authentifié, sans que cette hypothèse soit revalidée sur le serveur.

Dans les applications modernes, cette hypothèse est souvent valable dans la plupart des cas, mais pas dans tous. C'est cette incohérence qui explique l'existence des IDOR.

Pourquoi les vulnérabilités IDOR sont particulièrement dangereuses dans les API

Dans sécurité des API , les IDOR sont souvent appelés « Broken Object Level Authorization » (BOLA), le risque numéro un dans sécurité des API 10 de l'OWASP sécurité des API . L'OWASP a adopté le terme BOLA afin de 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 pirates peuvent souvent l'exploiter à grande échelle.

Les impacts courants comprennent :

• Accès aux données sensibles appartenant à d'autres utilisateurs
  
• Modification ou suppression de ressources appartenant à d'autres personnes
  
• Contournement des règles métier liées à la propriété ou au rôle
  
• Nuire aux processus opérationnels tels que les approbations, la facturation ou la gestion des comptes
  

Les API étant conçues pour l'automatisation, une seule vérification d'appropriation manquante peut compromettre une grande partie d'un système.

Types courants de vulnérabilités IDOR

IDOR est un terme générique. Dans la pratique, les équipes rencontrent plusieurs schémas récurrents :

• IDOR horizontal : un utilisateur accède aux objets d'un autre utilisateur avec le même niveau de privilège.
  
• Identifiant vertical : les identifiants permettent d'accéder à des objets privilégiés ou administratifs.
  
• Blind IDOR : la réponse n'expose pas les données, mais l'action réussit sur l'objet d'une autre personne.
  

Les IDOR aveugles sont particulièrement faciles à manquer avec les outils qui se concentrent sur l'exposition évidente des données. Ils nécessitent souvent une validation explicite pour confirmer leur impact.

Comment les vulnérabilités IDOR sont traditionnellement testées dans la pratique

Lors d'un test d'intrusion, les tests IDOR sont généralement effectués par le biais d'une relecture et d'une comparaison minutieuses des requêtes.

Dans la pratique, cela implique :

• Authentification en tant qu'utilisateur légitime
  
• Exécution des workflows via l'interface utilisateur
  
• Capture des 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 que les données de l'utilisateur A renvoie les mêmes données lorsqu'elle est rejouée en tant qu'utilisateur B, cela indique contrôle d’accès défaillant.

Cette approche est efficace et largement utilisée. Elle repose sur la compréhension par le testeur de l'intention de l'application et sur sa capacité à déterminer quelles requêtes sont sensibles en matière de sécurité.

Cependant, ce processus est intrinsèquement manuel et chronophage. Chaque workflow, rôle ou transition d'état supplémentaire multiplie le nombre de requêtes qui doivent être capturées, rejouées et interprétées. À mesure que les applications gagnent en complexité, il devient impossible d'appliquer cette comparaison de manière exhaustive à tous les chemins possibles.

C'est pourquoi les tests manuels permettent souvent de détecter les IDOR dans les domaines qui font l'objet d'une attention particulière, mais ne peuvent garantir une couverture complète.

Pourquoi DAST ne détectent pas les vulnérabilités IDOR réelles

Tests de sécurité des applications dynamiques fonctionnent au niveau des requêtes. Ils explorent les points de terminaison, testent 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 tient pas compte de la propriété, du contexte du flux de travail ou de l'adéquation d'une réponse à 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 si des données sensibles sont exposées à un utilisateur non autorisé.

Cela rend DAST pour les problèmes de surface, mais fondamentalement limité lorsqu'il s'agit d'IDOR et d'autres échecs d'autorisation qui dépendent de la propriété des objets et du contexte. Cette limitation n'est pas spécifique à un outil en particulier. Elle reflète le fait que l'analyse au niveau des requêtes, même lorsqu'elle est bien mise en œuvre, ne dispose pas d'un contexte suffisant pour raisonner sur la propriété des objets et l'intention du flux de travail.

Pourquoi l'analyse statique crée du bruit autour des IDOR

De nombreuses équipes s'appuient sur des outils d'analyse statique pour signaler les problèmes potentiels liés à l'IDOR. Ces outils recherchent généralement des modèles dans lesquels des identifiants sont transmis à des gestionnaires ou à des contrôleurs sans vérification d'autorisation évidente à proximité.

Cela produit souvent un grand nombre de résultats.

Dans la pratique, la plupart d'entre eux sont des faux positifs. Les contrôles d'autorisation existent souvent ailleurs dans la chaîne d'appels, dans des intergiciels partagés ou au niveau du framework. L'analyse statique ne permet pas de déterminer de manière fiable si un identifiant est exploitable lors de l'exécution.

Ce problème est amplifié lorsque l'autorisation est mise en œuvre implicitement ou répartie entre plusieurs couches, notamment :

• Contrôle d'accès appliqué par des intergiciels ou des décorateurs
  
• Contrôles mis en œuvre dans les services partagés ou les méthodes modèles
  
• Logique d'autorisation 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 passent à côté du contexte d'autorisation complet. Il en résulte un volume élevé de résultats plausibles, mais peu fiables.

Il s'agit là d'une limitation fondamentale de l'analyse statique. Sans contexte d'exécution et 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 dans la pratique.

Même les outils d'analyse statique assistés par l'IA restent prédictifs. Ils analysent la structure du code, mais ne peuvent pas confirmer le comportement d'exécution. Par conséquent, les résultats de type IDOR présentent souvent des taux de faux positifs supérieurs à 50 %, ce qui oblige les équipes à trier les problèmes théoriques, tandis que les véritables défaillances de propriété risquent d'être ignorées.

Le problème fondamental : la propriété dépend du contexte

Les IDOR ne sont pas simplement des contrôles manquants. Il s'agit d'échecs d'autorisation contextuelle liés à la propriété des objets.

La propriété est établie par une combinaison des éléments suivants :

• État d'authentification
  
• Modèles de rôles et d'autorisations
  
• Progression du flux de travail
  
• État côté serveur créé précédemment dans un processus
  

Si une partie de ce contexte est supposée plutôt que revalidée, un IDOR peut apparaître.

Certains IDOR sont de second ordre. Un identifiant est accepté en une seule étape, stocké, puis utilisé ultérieurement, 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 répartie dans le temps et en plusieurs étapes.

Pour tester de manière fiable les IDOR, il faut 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

Il est courant de croire à tort que le passage 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 les accès non autorisés si les contrôles de propriété font défaut.

Dans les systèmes réels, les attaquants obtiennent des identifiants par le biais du comportement normal des applications, notamment :

• Références renvoyées par d'autres points de terminaison
  
• Liens et URL partagés
  
• Messages et notifications dans l'application
  
• Journaux, exportations et historique du navigateur
  

Si un attaquant peut obtenir un identifiant valide et que le backend n'applique pas la propriété, une IDOR existe toujours.

Comment pentest IA les vulnérabilités IDOR que d'autres ne voient pas

pentest IA adopte une approche différente pour identifier les défaillances d'autorisation.

Plutôt que de se limiter à la détection, il teste activement les hypothèses relatives à la propriété et au contrôle d'accès dans une application en cours d'exécution.

Dans le domaine de Aikido, cette approche est mise en œuvre grâce à Aikido , un test de pénétration autonome qui allie la créativité humaine à la vitesse des machines. Il est conçu pour évaluer les défaillances en matière d'autorisation et de propriété dans des environnements réels. Aikido fonctionne à l'aide d'identités réelles, exécute des workflows de bout en bout et valide l'exploitabilité avant de rendre compte de ses conclusions.

Pour les IDOR, ce processus implique :

• Authentification en tant qu'utilisateurs réels
  
• Exercice complet des flux de travail de bout en bout
  
• Réutilisation des identifiants d'objets entre 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 pouvant être exploités dans la pratique sont signalés. Les autres sont automatiquement ignorés.

Cela réduit les faux positifs et garantit que les résultats signalés correspondent à de véritables échecs d'autorisation. Dans les situations où l'intention n'est pas claire, un testeur humain devrait généralement consulter le propriétaire de l'application. La validation à l'exécution résout ce problème directement.

Test ciblé des hypothèses relatives à la propriété

pentest IA des efforts spécifiques à l'évaluation des hypothèses de propriété liées aux identifiants d'objets dans une application.

Plutôt que de traiter les IDOR comme un effet secondaire des tests génériques, il se concentre explicitement sur :

• Identifiants liés aux ressources appartenant à l'utilisateur
  
• Transitions de workflow qui réutilisent des références d'objets
  
• Points de terminaison backend qui reposent sur des hypothèses de propriété frontend
  

Cela garantit une couverture cohérente des parties d'un système où les IDOR se produisent réellement.

Exemple : IDOR dans un workflow d'approbation en plusieurs étapes

Cet exemple illustre comment un IDOR peut apparaître à plusieurs étapes du flux de travail, même lorsque les points de terminaison individuels semblent appliquer correctement le contrôle d'accès.

Contexte d'application

L'application comprend un processus d'approbation en plusieurs étapes pour les actions sensibles. Un utilisateur crée une demande qui doit ensuite être examinée et approuvée. Chaque demande est liée à l'utilisateur qui l'a créée et est référencée par un identifiant utilisé dans plusieurs appels API.

Seul le propriétaire d'une demande est autorisé à la consulter ou à la modifier avant son approbation.

Ce que le système a observé

pentest IA en tant qu'utilisateur standard et a testé le flux de création de demande. Au cours de ce processus, le système a stocké l'état intermédiaire du flux de travail sur le serveur et l'a réutilisé lors des étapes suivantes.

Les vérifications initiales de propriété ont été correctement effectuées lors de la création de la demande.

Test de propriété tout au long du flux de travail

Des tests supplémentaires ont évalué la manière dont l'identifiant de requête était utilisé dans les étapes ultérieures. Ils ont permis d'observer que :

• L'identifiant a été réutilisé lors de la reprise d'une demande en attente.
  
• Les appels API ultérieurs ont pris en charge la propriété sur la base de la validation antérieure.
  
• La propriété n'a pas été revalidée lorsque le flux de travail a repris.
  

En rejouant l'action de reprise avec un autre utilisateur authentifié et en remplaçant l'identifiant de la requête, le système a pu accéder à une requête qui ne lui appartenait pas et agir en conséquence.

Pourquoi il s'agissait d'une vulnérabilité IDOR

Le problème ne provenait pas d'un seul chèque manquant.

Cela résultait d'une hypothèse selon laquelle la propriété avait déjà été validée plus tôt dans le flux de travail et n'avait pas besoin d'être revérifiée lorsque la demande était reprise. Cette hypothèse s'est avérée erronée lorsque les identifiants d'objet ont été réutilisés par plusieurs utilisateurs.

Validation et reproductibilité

Avant de signaler le problème, le système :

• J'ai rejoué la séquence complète plusieurs fois.
  
• Comportement cohérent confirmé
  
• Preuves capturées d'accès non autorisé
  

Ce n'est qu'après avoir confirmé la reproductibilité et l'impact que le problème a été signalé.

Pourquoi cela serait négligé par d'autres approches

Chaque point de terminaison individuel fonctionnait correctement lorsqu'il était isolé. La vulnérabilité n'apparaissait que lorsque :

• Un flux de travail a été partiellement achevé.
  
• L'état côté serveur a été réutilisé.
  
• Une étape ultérieure a été invoquée en dehors du contexte utilisateur d'origine.
  

Cela rendait le problème difficile à détecter par des tests manuels et invisible pour les outils d'analyse basés sur les requêtes.

Pourquoi les tests continus sont importants pour les vulnérabilités IDOR

Les IDOR sont souvent introduits par le changement.

Ils apparaissent généralement lorsque :

• Les nouvelles fonctionnalités réutilisent les modèles de données existants.
  
• La logique d'autorisation est ajoutée à un endroit, mais pas à un autre.
  
• Les refactorisations contournent involontairement les contrôles de propriété antérieurs.
  

Un test ponctuel peut confirmer que la propriété est respectée aujourd'hui, mais cette assurance s'affaiblit à 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 les logiciels évoluent. pentest continu prennent en charge cette fonctionnalité en testant en permanence les workflows nouveaux et modifiés afin de détecter tout accès non autorisé aux objets.

Les vulnérabilités IDOR comme symptôme de la complexité du système

Les IDOR ne sont pas des cas marginaux. Ils sont le résultat naturel de l'évolution au fil du temps de systèmes complexes.

À mesure que les applications se développent, la logique de propriété s'étend aux services, aux flux de travail et aux couches. Les hypothèses s'accumulent et il devient de plus en plus difficile de raisonner sur l'accès au niveau des objets.

pentest IA supprime pentest IA cette complexité, mais il la rend testable.

En exerçant systématiquement les flux de travail, en suivant l'état et en validant la propriété dans son contexte, cela transforme l'une des classes de vulnérabilité les plus persistantes en quelque chose qui peut être détecté plus tôt, de manière plus cohérente et avec une plus grande confiance.

Les équipes de sécurité accordent de plus en plus d'importance aux IDOR et autres défaillances d'autorisation, car elles sont spécifiques au système, sujettes à la régression et difficiles à valider sans tests d'exécution tenant compte du flux de travail.


Vous aimerez peut-être aussi :

• Les meilleurs outils de test d'intrusion basés sur l'IA
• DAST test d'intrusion basé sur l'IA vs test d'intrusion manuel
• Qu'est-ce que le pentesting IA ?

Faites réaliser un test d'intrusion dès aujourd'hui avec Aikido .