Introduction
Les références directes à des objets non sécurisées (Insecure Direct Object References, IDOR) constituent un type de vulnérabilité de contrôle d'accès qui survient lorsqu'une application utilise des entrées fournies par l'utilisateur pour accéder directement à des objets. Si l'application ne vérifie pas adéquatement si l'utilisateur demandant l'objet est autorisé à y accéder, un attaquant peut manipuler la référence (telle qu'un identifiant de base de données, un nom de fichier ou un identifiant utilisateur dans une URL) pour accéder aux données sensibles d'autres utilisateurs.
La distinction importante est que la référence elle-même n'est pas la vulnérabilité. La vulnérabilité réside dans le fait de faire confiance à cette référence sans vérifier si l'utilisateur actuel est autorisé à l'utiliser.
Dans ce laboratoire, vous agirez en tant que testeur de sécurité évaluant l'API d'une application web locale. Vous commencerez par vous authentifier en tant qu'utilisateur standard, vous analyserez la manière dont l'application référence votre profil utilisateur, puis vous exploiterez une vulnérabilité IDOR pour accéder aux données privées d'autres utilisateurs, y compris celles d'un administrateur.
S'authentifier en tant qu'utilisateur standard
Dans cette étape, vous allez interagir avec une API web locale s'exécutant sur votre machine sur le port 5000. Pour commencer à tester l'application à la recherche de vulnérabilités, vous devez d'abord vous authentifier en tant qu'utilisateur standard afin d'obtenir un jeton de session valide.
Nous disposons des identifiants d'un utilisateur standard nommé Alice. Son nom d'utilisateur est alice et son mot de passe est password123.
Vous utiliserez l'outil en ligne de commande curl pour envoyer une requête HTTP POST au point de terminaison de connexion. curl est un outil puissant utilisé pour transférer des données vers ou depuis un serveur.
Exécutez la commande suivante dans votre terminal pour vous connecter :
curl -X POST http://localhost:5000/api/login \
-H "Content-Type: application/json" \
-d '{"username": "alice", "password": "password123"}'
Analysons cette commande :
-X POSTspécifie que nous envoyons une requête POST, généralement utilisée pour soumettre des données telles que des identifiants de connexion.-H "Content-Type: application/json"indique au serveur que les données que nous envoyons sont formatées en JSON.-d '...'contient la charge utile (payload) des données JSON avec le nom d'utilisateur et le mot de passe.
Si les identifiants sont corrects, vous devriez voir un résultat similaire à celui-ci :
{"token": "Bearer alice_token", "user_id": "1001"}
Notez le token et le user_id. Le jeton (Bearer alice_token) agit comme votre carte d'identité numérique. Vous devrez l'inclure dans vos futures requêtes pour prouver que vous êtes authentifié. Le user_id (1001) est votre identifiant unique dans la base de données de l'application.
Analyser les références d'objets (URL/API)
Maintenant que vous êtes authentifié en tant qu'Alice, vous pouvez accéder à son profil utilisateur. Dans de nombreuses applications web, les profils utilisateur sont accessibles via un point de terminaison d'API qui nécessite votre jeton d'authentification et une référence à l'objet spécifique (dans ce cas, le profil utilisateur) que vous souhaitez consulter.
Vous utiliserez à nouveau curl, mais cette fois-ci, vous enverrez une requête GET au point de terminaison /api/profile. Vous devez inclure le jeton d'authentification dans les en-têtes HTTP et spécifier votre user_id dans l'URL.
C'est exactement le type de modèle que l'on retrouve dans les API réelles : un jeton prouve que la session existe, tandis qu'un paramètre sélectionne l'objet à récupérer. Les applications sécurisées doivent lier ces deux concepts par des contrôles d'autorisation.
Exécutez la commande suivante pour afficher le profil d'Alice :
curl -H "Authorization: Bearer alice_token" \
"http://localhost:5000/api/profile?user_id=1001"
Dans cette commande :
-H "Authorization: Bearer alice_token"transmet votre carte d'identité numérique au serveur.?user_id=1001est un paramètre de requête ajouté à l'URL. Il s'agit de la référence directe à l'objet. Il indique au serveur exactement quel enregistrement de base de données récupérer.
Vous devriez recevoir une réponse JSON contenant les informations du profil d'Alice :
{"name": "Alice", "role": "user", "email": "alice@example.com", "secret": "alice_secret_123"}
Remarquez comment l'application s'appuie sur le paramètre user_id=1001 dans l'URL pour décider quelles données retourner. Une application sécurisée vérifierait que l'utilisateur associé au Bearer alice_token est réellement autorisé à consulter les données pour user_id=1001. Si l'application omet d'effectuer ce contrôle d'autorisation, elle est vulnérable à une attaque IDOR.
Manipuler les identifiants utilisateur
Dans cette étape, vous allez tester si l'application applique correctement les contrôles d'accès. Vous êtes actuellement authentifié en tant qu'Alice, mais que se passe-t-il si vous demandez au serveur les données d'un autre utilisateur ?
C'est la question fondamentale de l'autorisation. « Suis-je connecté ? » et « Suis-je autorisé à lire cet objet ? » sont des vérifications différentes, et les confondre mène directement à une faille IDOR.
Supposons qu'il existe un autre utilisateur standard nommé Bob, dont l'identifiant est 1002. Si l'application est vulnérable à l'IDOR, elle fera aveuglément confiance au paramètre user_id dans l'URL sans vérifier si Alice a la permission de consulter le profil de Bob.
Modifiez le paramètre user_id dans votre commande précédente, en remplaçant 1001 par 1002. Exécutez la commande suivante :
curl -H "Authorization: Bearer alice_token" \
"http://localhost:5000/api/profile?user_id=1002"
Observez le résultat renvoyé par le serveur :
{"name": "Bob", "role": "user", "email": "bob@example.com", "secret": "bob_secret_456"}
Vous avez réussi à récupérer les informations privées de Bob, y compris son adresse e-mail et sa clé secrète, tout en étant authentifié en tant qu'Alice !
Cela confirme la présence d'une vulnérabilité de type Insecure Direct Object Reference (IDOR). Le serveur a vérifié que vous étiez connecté (en validant le jeton), mais il a échoué à vérifier si vous étiez autorisé à accéder à l'objet spécifique (le profil de Bob) que vous aviez demandé.
Accéder à des données non autorisées
Après avoir confirmé la vulnérabilité IDOR, vous pouvez maintenant intensifier l'attaque pour accéder à des informations hautement sensibles. Dans de nombreux systèmes, les utilisateurs administrateurs ont des identifiants prévisibles, tels que 1, 0 ou 9999.
Pour cette application, l'identifiant de l'administrateur est 9999. En exploitant la même vulnérabilité IDOR, vous pouvez tenter d'extraire le profil de l'administrateur, qui contient un flag secret.
Pour documenter votre découverte, vous allez rediriger la sortie de votre commande curl vers un fichier nommé flag.txt dans votre répertoire de travail actuel (~/project).
Exécutez la commande suivante pour récupérer le profil de l'administrateur et l'enregistrer :
curl -H "Authorization: Bearer alice_token" \
"http://localhost:5000/api/profile?user_id=9999" > ~/project/flag.txt
Le symbole > redirige la sortie qui s'afficherait normalement sur votre écran vers le fichier spécifié.
Pour vérifier que vous avez bien capturé les données de l'administrateur, lisez le contenu du fichier à l'aide de la commande cat :
cat ~/project/flag.txt
Vous devriez voir les données du profil de l'administrateur, y compris le flag secret :
{"name": "Admin", "role": "admin", "email": "admin@example.com", "secret": "FLAG{IDOR_VULN_EXPLOITED}"}
Félicitations ! Vous avez réussi à exploiter une vulnérabilité IDOR pour contourner les contrôles d'accès et récupérer des données administratives sensibles.
Résumé
Dans ce laboratoire, vous avez exploré les mécanismes des références directes à des objets non sécurisées (IDOR), une faille critique de contrôle d'accès. Vous avez commencé par vous authentifier en tant qu'utilisateur standard et par analyser la manière dont l'application référençait les données utilisateur via des paramètres d'URL. En manipulant ces paramètres, vous avez réussi à contourner les contrôles d'autorisation pour consulter les profils privés d'autres utilisateurs. Enfin, vous avez intensifié l'attaque pour extraire des données administratives sensibles.
Cet exercice souligne l'importance de mettre en œuvre des contrôles d'autorisation robustes côté serveur. Les applications ne doivent jamais se fier uniquement aux entrées fournies par l'utilisateur pour accorder l'accès à des objets ; elles doivent toujours vérifier que l'utilisateur authentifié dispose du droit explicite d'accéder à la ressource demandée.
