Écrire une vérification Nuclei portable des diagnostics

Introduction

Un scanner fondé uniquement sur le statut a détecté à la fois une véritable réponse de diagnostic et un exemple de documentation. Construisez maintenant une vérification qui pose la question voulue : une requête non authentifiée a-t-elle reçu l’objet de diagnostic interne actif de cette application ?

Vous allez créer un modèle YAML natif pour Nuclei, tester ses conditions de réponse et scanner six sites Fieldwork Studio approuvés. Votre modèle réutilisable et vos résultats réels constituent les éléments à remettre. L’environnement est indépendant du lab précédent ; aucun fichier ni processus n’est repris.

Terminez d’abord Confirmer l’exposition des diagnostics avec des réponses réelles, ou soyez à l’aise avec la lecture d’un statut HTTP, d’en-têtes de type de contenu, d’un petit objet JSON et de résultats Nuclei au format JSONL. Ce lab explique son YAML et ses expressions de correspondance. Toute la configuration des cibles est synthétique. Utilisez uniquement le périmètre en lecture seule fourni, préservez les pages publiques des ateliers et leurs programmes, et prévoyez environ 65 minutes, lecture et erreurs courantes comprises ; il s’agit d’une estimation de l’auteur.

Établir le contrat de réponse de la vérification

Dans cette étape, vous allez établir le service normal et la question précise à laquelle votre modèle doit répondre. Ouvrez Workshops, parcourez les sessions et utilisez Get the workshop schedule pour télécharger le véritable fichier fieldwork-schedule.csv. Printmaking et Bookbinding doivent rester disponibles pendant toute votre évaluation.

Les deux cartes des ateliers montrent le service public à préserver. Le lien vert Get the workshop schedule télécharge son véritable programme.

Passez à Auditor. Il ouvre le conteneur d’audit Kali dans /home/labex/project. Lisez le périmètre et les URL de base approuvées :

cat scope.txt

cat targets.txt

Les six sites sont studio, archive, manual, garden, status et members, sous http://workshop.test:8080/. Testez uniquement ces URL, à l’aide de requêtes HTTP GET en lecture seule. Ne modifiez ni les sites cibles ni les fichiers de périmètre fournis.

Revenez sur une réponse de diagnostic active. Comme précédemment, curl -i inclut les en-têtes de réponse :

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

Un résultat doit combiner HTTP 200, un type de contenu JSON et l’objet de diagnostic interne de l’application au premier niveau. Ses quatre champs scalaires identifient le service et la visibilité, un chemin absolu de fichier de base de données et un nombre de requêtes entier non négatif sans guillemets. Le chemin du fichier et le compteur peuvent changer. L’ordre des clés et les espaces ne changent pas le sens. Un exemple de documentation imbriqué n’est pas l’objet actif.

Votre vérification cible le format de réponse déclaré de cette petite application. Elle n’établit pas qu’un point de terminaison JSON quelconque est vulnérable ni qu’un site ne présente aucun autre problème. En particulier, une page publique, une synthèse JSON publique, une réponse d’état de santé, un refus HTTP ou une redirection vers la connexion ne constituent pas la preuve d’exposition requise.

Si votre répertoire change, utilisez pwd pour le vérifier et cd /home/labex/project pour revenir avant de lire ou de créer des fichiers à partir de noms relatifs. Conservez votre travail lors d’une reconnexion ; ouvrir un terminal ne reconstruit pas le scénario.

Construire les critères natifs de réponse

Dans cette étape, vous allez écrire un modèle réutilisable au lieu de vous appuyer sur une correspondance HTTP 200. Restez dans Auditor.

Un modèle Nuclei possède un id, des informations descriptives info et une section de protocole telle que http. L’indentation regroupe les champs YAML imbriqués, tandis qu’un tiret commence un élément de liste. Utilisez des espaces, pas des tabulations. method: GET sélectionne une requête en lecture seule. {{BaseURL}} provient de la cible transmise à Nuclei : le modèle n’intègre donc pas de nom d’hôte, de port ou de préfixe de site particulier. redirects: false laisse une redirection vers la connexion visible en tant que redirection.

