Les Insecure Direct Object References (IDOR) ou références objet directe non protégée font partie des vulnérabilités les plus courantes et dangereuses dans les applications web. Dans cet article, nous allons explorer ce qu’est l’IDOR, comment elle fonctionne, pourquoi elle est dangereuse et, surtout, comment la prévenir.
Une IDOR est un type de vulnérabilité sous-estimé ou méconnu par les développeurs mais bien connu des pirates informatiques et des chercheurs en sécurité. En effet, les IDOR ont souvent été et sont toujours à l’origine de fuites de données (voir les exemples : Uber 2016, Microsoft Teams 2023). De plus, elles sont apparues dans le Top 10 OWASP pour la première fois en 2007 (« A4 – IDOR »). Depuis les IDOR ont été fusionnées avec la catégorie « A7 – Missing function level access control (2013) » puis dans la catégorie « A5 – Broken Access Control » en 2017.
En 2021, cette catégorie a été placée en première position du Top 10 OWASP, confirmant ainsi son importance, sa criticité et son risque d’apparition élevé. Enfin, en 2023 dans le Top 10 OWASP spécifique aux API, cette catégorie a été séparée en trois catégories :
On parle de référence directe à un objet lorsqu’il est possible de cibler une ressource à l’aide d’un identifiant ou d’un nom par exemple. Lorsqu’il est possible d’itérer sur les identifiants ou les noms pour cibler toutes les ressources concernées, et que les vérifications d’autorisation d’accès aux ressources sont mal implémentées voire non implémentées, on parle alors de référence objet directe non protégée.
En d’autres termes, si une application ne vérifie pas que l’utilisateur a bien l’autorisation d’accéder à une ressource spécifique, un attaquant peut modifier ces références pour accéder à des ressources qui ne lui appartiennent pas.
Il existe plusieurs types d’IDOR, souvent séparés en quatre catégories permettant :
Prenons l’extrait de code vulnérable ci-dessous (Figure 2). Il semble nécessaire d’être authentifié pour pouvoir utiliser la route d’API « /api/user/{user_id}/account ». Cependant, aucune restriction ne semble avoir été mise en place pour limiter l’accès aux informations des autres comptes.
Figure 2 – Extrait de code vulnérable
Il est donc possible d’itérer sur la valeur du paramètre « user_id » pour récupérer les informations de chaque utilisateur.
Figure 3 – Requête vulnérable à l’IDOR
Prenons l’extrait de code vulnérable ci-dessous (Figure 4). Il semble là encore nécessaire d’être authentifié pour pouvoir utiliser la route d’API « /api/orders/comment ». Cependant, aucune restriction ne semble avoir été mise en place pour limiter l’ajout de commentaires sur les commandes des autres utilisateurs.
Figure 4 – Extrait de code vulnérable
Il est donc possible d’itérer sur la valeur du paramètre « order_id » pour ajouter des commentaires sur chaque commande.
Figure 5 – Requête vulnérable à l’IDOR
Il s’agit ici d’un cas particulier de la première catégorie appliquée aux documents. Il existe plusieurs formes de requêtes vulnérables dans ce cas :
Figure 6 – Exemple 1 : Requête vulnérable à l’IDOR
Figure 7 – Exemple 2 : Requête vulnérable à l’IDOR
Les vulnérabilités de type LFI (Local File Inclusion) sont un cas particulier de ce type d’IDOR.
Figure 8 – Exemple 3 : Cas particulier d’une requête vulnérable à une LFI
Prenons l’extrait de code vulnérable ci-dessous (Figure 9). Il semble là encore nécessaire d’être authentifié pour pouvoir utiliser la route d’API « /api/employees/?role=rh ». Cependant, aucune restriction ne semble avoir été mise en place pour limiter l’accès aux fonctionnalités réservées à certains rôles sur la liste des employés.
Figure 9 – Extrait de code vulnérable
Il est donc possible d’itérer sur la valeur du paramètre « role » pour accéder aux différentes vues et fonctionnalités possibles. Par exemple, sur la Figure 10, on obtient la vue et les fonctionnalités réservées à un administrateur sur la liste des employés.
Figure 10 – Requête vulnérable à l’IDOR
Les IDOR, lorsqu’elles sont appliquées à certaines caractéristiques des comptes utilisateurs, peuvent être très critiques pour une application.
Lorsqu’une IDOR affecte la fonctionnalité de changement de rôle d’un utilisateur, il peut être possible de :
Figure 11 – Requête vulnérable à l’IDOR
Cela peut permettre de réduire ou d’élever les droits d’un autre utilisateur, ou bien d’élever ses propres droits sur l’application.
Lorsqu’une IDOR affecte la fonctionnalité de changement de mot de passe d’un utilisateur, il peut être possible de modifier le mot de passe d’un autre utilisateur.
Cela peut permettre la compromission des comptes des autres utilisateur et une éventuelle élévation de privilèges sur l’application.
Pour protéger une application contre les vulnérabilités de type IDOR, voici quelques recommandations à suivre :
Les Insecure Direct Object References (IDOR) représentent une menace sérieuse pour la sécurité des applications web, principalement à cause de leur simplicité d’exploitation et de leur capacité à exposer des données sensibles. Cependant, en appliquant des contrôles d’accès stricts, en utilisant des références indirectes et en validant correctement les autorisations côté serveur, les développeurs peuvent prévenir efficacement ces vulnérabilités.
https://www.akto.io/blog/comprehensive-guide-on-idor
https://latesthackingnews.com/2023/06/26/serious-idor-vulnerability-found-in-microsoft-teams
https://owasp.org/API-Security/editions/2023/en/0x11-t10