Introduction
Une boutique importe les images de ses produits depuis un catalogue préparé. Votre navigateur demande à une application de récupérer une image ; celle-ci dispose d’un accès réseau que le client n’a pas. Vous suivrez la requête réelle et consulterez un relevé interne inoffensif pour comprendre la falsification de requêtes côté serveur (SSRF).
Utilisez uniquement les URL d’entraînement fournies. Les organisations et données internes sont synthétiques. Une connaissance élémentaire du terminal suffit : HTTP, champs d’URL, rôles réseau et redirections sont expliqués ici. Les conteneurs disposent d’espaces de noms réseau distincts et partagent le noyau d’une instance.
Importer une image de produit ordinaire
Dans cette étape, importez une véritable image et identifiez le serveur qui l’a récupérée. Passez à l’onglet Image Importer. Son formulaire envoie une URL à App, le serveur de cette fonction. Une URL est une adresse : http est le protocole (schéma), catalog.test le nom d’hôte, 8000 le port d’écoute et /leaf.png le chemin de la ressource.
Sélectionnez l’onglet Image Importer dans l’interface du laboratoire pour commencer cette étape.
Conservez Image URL à http://catalog.test:8000/leaf.png et Import slot à normal. Cliquez sur Import image. La page Import result affiche le véritable statut HTTP et un objet JSON, une réponse faite de champs nommés. Repérez content_type: image/png et un hachage, empreinte des octets récupérés. Le champ body contient les octets encodés de l’image ; vous n’avez pas à le modifier ni à le décoder.
Sélectionnez Back to Image Importer dans le même onglet (ou utilisez le bouton Retour du navigateur), puis actualisez la page. Une image verte doit apparaître sous Imported responses. Sinon, vérifiez l’orthographe de l’URL et de l’emplacement, puis renvoyez le formulaire.
Passez à l’onglet Workstation, terminal d’un conteneur client. Le programme préparé imagectl.py envoie les requêtes à App ; python3 l’exécute. show normal lit l’import existant sans nouvelle récupération :
Passez à l’onglet Workstation avant d’exécuter la commande suivante.
python3 imagectl.py show normal
Repérez HTTP 200, session: learner-c08 et PNG image content. HTTP est un protocole requête/réponse ; 200 indique la réussite. Lisez maintenant les véritables journaux de Catalog :
python3 imagectl.py requests
Chaque entrée contient l’adresse client et le path demandé. Catalog a vu l’adresse d’App sur son réseau, pas Workstation ni votre navigateur. App a émis la requête sortante. Cette adresse variable constitue une observation du service, pas une valeur à mémoriser. Passez à l’onglet Topology pour comparer les connexions configurées et une sonde en direct du consommateur interne.
Comparer l’accessibilité du client et du serveur
Dans cette étape, récupérez uniquement l’état interne d’inventaire préparé via App. Un service interne se trouve sur un réseau réservé aux composants applicatifs. Workstation appartient au réseau frontal ; App appartient aussi au réseau interne. localhost désigne toujours l’environnement exécutant la commande : la boucle locale de Workstation n’est pas celle d’App.
Sélectionnez l’onglet Workstation dans l’interface du laboratoire pour commencer cette étape.
Essayez une requête directe depuis Workstation. L’outil affiche les échecs attendus sans arrêter le shell :
Passez à l’onglet Workstation avant d’exécuter la commande suivante.
python3 imagectl.py direct http://internal.test:8000/status
Attendez-vous à UNREACHABLE from Workstation. Ce nom d’hôte n’est pas disponible dans ce conteneur. Les réseaux isolent également l’adresse sous-jacente ; ce n’est pas seulement un nom manquant. Demandez maintenant à App de récupérer la même ressource. fetch réalise un import ; le dernier argument nomme l’emplacement où conserver la réponse :
python3 imagectl.py fetch http://internal.test:8000/status internal
Attendez-vous à HTTP 200 et un corps JSON contenant service: inventory, status: synthetic-ready et un training_id variable. Relisez la réponse importée :
python3 imagectl.py show internal
L’entrée appartient à learner-c08. C’est une SSRF : une entrée contrôlée par le client amène le serveur à utiliser son propre accès réseau. Workstation n’a reçu aucune nouvelle connexion réseau. Si vous voyez no import, recommencez avec l’emplacement internal ; seul le relevé synthétique de la VM actuelle compte.
Suivre la redirection du catalogue
Dans cette étape, découvrez pourquoi vérifier la première destination peut être insuffisant. Une redirection est une réponse HTTP indiquant au client une autre URL à demander. La route /redirect de Catalog retourne 302 avec un Location vers le même service d’inventaire synthétique. L’App vulnérable la suit automatiquement.
Sélectionnez l’onglet Workstation dans l’interface du laboratoire pour commencer cette étape.
Dans l’onglet Workstation, importez cette route préparée dans un emplacement distinct :
Passez à l’onglet Workstation avant d’exécuter la commande suivante.
python3 imagectl.py fetch http://catalog.test:8000/redirect redirect
Le champ url désigne Catalog, mais final_url désigne Internal. Le corps est l’état synthétique courant de l’inventaire, pas une image. Examinez la réponse enregistrée et le journal de Catalog :
python3 imagectl.py show redirect
python3 imagectl.py requests
Catalog a enregistré /redirect ; App a ensuite utilisé son autre réseau pour atteindre Internal. Un hôte de départ fiable ne rend pas la destination suivante fiable. Le prochain laboratoire repart d’un environnement indépendant et corrige deux décisions : les destinations autorisées et le suivi des redirections. Cet exercice contrôlé ne teste ni les changements DNS hostiles, ni les sources Internet arbitraires, ni d’autres encodages d’adresses.
Résumé
Vous avez importé une véritable image, comparé l’accessibilité côté client et serveur et examiné une réponse réellement redirigée. Les données internes étaient synthétiques ; les requêtes réseau étaient réelles.
