Introduction
Une facture indique les achats d’un client, leur prix et son adresse de facturation. Un client doit pouvoir lire ses propres factures ou celles qui lui sont explicitement partagées. Connaître un identifiant ne donne pas le droit de lire l’objet.
Vous êtes autorisé à tester Invoice Desk avec des données synthétiques en tant qu’Alex. Établissez l’accès normal, comparez une facture partagée à une facture privée, puis enregistrez la réponse privée pour démontrer une faille de propriété. Le laboratoire s’arrête à la validation, sans réparation du serveur. Seuls les objets fournis sont autorisés.
Établir votre accès normal
Dans cette étape, connectez-vous en tant qu’Alex et récupérez votre facture avant de tester un autre compte.
Sélectionnez l’onglet Invoice Desk dans l’interface du laboratoire pour commencer cette étape.
Passez à l’onglet Invoice Desk. Le schéma montre un client qui envoie des requêtes et un serveur d’API qui y répond. Une API est l’interface de requêtes de l’application. API: ready provient d’une véritable requête de santé. La table indique les règles attendues :
| Identifiant | Propriétaire | Partagée avec | Alex peut lire ? |
|---|---|---|---|
inv-104 |
alex |
Personne | Oui : propriétaire |
inv-208 |
morgan |
Personne | Non : privée |
inv-315 |
riley |
alex |
Oui : partage explicite |
Dans le portail, saisissez l’utilisateur alex et le mot de passe shop-alex-42, puis cliquez sur Sign in. Attendez Signed in as alex. Saisissez inv-104 dans Invoice ID et cliquez sur View invoice. Le champ owner doit être alex.
Passez à l’onglet Client Terminal. C’est un espace client isolé dans /home/student/project, pas le serveur. invoice-api:8000 désigne le serveur dans ce réseau de formation, pas une cible publique. curl envoie des requêtes HTTP depuis le terminal. HTTP est le protocole requête/réponse utilisé ici ; GET demande la lecture d’une ressource. Le chemin après l’adresse identifie cette ressource. -i inclut le statut et les en-têtes de réponse.
Sans session, attendez 401 Unauthorized, qui exige une connexion :
Passez à l’onglet Client Terminal avant d’exécuter la commande suivante.
curl -i http://invoice-api:8000/api/invoices/inv-104
La connexion du navigateur ne connecte pas curl. Une session est un enregistrement côté serveur de l’identité connectée ; un cookie aléatoire relie les requêtes suivantes à cet enregistrement. La commande envoie un objet JSON, un format de champs nommés. -H définit un en-tête indiquant JSON, -d envoie les identifiants et choisit POST, et -c enregistre le cookie retourné dans session.txt. Les apostrophes conservent espaces et guillemets doubles dans un seul argument du shell.
curl -sS -c session.txt -H 'Content-Type: application/json' -d '{"username":"alex","password":"shop-alex-42"}' http://invoice-api:8000/api/login
-sS masque la progression mais affiche les erreurs de connexion. account doit être alex. -b envoie le cookie enregistré. Vérifiez l’identité de la session :
curl -sS -b session.txt http://invoice-api:8000/api/me
Demandez votre facture :
curl -sS -b session.txt http://invoice-api:8000/api/invoices/inv-104
Lisez invoice_id, owner, item et total_usd : Alex a acheté Desk lamp pour 38.00. La liste vide shared_with, [], signifie qu’aucune autre personne n’est autorisée. C’est normal. Le contrôle porte sur la réponse réelle du serveur à Alex, depuis le terminal ou le portail.
Si vous obtenez 401 après connexion, répétez la commande de connexion dans ce terminal, puis réessayez avec -b session.txt. Une erreur de connexion est différente : aucune réponse HTTP ne vous est parvenue ; vérifiez l’adresse et API: ready.
Demander une autre facture
Dans cette étape, comparez le partage explicite à une facture privée en conservant la même identité connectée.
Sélectionnez l’onglet Client Terminal dans l’interface du laboratoire pour commencer cette étape.
L’authentification répond à « Qui êtes-vous ? ». L’autorisation répond à « Cette personne peut-elle lire cette facture ? ». La connexion ne règle que la première question. Téléchargez d’abord la facture légitimement partagée. Un téléchargement reste une requête GET ; /download sélectionne une réponse destinée à être enregistrée, avec les mêmes champs JSON.
Passez à l’onglet Client Terminal avant d’exécuter la commande suivante.
curl -sS -b session.txt http://invoice-api:8000/api/invoices/inv-315/download
Le propriétaire est riley, mais shared_with contient alex. Cet accès est permis. Un propriétaire différent ne prouve pas à lui seul une faille.
Prévoyez ensuite le cas privé : inv-208 appartient à Morgan et n’est partagée avec personne. Alex devrait recevoir un refus, souvent 403 Forbidden. Un service peut aussi utiliser 404 Not Found pour dissimuler l’existence d’un objet privé. Ici, 404 désigne également un identifiant inconnu. 200 OK signifie que la requête a réussi ; le corps montre les données exposées.
-v affiche la requête envoyée et les en-têtes reçus, ainsi que votre cookie de session de formation. Ne diffusez pas cette sortie hors du laboratoire. Exécutez :
curl -v -b session.txt http://invoice-api:8000/api/invoices/inv-208
Repérez GET /api/invoices/inv-208 et HTTP/1.0 200 OK. Le corps indique le propriétaire morgan, une liste de partage vide, Studio microphone et l’adresse 82 Cedar Lane. Le serveur a fourni un objet privé à Alex. Vous avez changé le chemin de l’objet, pas l’identité de session. Les identifiants prévisibles facilitent le test ; l’absence de contrôle des permissions cause l’exposition.
Passez à l’onglet Invoice Desk pour répéter les deux requêtes : Download invoice pour inv-315 et View invoice pour inv-208. Le client web enregistre les téléchargements dans le même espace client. Le contrôle exige le téléchargement partagé autorisé et la consultation privée, pas un fichier d’explication.
Vérifier l’exposition
Dans cette étape, conservez le véritable téléchargement privé et reliez les données exposées à leur impact métier.
Sélectionnez l’onglet Client Terminal dans l’interface du laboratoire pour commencer cette étape.
Utilisez /download pour la facture privée. -o écrit les octets de réponse dans un fichier au lieu de les afficher. Enregistrez la réponse complète dans private-invoice.json, dans l’espace client courant :
Passez à l’onglet Client Terminal avant d’exécuter la commande suivante.
curl -sS -b session.txt -o private-invoice.json http://invoice-api:8000/api/invoices/inv-208/download
cat affiche un fichier pour le lire :
cat private-invoice.json
Retrouvez la facture de Morgan : invoice_id inv-208, propriétaire morgan, montant 129.00 et adresse de facturation. Si vous avez enregistré une erreur 401 ou la facture partagée, reconnectez-vous si nécessaire puis téléchargez la facture privée désignée ; -o remplace le fichier.
Autre méthode : passez à l’onglet Invoice Desk. Connecté en tant qu’Alex, saisissez inv-208 puis cliquez sur Download invoice. Ce client web transmet la véritable requête API et enregistre la réponse intacte dans /home/student/project/private-invoice.json, consultable après être revenu à l’onglet Client Terminal. Les deux méthodes satisfont le même résultat.
Lancez le contrôle. Il compare les octets enregistrés à la facture désignée et vérifie que le serveur a enregistré ce téléchargement sous la session d’Alex. Une affirmation copiée, une facture inventée, une facture partagée autorisée ou un fichier sans téléchargement client correspondant ne démontrent pas le résultat.
L’impact est la divulgation des achats et de l’adresse d’un autre client. Le serveur doit vérifier la propriété ou le partage explicite pour chaque objet demandé, y compris les téléchargements. Cacher les liens ou rendre les identifiants difficiles à deviner ne remplace pas ce contrôle. C’est le problème d’autorisation au niveau objet décrit par OWASP BOLA. Votre test autorisé est terminé ; la réparation du serveur relève d’une tâche distincte.
Résumé
Vous avez établi une session client, lu votre facture, distingué partage explicite et accès privé, puis enregistré une véritable réponse entre comptes. Vous avez vérifié les données exposées et l’identité qui les a reçues, sans accès serveur ni identifiants de victime.
