Eine portable Nuclei-Diagnoseprüfung schreiben

Einführung

Ein Scanner, der nur den Status prüfte, fand sowohl eine echte Diagnoseantwort als auch ein Dokumentationsbeispiel. Entwickle nun eine Prüfung für die beabsichtigte Frage: Hat eine nicht authentifizierte Anfrage das aktuelle interne Diagnoseobjekt dieser Anwendung erhalten?

Du erstellst eine native Nuclei-YAML-Vorlage, testest ihre Antwortbedingungen und scannst sechs freigegebene Fieldwork-Studio-Websites. Deine wiederverwendbare Vorlage und die echten Funde bilden die Übergabe. Die Umgebung ist unabhängig vom vorherigen Lab; keine Dateien oder Prozesse werden übernommen.

Absolviere zuerst Diagnoseoffenlegung mit echten Antworten bestätigen, oder sei mit dem Lesen von HTTP-Status, Content-Type-Headern, einem kleinen JSON-Objekt und Nuclei-JSONL-Funden vertraut. Dieses Lab erklärt sein YAML und seine Matcher-Ausdrücke. Die gesamte Zielkonfiguration ist synthetisch. Verwende ausschließlich den vorgegebenen lesenden Prüfumfang, erhalte die öffentlichen Workshop-Seiten und Zeitpläne und plane einschließlich Lesen und gewöhnlicher Fehler etwa 65 Minuten ein; dies ist eine Schätzung des Autors.

Den Antwortvertrag der Prüfung festlegen

In diesem Schritt stellst du den normalen Dienst und die genaue Frage fest, die deine Vorlage beantworten muss. Öffne Workshops, sieh dir die Kurse an und lade über Get the workshop schedule die echte fieldwork-schedule.csv herunter. Printmaking und Bookbinding müssen während deiner gesamten Bewertung verfügbar bleiben.

Die beiden Workshop-Karten zeigen den öffentlichen Dienst, den du erhalten musst. Der grüne Link Get the workshop schedule lädt seinen tatsächlichen Zeitplan herunter.

Wechsle zu Auditor. Es öffnet den Kali-Audit-Container in /home/labex/project. Lies den Prüfumfang und die freigegebenen Basis-URLs:

cat scope.txt

cat targets.txt

Die sechs Websites heißen studio, archive, manual, garden, status und members unter http://workshop.test:8080/. Teste nur diese URLs mit lesenden HTTP-GET-Anfragen. Verändere weder die Ziel-Websites noch die bereitgestellten Umfangsdateien.

Betrachte erneut eine aktuelle Diagnoseantwort. Wie zuvor zeigt curl -i die Antwortheader mit an:

curl -i http://workshop.test:8080/studio/maintenance/diagnostics

Ein Fund muss HTTP 200, einen JSON-Inhaltstyp und das interne Diagnoseobjekt der Anwendung auf oberster Ebene kombinieren. Seine vier skalaren Felder geben Dienst und Sichtbarkeit, einen absoluten Datenbankdateipfad sowie einen Anfragezähler als nichtnegative ganze Zahl ohne Anführungszeichen an. Dateipfad und Zähler können sich ändern. Die Reihenfolge der Schlüssel und Leerraum verändern die Bedeutung nicht. Ein verschachteltes Dokumentationsbeispiel ist nicht das aktuelle Objekt.

Deine Prüfung zielt auf das angegebene Antwortformat dieser kleinen Anwendung. Sie weist weder nach, dass ein beliebiger JSON-Endpunkt verwundbar ist, noch dass eine Website keine anderen Probleme hat. Insbesondere sind eine öffentliche Seite, eine öffentliche JSON-Zusammenfassung, eine Zustandsantwort, eine HTTP-Ablehnung oder eine Weiterleitung zur Anmeldung nicht der erforderliche Nachweis einer Offenlegung.

Wenn dein Verzeichnis wechselt, prüfe es mit pwd und kehre mit cd /home/labex/project zurück, bevor du relative Dateinamen liest oder erstellst. Behalte deine Arbeit beim erneuten Verbinden; das Öffnen eines Terminals baut das Szenario nicht neu auf.