Un critère de correspondance (matcher) est une condition appliquée à une réponse. Ce modèle exige les trois groupes de critères suivants :

matchers-condition: and combine ces groupes. Sans ce paramètre, la relation OU par défaut pourrait de nouveau permettre au seul statut HTTP 200 de produire un résultat. À l’intérieur du critère DSL, condition: and exige de même toutes les expressions de corps listées.

DSL signifie langage spécifique à un domaine : ici, de courtes expressions qui examinent une réponse. body est le texte de la réponse. json_minify(body) analyse et compacte du JSON valide, en supprimant les espaces non significatifs sans dépendre de l’ordre des clés. contains(text, fragment) recherche un fragment littéral. Normaliser d’abord permet à un champ écrit "visibility" : "internal" de satisfaire la même condition que "visibility":"internal".

regex(pattern, text) applique une expression régulière. Les expressions ci-dessous utilisent un petit ensemble de symboles :

• /[A-Za-z0-9._/-]+ exige une barre oblique initiale suivie d’un ou plusieurs caractères de chemin : lettres, chiffres, points, traits de soulignement, barres obliques ou traits d’union. Il accepte des chemins absolus différents, y compris des lettres majuscules.
• [0-9]+[,}] exige des chiffres immédiatement suivis d’une virgule ou d’une accolade fermante. Cela évite de prendre un compteur entre guillemets, une valeur négative ou le début d’un nombre décimal pour le compteur entier attendu.
• ^\{[^{}]*\}$ exige une seule paire d’accolades extérieures et aucune accolade imbriquée, afin de correspondre au format de diagnostic plat à quatre champs de ce cours, plutôt qu’à un objet dans un exemple de documentation.

L’expression d’en-tête utilise (?im) pour une recherche par ligne insensible à la casse ; \s* autorise les espaces. Son groupe facultatif (?: ... )? accepte des paramètres tels que ; charset=utf-8. Vous pouvez copier cette expression comme vérification complète du type de contenu JSON ; vous n’avez pas besoin de construire un analyseur MIME généraliste.

Dans le YAML ci-dessous, >- introduit une valeur textuelle sur la ligne indentée suivante. Il préserve les guillemets et les barres obliques inverses de l’expression sans échappement supplémentaire des guillemets YAML. Les guillemets simples de chaque expression entourent du texte littéral ; les guillemets doubles à l’intérieur de ce texte sont la ponctuation des champs JSON à rechercher.

Créez diagnostics.yaml. Comme dans le lab précédent, > remplace ce fichier et le délimiteur du here-document entre guillemets copie le bloc littéralement. Le YAML final doit être seul sur sa ligne.

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

Demandez au véritable moteur de valider le modèle. -validate vérifie la syntaxe de modèle de Nuclei ; il n’établit pas que la détection est correcte. -t sélectionne votre fichier, -duc désactive les recherches de mises à jour, -ni désactive les rappels Interactsh externes et -nc supprime les codes de couleur du terminal.

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

Attendez-vous à All templates validated successfully. Si Nuclei signale une erreur YAML ou d’expression, comparez l’indentation, les guillemets et les barres obliques inverses au bloc complet, puis répétez le here-document corrigé et la commande de validation. Préservez targets.txt et scope.txt.

Le cours accepte le sous-ensemble enseigné suivant : une définition HTTP GET au chemin approuvé {{BaseURL}}/maintenance/diagnostics, aucune redirection et des critères de statut, de mot, d’expression régulière ou DSL portant uniquement sur la réponse. Les fonctions DSL autorisées sont contains, contains_all, contains_any, regex, json_minify, len, tolower, toupper, starts_with et ends_with, appliquées à body, all_headers, status_code ou content_length. Utilisez uniquement id, info et http au premier niveau, et les champs de requête method, path, redirects, matchers-condition et matchers. Limitez le modèle à 32 KiB et à douze critères de correspondance au maximum. Les autres protocoles, les scripts, les rappels externes et l’accès aux fichiers locaux sortent du cadre de cette tâche. Les agencements équivalents de critères dans ce périmètre sont acceptés.

