Série Partage & Apprentissage : Les références directes à des objets non sécurisées

Les URL sont essentielles pour naviguer sur tous les sites web et applications que nous connaissons et apprécions. Leur fonction première est d'identifier l'emplacement des ressources et la manière de les récupérer. Bien que les URL soient nécessaires au fonctionnement du World Wide Web, elles peuvent également présenter un risque de sécurité si elles ne sont pas correctement protégées.

Dans cet article, nous aborderons les points suivants :

• Qu'est-ce que l'IDOR et comment les attaquants l'exploitent
• Pourquoi l'IDOR est dangereux
• Techniques pour corriger cette vulnérabilité

Comprendre l'IDOR

Une référence directe à un objet se produit lorsqu'un enregistrement spécifique (l'« objet ») est référencé au sein d'une application. Elle prend généralement la forme d'un identifiant unique et peut apparaître dans une URL.

Par exemple, vous pourriez remarquer une chaîne telle que « ?id=12345 » à la fin d'une URL. Le nombre 12345 est une référence à un enregistrement spécifique. Les failles de sécurité surviennent lorsque le contrôle d'accès fait défaut pour les enregistrements individuels. Cela permet aux utilisateurs d'accéder à des données qu'ils ne devraient pas voir. Il s'agit d'une attaque qui nécessite un niveau de compétence relativement faible.

Dans ce cas, imaginons qu'un attaquant modifie l'identifiant dans l'URL par 12344. Dans une application vulnérable à l'IDOR, l'attaquant serait en mesure de consulter les données relatives à cet enregistrement.

Quels dommages ce type de vulnérabilité peut-il réellement causer ?

Comprendre pourquoi l'IDOR est dangereux

Lorsque les développeurs manquent de vigilance, ils peuvent concevoir un système qui affiche et expose des enregistrements de l'application à divers endroits. Une violation de cette ampleur peut être significative, surtout lorsque des données sensibles ou des informations personnelles identifiables (PII) sont impliquées.

L'administration fiscale australienne a mis en place un site web pour aider les entreprises à collecter un nouvel impôt. Malheureusement, celui-ci comportait une fonctionnalité indésirable : une vulnérabilité IDOR. Un utilisateur curieux a remarqué que les URL du site contenaient son numéro d'entreprise australien (ABN). Il se trouve que ce numéro est facilement accessible pour toute entreprise enregistrée. Cet utilisateur a décidé de saisir les numéros d'autres sociétés dans l'URL. Il a ainsi pu accéder à leurs coordonnées bancaires et à leurs informations personnelles !

Apple a récemment été victime d'une vulnérabilité IDOR. Lors du lancement de l'iPad, 114 000 adresses e-mail de clients ont été divulguées. (Pour être honnête, il s'agissait davantage d'une erreur de la part d'AT&T).

En effet, AT&T avait développé un service pour prendre en charge la connectivité 3G des iPad. L'iPad envoyait un identifiant stocké sur la carte SIM au service d'AT&T, qui renvoyait ensuite l'adresse e-mail de l'utilisateur.

Malheureusement, ces identifiants étaient simplement des entiers séquentiels et étaient donc facilement devinables. Les attaquants ont parcouru les identifiants et ont dérobé les adresses e-mail.

Une autre erreur a été que le service d'AT&T a tenté de se « sécuriser » en ne renvoyant l'adresse e-mail que si l'en-tête user-agent de la requête indiquait qu'elle provenait d'un iPad. Le user-agent n'est qu'une chaîne de caractères qui peut être facilement manipulée.

Les vulnérabilités IDOR peuvent être subtiles et insidieuses. Voyons comment les contrer.

Vaincre les IDOR

Le contrôle d'accès est la clé pour résoudre les IDOR. Lorsqu'un utilisateur demande un enregistrement spécifique, assurez-vous qu'il est autorisé à le consulter.

L'utilisation de modules d'autorisation centralisés est la meilleure approche. Des outils comme Spring Security offrent une authentification et une autorisation robustes et personnalisables pour les applications.

En résumé : utilisez un module unique sur lequel tout le reste du code s'appuie pour effectuer les vérifications d'autorisation.

Une autre mesure d'atténuation courante consiste à utiliser des références de substitution. Au lieu d'utiliser les identifiants réels de vos enregistrements de base de données dans vos URL, vous pouvez créer des nombres aléatoires qui renvoient aux enregistrements réels.

L'utilisation de références de substitution garantit qu'un attaquant ne peut pas accéder à un enregistrement simplement en devinant l'identifiant valide suivant.

Enfin, ne vous fiez jamais à des éléments manipulables par l'utilisateur pour gérer l'autorisation. AT&T a tenté d'utiliser l'en-tête user-agent pour autoriser son service. Ne vous reposez pas sur les en-têtes HTTP, les cookies ou les paramètres GET et POST.

Avec ces mesures en place, les IDOR appartiendront au passé.

Sécurisez vos références

Les références directes à des objets non sécurisées sont parmi les vulnérabilités les plus faciles à exploiter. Ne vous laissez pas surprendre. Vérifiez toujours que les utilisateurs sont autorisés. N'utilisez pas d'identifiants de base de données réels. Ne dépendez pas de données contrôlées par l'utilisateur pour l'autorisation.

Développez votre expertise en consultant nos ressources d'apprentissage. En vous exerçant à atténuer les vulnérabilités IDOR dans le langage de votre choix, vous n'aurez aucun mal à identifier et corriger ce problème dans vos bases de code en production. Vous pouvez également mettre vos nouvelles connaissances défensives à l'épreuve avec une démo gratuite de la plateforme Secure Code Warrior, qui forme les équipes de cybersécurité à devenir des experts en défense. Pour en savoir plus sur la lutte contre cette vulnérabilité et bien d'autres menaces, visitez le blog de Secure Code Warrior.

Prêt à vous défendre contre les attaques IDOR dès maintenant ? Rendez-vous sur la plateforme pour relever le défi gratuitement : [Commencer ici]