Die nativen Antwort-Matcher erstellen

In diesem Schritt schreibst du eine wiederverwendbare Vorlage, statt dich auf einen HTTP-200-Treffer zu verlassen. Bleibe in Auditor.

Eine Nuclei-Vorlage besitzt eine id, beschreibende info und einen Protokollabschnitt wie http. Einrückungen gruppieren verschachtelte YAML-Felder, während ein Bindestrich einen Listeneintrag beginnt. Verwende Leerzeichen, keine Tabulatoren. method: GET wählt eine lesende Anfrage. {{BaseURL}} stammt vom an Nuclei übergebenen Ziel, sodass die Vorlage keinen bestimmten Hostnamen, Port oder Website-Präfix fest einbettet. redirects: false hält eine Weiterleitung zur Anmeldung als Weiterleitung sichtbar.

Ein Matcher ist eine auf eine Antwort angewendete Bedingung. Diese Vorlage verlangt alle drei Matcher-Gruppen:

matchers-condition: and kombiniert diese Gruppen. Ohne diese Angabe könnte die voreingestellte ODER-Verknüpfung wieder allein durch HTTP 200 einen Fund erzeugen. Innerhalb des DSL-Matchers verlangt condition: and ebenso jeden aufgeführten Ausdruck für den Antwortinhalt.

DSL bedeutet domänenspezifische Sprache: hier kurze Ausdrücke, die eine Antwort untersuchen. body ist der Antworttext. json_minify(body) parst gültiges JSON und komprimiert es, indem es bedeutungslosen Leerraum entfernt, ohne von der Schlüsselreihenfolge abzuhängen. contains(text, fragment) sucht nach einem wörtlichen Fragment. Durch die vorherige Normalisierung erfüllt ein als "visibility" : "internal" geschriebenes Feld dieselbe Bedingung wie "visibility":"internal".

regex(pattern, text) wendet einen regulären Ausdruck an. Die folgenden Ausdrücke verwenden eine kleine Menge von Symbolen:

• /[A-Za-z0-9._/-]+ verlangt einen führenden Schrägstrich, gefolgt von einem oder mehreren Pfadzeichen: Buchstaben, Ziffern, Punkten, Unterstrichen, Schrägstrichen oder Bindestrichen. Er akzeptiert veränderte absolute Pfade einschließlich Großbuchstaben.
• [0-9]+[,}] verlangt Ziffern, auf die unmittelbar ein Komma oder eine schließende geschweifte Klammer folgt. So wird weder ein Zähler in Anführungszeichen noch ein negativer Wert oder der Anfang einer Dezimalzahl als ganzzahliger Zähler behandelt.
• ^\{[^{}]*\}$ verlangt ein äußeres Paar geschweifter Klammern ohne verschachtelte Klammern. Es entspricht dem flachen Diagnoseformat mit vier Feldern dieses Kurses statt einem Objekt innerhalb eines Dokumentationsbeispiels.

Der Header-Ausdruck verwendet (?im) für eine zeilenbasierte Suche ohne Unterscheidung der Groß- und Kleinschreibung; \s* erlaubt Leerraum. Seine optionale Gruppe (?: ... )? akzeptiert Parameter wie ; charset=utf-8. Du kannst diesen Ausdruck als vollständige JSON-Inhaltstyp-Prüfung kopieren; du musst keinen allgemeinen MIME-Parser entwickeln.

Im folgenden YAML leitet >- einen Textwert in der nächsten eingerückten Zeile ein. Dadurch bleiben Anführungszeichen und Backslashes des Ausdrucks ohne zusätzliches YAML-Escaping erhalten. Die einfachen Anführungszeichen in jedem Ausdruck umschließen wörtlichen Text; die doppelten Anführungszeichen darin sind die zu prüfenden JSON-Feldzeichen.