La vérification exécute votre modèle inchangé avec le moteur Nuclei natif sur des exemples de réponses positifs et négatifs jetables. Ces exemples comprennent des ports, des noms d’hôte, des valeurs, une disposition JSON et des paramètres de type de contenu différents. Un fichier qui se contente d’être syntaxiquement valide, qui correspond toujours ou qui ne correspond jamais ne peut pas réussir ces vérifications fonctionnelles.

Exécuter la vérification et examiner les éléments à remettre

Dans cette étape, vous allez appliquer votre modèle aux véritables sites approuvés et conserver des preuves qui pourront être examinées. Restez dans Auditor. Le même fichier peut être réutilisé lorsque la liste des cibles change, car son chemin est relatif à BaseURL.

Lancez l’évaluation réelle. -l fournit les URL de base, -o enregistre les résultats et -elog enregistre les erreurs de requête. -jsonl utilise un objet JSON par résultat ; -ot omet le modèle encodé tout en conservant la requête et la réponse natives.

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

Avant d’interpréter l’absence d’un résultat, examinez le journal natif des erreurs de requête :

cat scan-errors.jsonl

Il doit être vide pour cette exécution réussie. Une erreur de connexion signifie que la vérification est incomplète, même si Nuclei se termine avec un code zéro ou affiche No results found. Corrigez les erreurs d’orthographe ou les problèmes de connexion avant de conclure, et utilisez de nouveaux noms de fichiers lors d’une nouvelle tentative pour ne pas confondre les preuves précédentes avec la nouvelle exécution. Les fichiers finaux acceptés sont findings.jsonl et scan-errors.jsonl ; si vous avez recommencé sous de nouveaux noms, utilisez cp pour copier la paire réussie vers ces noms finaux. Par exemple, cp retry-findings.jsonl findings.jsonl copie le premier fichier en remplaçant le second ; copiez également le journal d’erreurs correspondant.

Lisez les résultats :

cat findings.jsonl

Attendez-vous à une seule URL correspondante se terminant par /studio/maintenance/diagnostics. Lisez la réponse intégrée et son X-Audit-Event, pas seulement le nombre de résultats. Le corps doit satisfaire le contrat que vous avez vérifié manuellement.

Confirmez pourquoi deux autres possibilités plausibles n’ont pas correspondu :

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

Il s’agit de JSON public dont visibility vaut public. Ce n’est pas une exposition de diagnostics internes.

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

Attendez-vous à HTTP 302 avec un Location pointant vers la connexion. Votre modèle ne suit pas cette redirection et ne prend pas la page de connexion pour un résultat de diagnostic. Les autres sites sans correspondance sont archive, protégé, la documentation imbriquée de manual et la réponse minimale d’état de santé de status. Chacun reçoit malgré tout la requête en lecture seule approuvée ; l’absence de résultat décrit uniquement les conditions de ce modèle, pas la sécurité globale du site.

Livrez des fichiers ordinaires autonomes que auditor peut lire. Les éléments à remettre sont le modèle réutilisable diagnostics.yaml, les résultats réels findings.jsonl et le journal scan-errors.jsonl correspondant. Conservez les fichiers de périmètre à côté. Le modèle ne contient aucun chemin de fichier de base de données, compteur de requêtes, nom d’hôte ou port propre à une cible. La vérification examine les preuves réelles avant d’exécuter les exemples isolés et préserve vos fichiers. Ses requêtes ordinaires en lecture seule destinées à vérifier la préservation peuvent ajouter des entrées au journal du serveur et augmenter les compteurs de requêtes ; elles ne deviennent pas des preuves d’évaluation de l’apprenant.

Le défi indépendant vous fournit une nouvelle liste de déploiements et de nouvelles adresses. Appliquez le même contrat de réponse et la même rigueur face aux erreurs, tout en préservant l’utilisation publique des ateliers et l’accès de maintenance autorisé.

Résumé

Vous avez écrit un modèle HTTP natif pour Nuclei qui combine le statut, le type de contenu et des champs de diagnostic normalisés. Vous avez testé les différences entre les réponses, préservé la portabilité de BaseURL et évalué tous les sites approuvés sans traiter un échec d’exécution comme un résultat négatif. Les éléments à remettre sont le modèle réel, les résultats et le journal natif correspondant des erreurs de requête.