Références d’objet directes non sécurisées (IDOR)

Que sont les références d’objet directes non sécurisées ?

Les références d’objet direct non sécurisées (IDOR) sont des vulnérabilités qui se produisent lorsqu’un développeur d’applications Web utilise uniquement des identifiants pour pointer directement vers des éléments de page qui doivent être soumis à un contrôle d’accès ou nécessitent une autorisation.

Par exemple, une vulnérabilité IDOR se produit si l’URL d’une transaction contient l’ID de transaction, et simplement en fournissant un ID de transaction différent, vous pouvez accéder aux informations sur une transaction qui appartient à un autre utilisateur.

Gravité:		sévérité moyenne
Prévalence:		découvert rarement
Portée:		peut apparaître dans toutes les applications Web
Impact technique :		accès aux informations sensibles
Conséquences dans le pire des cas :		violation d’informations sensibles
Solution rapide:		mettre en œuvre des contrôles d’accès stricts

Que signifie une référence d’objet directe non sécurisée ?

Le terme référence d’objet direct non sécurisée signifie qu’une application Web fait directement référence à un certain objet interne, tel qu’un numéro de transaction ou un identifiant d’utilisateur, mais que cette référence est publiquement visible, ouverte à un accès direct et non sécurisée à l’aide d’une quelconque forme de validation, autorisation ou contrôle d’accès. Le terme a été introduit par l’Open Web Application Security Project (OWASP) dans le Top 10 OWASP pour 2007 en tant que catégorie distincte A4 Insecure Direct Object Reference . En 2017, il a été fusionné avec A5 Broken Access Control avec d’autres problèmes de contrôle d’accès, puis reporté sur la liste 2021 sous A1 Broken Access Control.

Comment les vulnérabilités IDOR se produisent-elles ?

La plupart des applications Web utilisent des identifiants uniques simples pour référencer des objets côté serveur. Par exemple, un utilisateur dans une base de données sera généralement référencé via un ID utilisateur unique. Le même ID utilisateur est la clé primaire de la colonne de base de données contenant les informations utilisateur et il est généré automatiquement. L’algorithme de génération de clé de base de données est basé sur une simple incrémentation – il utilise généralement le prochain entier disponible. Les mêmes mécanismes de génération d’ID de base de données sont utilisés pour tous les autres types d’enregistrements de base de données.

Ces identifiants sont souvent utilisés côté client par les applications Web et les API. Lorsqu’ils sont envoyés dans des URL via des requêtes HTTP régulières à l’aide de la méthode GET, les ID sont clairement visibles à la fois dans le navigateur Web et dans les en-têtes de requête, ce qui les rend facilement accessibles aux attaquants. Faire référence directement aux ID internes de cette manière n’est pas recommandé pour des raisons de sécurité, car cela pourrait permettre aux attaquants d’effectuer une énumération approfondie (par exemple, trouver tous les ID utilisateur). S’il n’y a pas d’autre moyen de faire référence à un objet interne, le développeur doit au moins assurer le contrôle d’accès afin que l’accès aux ressources nécessite plus qu’une simple référence et une authentification de page générique.

Par exemple, supposons qu’une application Web affiche les détails de la transaction à l’aide de l’URL suivante :

https://www.example.com/transaction.php?id=74656

Un pirate malveillant pourrait essayer de falsifier la valeur du paramètre id et de substituer d’autres valeurs similaires à 74656, par exemple :

https://www.example.com/transaction.php?id=74657

Selon l’application, la transaction 74657 pourrait être une transaction valide associée à un autre compte utilisateur, et le pirate malveillant ne devrait pas être autorisé à la voir. Cependant, si le développeur n’a pas implémenté les contrôles d’autorisation avant d’accorder l’accès à la transaction, l’attaquant peut être en mesure de le voir. Dans ce cas, nous aurions une vulnérabilité de référence d’objet direct non sécurisée.

Exemples de vulnérabilités IDOR courantes

Les vulnérabilités IDOR apparaissent souvent dans les formulaires de changement de mot de passe. Une URL de formulaire de changement de mot de passe mal conçue peut être :

https://www.example.com/change_password.php?userid=1701

Vous pouvez obtenir cette URL dans un e-mail de confirmation après avoir d’abord fourni une adresse e-mail à l’aide d’un formulaire différent. S’il n’y a pas de vérifications supplémentaires, un pirate malveillant pourrait essayer l’URL ci-dessus avec userid=1, accédant ainsi potentiellement au compte administrateur (l’ID de l’administrateur est souvent 1).

Les vulnérabilités IDOR peuvent également impliquer des noms de fichiers, et non des ID d’objets. Par exemple, la traversée de répertoire (traversée de chemin) est souvent considérée comme un type de vulnérabilité IDOR. Dans ce cas particulier d’IDOR, l’utilisateur peut afficher des fichiers sans autorisation. Par exemple:

https://www.example.com/display_file.php?file.txt

S’il existe une vulnérabilité IDOR associée au fichier display_file. php , un pirate malveillant pourrait accéder aux ressources sensibles du système de fichiers telles que le fichier /etc/passwd en manipulant l’entrée de l’utilisateur (dans ce cas, en changeant simplement l’URL) pour accéder à cette ressource au lieu de file.txt :

https://www.example.com/display_file.php?../../../etc/passwd

Comment détecter les vulnérabilités IDOR ?

Les références d’objet directes non sécurisées sont un type de vulnérabilité de contrôle d’accès qui ne peut pas être directement détectée à l’aide d’outils de test de sécurité automatisés (sauf dans le cas particulier des vulnérabilités de traversée de chemin). Étant donné que vous ne pouvez pas utiliser l’analyse des vulnérabilités pour les trouver, l’identification des IDOR nécessite des tests de pénétration manuels et des révisions de code axées sur la sécurité.

Comment prévenir les attaques IDOR ?

La seule façon de se protéger contre les IDOR est de mettre en place des contrôles d’accès stricts pour tous les objets sensibles. Heureusement, les frameworks de développement back-end modernes tels que Ruby on Rails ou Django n’ont pas de problèmes avec IDOR (à moins que le développeur du logiciel ne décide d’utiliser ses propres mécanismes d’accès plutôt que ceux intégrés). Avec de tels frameworks, le contrôle d’accès est implémenté de manière sécurisée dès la conception, il est donc recommandé d’utiliser des frameworks réputés pour développer vos applications Web et de suivre leurs méthodes documentées de contrôle d’accès aux objets. Si cela n’est pas possible, vous devez utiliser des hachages cryptographiques sécurisés de vos identifiants au lieu d’utiliser directement les identifiants.

Vous pouvez voir certaines sources dire que pour éviter les vulnérabilités IDOR, vous devez utiliser des identifiants d’objet longs et difficiles à deviner, tels que ceux utilisés pour la gestion de session ou les UUID. Une solution connexe consiste à utiliser des cartes de référence d’objet indirect avec des ID externes difficiles à deviner. Cependant, nous vous déconseillons fortement d’utiliser de telles approches car elles vous donnent un faux sentiment de sécurité tout en rendant les attaques plus difficiles mais pas impossibles.