Insecure Direct Object References : une menace majeure pour les applications web
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 :
- API1 – Broken Object Level Authorization
- API3 – Broken Object Property Level Authorization
- API5 – Broken Function Level Authorization
Définition
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 :
- L’accès en lecture à des ressources ;
- La création, l’édition ou la suppression des ressources ;
- L’accès en lecture à des documents ;
- L’accès à des fonctionnalités.
Accès en lecture aux ressources
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
Création, édition et suppression des ressources
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
Accès en lecture à des documents
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 :
- Accès aux documents à l’aide d’un identifiant
Figure 6 – Exemple 1 : Requête vulnérable à l’IDOR
- Accès aux documents à l’aide du nom du fichier
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
Accès à des fonctionnalités
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
Cas spécifiques
Les IDOR, lorsqu’elles sont appliquées à certaines caractéristiques des comptes utilisateurs, peuvent être très critiques pour une application.
Modification du rôle de l’utilisateur
Lorsqu’une IDOR affecte la fonctionnalité de changement de rôle d’un utilisateur, il peut être possible de :
- Modifier le rôle d’un autre utilisateur
- Modifier son propre rôle avec un rôle plus élevé
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.
Modification du mot de passe
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.
Remédiation : protégez une application contre les vulnérabilités de type IDOR
Pour protéger une application contre les vulnérabilités de type IDOR, voici quelques recommandations à suivre :
- Vérifiez systématiquement les droits d’accès aux ressources, en tenant compte à la fois de la notion de propriété individuelle et de ressources partagées.
- Assurez-vous que les droits d’accès aux fonctionnalités sont correctement gérés en fonction des rôles des utilisateurs.
- Évitez les références directes dans les paramètres, en limitant notamment les entrées utilisateur.
- Utilisez des UUID (Universally Unique Identifiers) pour masquer les identifiants sensibles, bien que cela ne garantisse pas l’absence d’IDOR, cela complique l’exploitation.
- Validez toujours les entrées provenant des utilisateurs pour prévenir toute manipulation.
Conclusion
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.
- Références
https://www.akto.io/blog/comprehensive-guide-on-idor
https://latesthackingnews.com/2023/06/26/serious-idor-vulnerability-found-in-microsoft-teams