Einführung
Fieldwork Studio bietet öffentliche Kreativworkshops an. Der Zeitplan soll einfach anzusehen und herunterzuladen sein, während Wartungsdiagnosen eine Autorisierung erfordern sollten. Deine Aufgabe ist es festzustellen, welche Antworten tatsächlich interne Diagnosedaten dieser Anwendung offenlegen.
Nutze zuerst die normale Website. Vergleiche dann drei echte Antworten und führe eine bewusst zu breit gefasste Nuclei-Ausgangsprüfung aus. Am Ende verknüpfst du deine Schlussfolgerungen mit den untersuchten Antworten, statt jeden Scannerfund als bestätigtes Problem zu behandeln. Alle Konfigurationen und Identitäten sind synthetisch; die HTTP-Anfragen und die Ausführung des Scanners sind echt.
Du benötigst nur grundlegende Terminaleingaben und ein Verständnis von Pfaden. Das Lab erklärt HTTP, JSON und Scannerausgaben bei ihrer Verwendung. Der Kali-Auditor und das Ziel sind isolierte Container, die sich einen VM-Kernel teilen. Teste ausschließlich den bereitgestellten Umfang, verwende nur lesende Anfragen und erhalte die Workshop-Website samt Zeitplan. Plane einschließlich Lesen und gewöhnlicher Fehler etwa 50 Minuten ein; dies ist eine Schätzung des Autors.
Den öffentlichen Workshop-Zeitplan nutzen
In diesem Schritt stellst du fest, was beim normalen öffentlichen Zugriff erhalten bleiben muss. Öffne Workshops. Die Seite stellt die Kreativkurse von Fieldwork Studio vor. Folge Get the workshop schedule, um fieldwork-schedule.csv herunterzuladen. Die Datei enthält Workshop-Name, Uhrzeit und Raum für Printmaking und Bookbinding. Der öffentliche Zugriff auf diese Informationen ist beabsichtigt.
Die beiden Kurskarten und der grüne Zeitplan-Link bilden den normalen öffentlichen Dienst. Erhalte ihre tatsächlichen Workshop-Informationen, während du die Diagnosen bewertest.
Wechsle zu Auditor, dem Kali-Terminal. Es startet in /home/labex/project. Der Browsereinstieg und dieses Terminal erreichen denselben Workshop-Dienst; sie stehen nicht für verschiedene Zielrechner.
cat zeigt eine Textdatei an. Lies den autorisierten Umfang, bevor du Sicherheitsprüfungen sendest:
cat scope.txt
Autorisiert sind ausschließlich lesende HTTP-GET-Anfragen an die Basis-URLs in targets.txt. Eine Basis-URL bezeichnet eine Website; die Diagnoseroute wird daran angehängt. Zeige die Liste an:
cat targets.txt
Du solltest studio, archive und manual unter http://workshop.test:8080/ sehen. Der Port 8080 bezeichnet den Dienst dieses Kurses. Erhalte alle Websites, Konfigurationen und Workshop-Daten. Du bewertest den Zugriff, ohne die Anwendung zu verändern.
Wenn ein relativer Dateipfad fehlschlägt, zeige mit pwd dein aktuelles Verzeichnis an und kehre anschließend zurück:
cd /home/labex/project
Das Schließen oder erneute Verbinden von Auditor erstellt die Websites nicht neu. Deine Dateien bleiben in diesem Arbeitsverzeichnis erhalten.
Vor der Entscheidung die Antworten lesen
In diesem Schritt vergleichst du den Diagnose-Endpunkt jeder freigegebenen Website. Bleibe in Auditor. HTTP ist das von dieser Website verwendete Protokoll für Anfragen und Antworten. curl sendet eine Anfrage und gibt den Antwortinhalt aus. Die Option -i zeigt zusätzlich die Antwortheader einschließlich Status und Inhaltstyp an.
curl -i http://workshop.test:8080/studio/maintenance/diagnostics
Die Antwort beginnt mit HTTP/1.0 200 OK. Das bedeutet, dass der Server die angeforderte Ressource erfolgreich zurückgegeben hat; allein dadurch ist noch kein Sicherheitsproblem nachgewiesen. Content-Type: application/json; charset=utf-8 besagt, dass der Inhalt JSON als UTF-8-kodierter Text ist. JSON stellt benannte Werte in geschweiften Klammern dar. Namen und Textwerte stehen in doppelten Anführungszeichen; Zahlenwerte stehen ohne Anführungszeichen.
Das flache Objekt enthält service, visibility, database_file und request_count. Bei dieser Anwendung ist service gleich workshop-portal, visibility gleich internal, die Datenbankdatei ein absoluter Pfad und der Anfragezähler eine nichtnegative ganze Zahl. Der Dateipfad stammt aus der Konfiguration der laufenden Website: Ihre öffentliche Workshop-Seite und der CSV-Download lesen diese tatsächliche SQLite-Datenbank. SQLite speichert eine kleine Datenbank in einer Datei. Der Zähler verändert sich bei eingehenden Anfragen. Diese Kombination ist der in scope.txt veröffentlichte Diagnosevertrag. Sie ist keine allgemeingültige Definition einer Schwachstelle.
Eine nicht authentifizierte Anfrage hat diese internen Werte erhalten. Beachte ihren Header X-Audit-Event: Der Server gibt jeder echten Antwort eine andere Kennung. Notiere die Kennung an einem privaten Ort für die abschließende Bewertung. Auf diesen Nachweis kannst du verweisen, ohne interne Werte in deine Zusammenfassung zu kopieren.
Vergleiche die zweite Website:
curl -i http://workshop.test:8080/archive/maintenance/diagnostics
Erwarte 401 Unauthorized und einen Hinweis, dass ein Wartungszugang erforderlich ist. Diese Ablehnung ist beabsichtigt. Du hast keine Zugangsdaten innerhalb des freigegebenen Umfangs und sollst nicht versuchen, sie zu umgehen. curl -i kann regulär enden und dabei HTTP 401 anzeigen: Die erfolgreiche Übermittlung einer Ablehnung unterscheidet sich von einer erfolgreichen Autorisierung.
Untersuche nun die dritte Website:
curl -i http://workshop.test:8080/manual/maintenance/diagnostics
Sie liefert HTTP 200 und JSON zurück, aber die Diagnosefelder sind in einem example-Objekt verschachtelt. Sie dokumentieren ein Antwortformat; sie sind nicht das aktuelle Diagnoseobjekt auf oberster Ebene dieser Website. Vergleiche Struktur und Bedeutung, statt nur nach dem Wort internal zu suchen. Bewahre auch die Ereigniskennung dieser Antwort auf.
Wenn du 404 siehst, vergleiche die URL sorgfältig mit der vorgegebenen Route und wiederhole die korrigierte Anfrage. Could not resolve host oder Failed to connect bedeutet, dass die Anfrage die beabsichtigte Antwort nicht erhalten hat; daraus lässt sich weder Sicherheit noch Offenlegung ableiten. Prüfe die Schreibweise sowie den genauen Kurs-Hostnamen und Port. Ersetze das Ziel nicht durch eine öffentliche Website.
Einen zu breit gefassten Nuclei-Fund untersuchen
In diesem Schritt siehst du, wie eine Prüfung korrekt ablaufen und dennoch eine zu weitgehende Aussage treffen kann. Bleibe in Auditor. Nuclei ist ein vorlagenbasierter Scanner: Eine Vorlage beschreibt Anfragen und die Antwortbedingungen, die Funde erzeugen. Ein Fund bedeutet, dass diese Bedingungen zutrafen; du musst weiterhin beurteilen, ob sie das eigentlich geprüfte Problem nachweisen.
Lies die vorbereitete Ausgangsvorlage:
cat too-broad.yaml
YAML verwendet Einrückungen zum Gruppieren von Einstellungen. Diese Ausgangsvorlage sendet ein GET an die Diagnoseroute jeder Basis-URL und prüft dann lediglich den HTTP-Status 200. Der Platzhalter {{BaseURL}} wird durch die aktuelle freigegebene Basis-URL ersetzt. Die Bedeutung des Diagnoseobjekts untersucht sie nicht.
Führe die Ausgangsvorlage gegen die bereitgestellte Liste aus. -t wählt eine lokale Vorlage; -l liest die Zielliste; -o speichert Funde; und -elog speichert Anfragefehler. -jsonl schreibt einen JSON-Fund pro Zeile, und -ot lässt die kodierte Vorlage in dieser Ausgabe weg. Die Vorbereitungsoptionen -duc und -ni deaktivieren Aktualisierungsprüfungen und externe Interactsh-Callbacks. Unsere Vorlage benötigt beides nicht. Behalte diese Optionen für die isolierte Übung bei.
nuclei -t too-broad.yaml -l targets.txt -duc -ni -nc -jsonl -ot -o broad-findings.jsonl -elog broad-errors.jsonl
-nc entfernt Terminal-Farbcodes. Dieser Befehl führt echte lesende Anfragen aus. Erwarte Funde sowohl für studio als auch für manual, da beide 200 zurückgaben. Die geschützte Route archive erfüllt die Bedingung nicht. Ein Scan ohne ausgegebene Funde ist nicht automatisch eine abgeschlossene negative Prüfung.
Lies das native Anfragefehlerprotokoll, bevor du die Ergebnisse beurteilst:
cat broad-errors.jsonl
Ein leeres Protokoll bedeutet, dass in diesem Durchlauf keine Anfragefehler aufgezeichnet wurden. Ein Verbindungsfehler kann trotzdem den Prozess-Exitstatus von Nuclei auf null belassen; deshalb reichen weder der Exitstatus noch eine leere Funddatei allein aus. Enthält das Protokoll einen Fehler, behebe das Ziel- oder Verbindungsproblem, bevor du eine Schlussfolgerung ziehst. Bewahre den ursprünglichen Fehlernachweis auf; verwende bei einem erneuten Versuch einen neuen Ausgabedateinamen.
Untersuche die Funde:
cat broad-findings.jsonl
Jede Zeile enthält eine matched-at-URL und die Nachweise zu Anfrage und Antwort. Vergleiche den Fund bei manual mit dem bereits gelesenen verschachtelten Dokumentationsbeispiel. Für deine beabsichtigte Frage nach offengelegten Diagnosedaten ist dies ein Fehlalarm, obwohl der Status-Matcher der Ausgangsvorlage wie geschrieben funktioniert hat. Die Antwort von studio erfüllt hingegen die definierten Offenlegungsbedingungen.
Diese synthetischen Antworten enthalten keine echten Geheimnisse. Bei einer echten Bewertung können Rohfunde sensible Informationen enthalten und sollten vertraulich behandelt werden. Lade sie nicht bei einem externen Scanner hoch und füge sie nicht in einen öffentlichen Bericht ein.
Eine mit Nachweisen verknüpfte Bewertung speichern
In diesem Schritt trennst du deine Schlussfolgerung vom breit gefassten Treffer des Scanners. Bleibe in Auditor. Erstelle assessment.json mit einem Eintrag pro Website. Jeder Eintrag enthält das tatsächlich untersuchte Antwortereignis und deine Schlussfolgerung. Verwende exposed, access-denied und documentation-example für die drei oben vermittelten Ergebnisse.
Das Folgende ist ein vollständiges Shell-Here-Dokument. cat > assessment.json schreibt eine Datei; > ersetzt ihren Inhalt. <<'JSON' lässt die Shell den folgenden Text wörtlich kopieren, bis zur Zeile, die nur JSON enthält. Der in Anführungszeichen stehende Begrenzer verhindert Shell-Erweiterungen innerhalb des Texts. Ersetze jeden Wert REPLACE_... durch ein tatsächliches X-Audit-Event aus der Diagnoseantwort der jeweiligen Website, bevor du den Block ausführst. Behalte die doppelten JSON-Anführungszeichen und die Kommas bei.
cat > assessment.json <<'JSON'
{
"studio": {"event_id": "REPLACE_STUDIO_EVENT", "conclusion": "exposed"},
"archive": {"event_id": "REPLACE_ARCHIVE_EVENT", "conclusion": "access-denied"},
"manual": {"event_id": "REPLACE_MANUAL_EVENT", "conclusion": "documentation-example"}
}
JSON
Falls du eine Kennung nicht aufbewahrt hast, wiederhole die curl -i-Anfrage der betreffenden Website aus Schritt 2 und verwende ihre neue Kennung. Eine wiederholte Leseanfrage erzeugt eine weitere echte Antwort und kann request_count erhöhen; sie repariert oder verändert die Zugriffsrichtlinie der Website nicht.
Zeige die gespeicherte Datei an:
cat assessment.json
Ist ein Anführungszeichen, Komma oder Ereigniswert falsch, wiederhole das vollständige korrigierte Here-Dokument. Kopiere nicht die wörtlichen Platzhalterwerte. Liefere assessment.json als lesbare reguläre Datei in diesem Arbeitsverzeichnis ab. Die Verifikation vergleicht deine Schlussfolgerungen mit vorhandenen Antworten; sie erzeugt keine fehlenden Bewertungsanfragen. Du musst für diese kleine Zusammenfassung auch weder den Diagnose-Host noch den rohen Antwortinhalt kopieren.
Dein Ergebnis bestätigt eine Offenlegung bei studio, beobachtet eine echte Ablehnung bei archive und erklärt den irreführenden Dokumentationstreffer bei manual. Es behauptet nicht, dass alle anderen Routen oder Schwachstellen getestet wurden. Das nächste geführte Lab startet ein neues Szenario und zeigt dir, wie du den zu breiten Matcher durch eine portable native Nuclei-Prüfung ersetzt.
Zusammenfassung
Du hast den öffentlichen Workshop-Zeitplan genutzt, HTTP-Status und JSON-Struktur untersucht und eine Offenlegung interner Diagnosedaten bestätigt. Du hast eine echte Nuclei-Ausgangsprüfung ausgeführt und ihren Fehlalarm beim Dokumentationsbeispiel erklärt. Deine Bewertung verknüpft jede Schlussfolgerung mit einer vorhandenen Antwort und erhält dabei den normalen öffentlichen Zugriff.