Erstelle diagnostics.yaml. Wie im vorherigen Lab ersetzt > diese Datei, und der in Anführungszeichen stehende Here-Dokument-Begrenzer kopiert den Block wörtlich. Das abschließende YAML muss allein in seiner Zeile stehen.

cat > diagnostics.yaml <<'YAML'
id: workshop-diagnostics-exposed
info:
  name: Public workshop diagnostics
  author: labex
  severity: medium
http:
  - method: GET
    path:
      - "{{BaseURL}}/maintenance/diagnostics"
    redirects: false
    matchers-condition: and
    matchers:
      - type: status
        status: [200]
      - type: regex
        part: header
        regex:
          - '(?im)^content-type:\s*application/json(?:\s*;[^\r\n]*)?\s*$'
      - type: dsl
        condition: and
        dsl:
          - >-
            contains(json_minify(body), '"service":"workshop-portal"')
          - >-
            contains(json_minify(body), '"visibility":"internal"')
          - >-
            regex('"database_file":"/[A-Za-z0-9._/-]+"', json_minify(body))
          - >-
            regex('"request_count":[0-9]+[,}]', json_minify(body))
          - >-
            regex('^\{[^{}]*\}$', json_minify(body))
YAML

Lass die echte Engine die Vorlage validieren. -validate prüft die Vorlagensyntax von Nuclei; es weist kein korrektes Erkennungsverhalten nach. -t wählt deine Datei, -duc deaktiviert Aktualisierungsprüfungen, -ni deaktiviert externe Interactsh-Callbacks und -nc entfernt Terminal-Farbcodes.

nuclei -t diagnostics.yaml -validate -duc -ni -nc

Erwarte All templates validated successfully. Meldet Nuclei einen YAML- oder Ausdrucksfehler, vergleiche Einrückungen, Anführungszeichen und Backslashes mit dem vollständigen Block und wiederhole dann das korrigierte Here-Dokument sowie den Validierungsbefehl. Erhalte targets.txt und scope.txt.

Der Kurs akzeptiert diese vermittelte Teilmenge: eine HTTP-GET-Definition für den freigegebenen Pfad {{BaseURL}}/maintenance/diagnostics, keine Weiterleitungen und ausschließlich antwortbasierte Status-, Wort-, Regex- oder DSL-Matcher. Erlaubte DSL-Helfer sind contains, contains_all, contains_any, regex, json_minify, len, tolower, toupper, starts_with und ends_with, angewendet auf body, all_headers, status_code oder content_length. Verwende auf oberster Ebene nur id, info und http sowie die Anfragefelder method, path, redirects, matchers-condition und matchers. Halte die Vorlage innerhalb von 32 KiB und höchstens zwölf Matchern. Andere Protokolle, Skripte, externe Callbacks und lokale Dateizugriffe gehören nicht zu dieser Aufgabe. Gleichwertige Matcher-Anordnungen innerhalb dieses Umfangs sind willkommen.

Die Verifikation führt deine unveränderte Vorlage mit der nativen Nuclei-Engine gegen temporäre positive und negative Antwortbeispiele aus. Diese Beispiele enthalten veränderte Ports, Hostnamen, Werte, JSON-Anordnungen und Inhaltstyp-Parameter. Eine Datei, die lediglich validiert, immer oder niemals einen Treffer erzeugt, kann diese Funktionsprüfungen nicht bestehen.

Die Prüfung ausführen und die Übergabe prüfen

In diesem Schritt wendest du deine Vorlage auf die tatsächlich freigegebenen Websites an und bewahrst prüfbare Nachweise auf. Bleibe in Auditor. Dieselbe Datei lässt sich bei geänderter Zielliste wiederverwenden, weil ihr Pfad relativ zu BaseURL ist.

Führe die echte Bewertung aus. -l liefert die Basis-URLs, -o speichert Funde und -elog speichert Anfragefehler. -jsonl verwendet ein JSON-Objekt pro Fund; -ot lässt die kodierte Vorlage weg und behält die native Anfrage und Antwort bei.

