Einführung
Ein Shop importiert Produktbilder aus einem vorbereiteten Katalog. Dein Browser fordert eine Anwendung auf, ein Bild abzurufen; diese Anwendung hat Netzwerkzugriff, den der Käufer nicht besitzt. Du verfolgst die echte Anfrage und untersuchst einen harmlosen internen Statusdatensatz, um serverseitige Request-Fälschung (SSRF) zu verstehen.
Verwende ausschließlich die bereitgestellten Übungs-URLs. Organisationen und interne Daten sind synthetisch. Grundlegende Terminalkenntnisse genügen: HTTP, URL-Felder, Netzwerkrollen und Weiterleitungen werden hier erklärt. Die Container besitzen eigene Netzwerk-Namespaces und teilen den Kernel einer Instanz.
Ein gewöhnliches Produktbild importieren
In diesem Schritt importierst du ein echtes Bild und erkennst den abrufenden Server. Wechsle zum Tab Image Importer. Das Formular sendet eine URL an App, den Server der Bildfunktion. Eine URL ist eine Adresse: http bezeichnet das Protokoll (Schema), catalog.test den Hostnamen, 8000 den lauschenden Port und /leaf.png den Ressourcenpfad.
Wähle zu Beginn dieses Schritts den Tab Image Importer in der Lab-Oberfläche aus.
Lass Image URL auf http://catalog.test:8000/leaf.png und Import slot auf normal. Klicke auf Import image. Die Seite Import result zeigt den tatsächlichen HTTP-Status und ein JSON-Objekt, also eine Antwort aus benannten Feldern. Suche content_type: image/png und einen Hash als Fingerabdruck der abgerufenen Bytes. Das Feld body enthält codierte Bildbytes; du musst dieses Feld weder bearbeiten noch decodieren.
Wähle im selben Tab Back to Image Importer (oder verwende die Zurück-Schaltfläche des Browsers) und aktualisiere die Seite. Unter Imported responses sollte nun ein grünes Bild erscheinen. Falls nicht, prüfe URL und Slot-Schreibweise und sende erneut ab.
Wechsle zum Tab Workstation. Dieses Terminal ist ein Client-Container. Das vorbereitete Programm imagectl.py sendet Anfragen an App; python3 führt es aus. show normal liest den vorhandenen Import ohne erneuten Abruf:
Wechsle zum Tab Workstation, bevor du den folgenden Befehl ausführst.
python3 imagectl.py show normal
Achte auf HTTP 200, session: learner-c08 und PNG image content. HTTP ist ein Anfrage-Antwort-Protokoll; 200 bedeutet Erfolg. Lies nun die echten Anfrageeinträge von Catalog:
python3 imagectl.py requests
Jeder Eintrag enthält die Adresse client und den angefragten path. Catalog sah Apps Adresse im Katalognetz, nicht Workstation oder deinen Browser. App stellte die ausgehende Anfrage. Die wechselnde Adresse stammt aus dem Dienst und muss nicht auswendig gelernt werden. Wechsle zum Tab Topology, um die konfigurierten Netzwerkverbindungen und die Live-Zustandsprüfung des internen Verbrauchers zu vergleichen.
Erreichbarkeit von Client und Server vergleichen
In diesem Schritt rufst du ausschließlich den vorbereiteten internen Bestandsstatus über App ab. Ein interner Dienst liegt in einem für Anwendungskomponenten reservierten Netz. Workstation gehört zum Frontnetz; App zusätzlich zum internen Netz. localhost bezeichnet immer die Umgebung, in der der Befehl läuft: Workstations Loopback ist nicht Apps Loopback.
Wähle zu Beginn dieses Schritts den Tab Workstation in der Lab-Oberfläche aus.
Versuche einen direkten Abruf aus Workstation. Das Hilfsprogramm zeigt erwartete Fehler an, ohne die Shell zu stoppen:
Wechsle zum Tab Workstation, bevor du den folgenden Befehl ausführst.
python3 imagectl.py direct http://internal.test:8000/status
Erwarte UNREACHABLE from Workstation. Dieser Hostname ist im Container nicht verfügbar. Die Netze isolieren auch die zugrunde liegende Adresse; es fehlt nicht bloß ein Name. Bitte nun App, dieselbe Ressource abzurufen. fetch importiert sie; das letzte Argument benennt den Speicherplatz der Antwort:
python3 imagectl.py fetch http://internal.test:8000/status internal
Erwarte HTTP 200 und einen JSON-Inhalt mit service: inventory, status: synthetic-ready und einer wechselnden training_id. Lies die importierte Antwort erneut:
python3 imagectl.py show internal
Der Eintrag gehört zu learner-c08. Das ist SSRF: Eine vom Client kontrollierte Eingabe veranlasst den Server, seinen eigenen Netzwerkzugriff einzusetzen. Workstation hat keine zusätzliche Netzwerkverbindung erhalten. Bei no import wiederhole den Abruf mit dem Slot internal; relevant ist nur der synthetische Datensatz der aktuellen VM.
Der Katalogweiterleitung folgen
In diesem Schritt erkennst du, weshalb die Prüfung des ersten Ziels nicht immer genügt. Eine Weiterleitung ist eine HTTP-Antwort, die den Client zu einer anderen URL schickt. Catalogs Route /redirect liefert 302 mit einem Location zum selben synthetischen Bestandsdienst. Die verwundbare App folgt automatisch.
Wähle zu Beginn dieses Schritts den Tab Workstation in der Lab-Oberfläche aus.
Importiere diese vorbereitete Route im Tab Workstation in einen eigenen Slot:
Wechsle zum Tab Workstation, bevor du den folgenden Befehl ausführst.
python3 imagectl.py fetch http://catalog.test:8000/redirect redirect
Das Feld url nennt Catalog, final_url dagegen Internal. Der Inhalt ist der aktuelle synthetische Bestandsstatus und kein Bild. Untersuche die gespeicherte Antwort und das Kataloglog:
python3 imagectl.py show redirect
python3 imagectl.py requests
Catalog protokollierte /redirect; anschließend nutzte App ihr anderes Netz, um Internal abzurufen. Ein vertrauenswürdiger erster Host macht das nächste Ziel nicht vertrauenswürdig. Das nächste Lab beginnt unabhängig und repariert Zielauswahl sowie Weiterleitungsverhalten. Diese kontrollierte Übung testet keine bösartigen DNS-Änderungen, beliebigen Internet-Bildquellen oder alternativen Adresskodierungen.
Zusammenfassung
Du hast ein echtes Bild importiert, die Erreichbarkeit für Client und Server verglichen und eine tatsächlich weitergeleitete Antwort untersucht. Die internen Daten waren synthetisch; die Netzwerkanfragen waren real.