nuclei -t diagnostics.yaml -l targets.txt -duc -ni -nc -jsonl -ot -o findings.jsonl -elog scan-errors.jsonl

Bevor du einen ausbleibenden Fund interpretierst, untersuche das native Anfragefehlerprotokoll:

cat scan-errors.jsonl

Bei diesem erfolgreichen Durchlauf sollte es leer sein. Ein Verbindungsfehler ist eine unvollständige Prüfung, selbst wenn Nuclei mit null endet oder No results found ausgibt. Behebe Schreib- oder Verbindungsfehler, bevor du eine Schlussfolgerung ziehst, und verwende bei einem erneuten Versuch neue Dateinamen, damit frühere Nachweise nicht mit dem neuen Durchlauf verwechselt werden. Die akzeptierten endgültigen Dateien sind findings.jsonl und scan-errors.jsonl; hast du unter neuen Namen erneut getestet, kopiere das erfolgreiche Paar mit cp in diese endgültigen Dateinamen. Beispielsweise kopiert cp retry-findings.jsonl findings.jsonl die erste Datei über die zweite; kopiere auch das passende Fehlerprotokoll.

Lies die Funde:

cat findings.jsonl

Erwarte eine Treffer-URL, die auf /studio/maintenance/diagnostics endet. Lies die eingebettete Antwort und ihr X-Audit-Event, nicht nur die Anzahl der Funde. Der Inhalt muss den Vertrag erfüllen, den du manuell geprüft hast.

Bestätige, warum zwei plausible Alternativen keinen Treffer ergaben:

curl -i http://workshop.test:8080/garden/maintenance/diagnostics

Dies ist öffentliches JSON mit visibility gleich public. Es handelt sich nicht um eine Offenlegung interner Diagnosedaten.

curl -i http://workshop.test:8080/members/maintenance/diagnostics

Erwarte HTTP 302 mit einem Location-Header, der auf die Anmeldung verweist. Deine Vorlage folgt ihm nicht und verwechselt die Anmeldeseite nicht mit einem Diagnoseergebnis. Die anderen Websites ohne Treffer sind das geschützte archive, die verschachtelte Dokumentation bei manual und die minimale Zustandsantwort bei status. Jede erhält weiterhin die freigegebene lesende Anfrage; ein fehlender Fund beschreibt nur die Bedingungen dieser Vorlage, nicht die Gesamtsicherheit der Website.

Liefere eigenständige reguläre Dateien ab, die auditor lesen kann. Deine Übergabe besteht aus der wiederverwendbaren diagnostics.yaml, der tatsächlichen findings.jsonl und der dazugehörigen scan-errors.jsonl. Behalte die Umfangsdateien daneben. Die Vorlage enthält keinen zielspezifischen Datenbankdateipfad, Anfragezähler, Hostnamen oder Port. Die Verifikation prüft die vorhandenen echten Nachweise, bevor sie isolierte Beispiele ausführt, und erhält deine Dateien. Ihre gewöhnlichen lesenden Erhaltungsprüfungen können Server-Protokolleinträge hinzufügen und Anfragezähler erhöhen; sie werden nicht zu Bewertungsnachweisen des Lernenden.

Die unabhängige Challenge gibt dir eine neue Liste von Bereitstellungen und Adressen. Wende denselben Antwortvertrag und denselben sorgfältigen Umgang mit Fehlern an und halte die öffentliche Workshop-Nutzung sowie den autorisierten Wartungszugriff verfügbar.

Zusammenfassung

Du hast eine native Nuclei-HTTP-Vorlage geschrieben, die Status, Inhaltstyp und normalisierte Diagnosefelder kombiniert. Du hast Unterschiede zwischen Antworten getestet, die Portabilität mit BaseURL erhalten und alle freigegebenen Websites bewertet, ohne Ausführungsfehler als negative Ergebnisse zu behandeln. Deine Übergabe besteht aus der tatsächlichen Vorlage, den Funden und dem passenden nativen Anfragefehlerprotokoll.