Introduction
Fieldwork Studio propose des ateliers d’artisanat ouverts au public. Leur programme doit être facile à consulter et à télécharger, tandis que les diagnostics de maintenance doivent exiger une autorisation. Votre tâche consiste à confirmer quelles réponses exposent réellement les données de diagnostic internes de cette application.
Utilisez d’abord le site dans des conditions normales. Comparez ensuite trois réponses réelles et exécutez une vérification Nuclei de départ volontairement trop large. Vous terminerez par des conclusions reliées aux réponses que vous avez examinées, au lieu de considérer chaque résultat du scanner comme un problème confirmé. Toutes les configurations et les identités sont synthétiques ; les requêtes HTTP et l’exécution du scanner sont réelles.
Il vous suffit de savoir saisir des commandes élémentaires dans un terminal et de comprendre les chemins. Ce lab explique HTTP, JSON et les sorties du scanner au fur et à mesure de leur apparition. L’auditeur Kali et la cible sont des conteneurs isolés qui partagent le noyau d’une même VM. Testez uniquement le périmètre fourni, limitez-vous aux requêtes en lecture seule et préservez le site des ateliers ainsi que son programme. Prévoyez environ 50 minutes, lecture et erreurs courantes comprises ; il s’agit d’une estimation de l’auteur.
Utiliser le programme public des ateliers
Dans cette étape, vous allez établir ce que l’accès public normal doit préserver. Ouvrez Workshops. La page présente les ateliers d’artisanat de Fieldwork Studio. Suivez le lien Get the workshop schedule pour télécharger fieldwork-schedule.csv. Ce fichier contient le nom, l’horaire et la salle des ateliers Printmaking et Bookbinding. L’accès public à ces informations est intentionnel.
Les deux cartes des sessions et le lien vert du programme constituent le service public normal. Préservez leurs véritables informations sur les ateliers pendant l’évaluation des diagnostics.
Passez à Auditor, le terminal Kali. Il démarre dans /home/labex/project. L’entrée du navigateur et ce terminal accèdent au même service d’ateliers ; ils ne représentent pas des machines cibles différentes.
cat affiche un fichier texte. Lisez le périmètre autorisé avant d’envoyer des vérifications de sécurité :
cat scope.txt
Seules les requêtes HTTP GET en lecture seule vers les URL de base de targets.txt sont autorisées. Une URL de base identifie un site ; la route de diagnostic s’y ajoute. Affichez la liste :
cat targets.txt
Vous devriez voir studio, archive et manual sous http://workshop.test:8080/. Le port 8080 identifie le service de ce cours. Préservez tous les sites, leur configuration et les données des ateliers. Vous évaluez l’accès, sans modifier l’application.
Si un chemin de fichier relatif ne fonctionne pas, utilisez pwd pour afficher votre répertoire courant, puis revenez avec :
cd /home/labex/project
Fermer Auditor ou s’y reconnecter ne recrée pas les sites. Vos fichiers restent dans cet espace de travail.
Lire les réponses avant de décider
Dans cette étape, vous allez comparer le point de terminaison de diagnostic de chaque site approuvé. Restez dans Auditor. HTTP est le protocole de requêtes et de réponses utilisé par ce site. curl envoie une requête et affiche le corps de la réponse. Son option -i affiche également les en-têtes de réponse, dont le statut et le type de contenu.
curl -i http://workshop.test:8080/studio/maintenance/diagnostics
La réponse commence par HTTP/1.0 200 OK. Cela signifie que le serveur a renvoyé la ressource demandée avec succès ; ce statut ne suffit pas à établir un problème de sécurité. Content-Type: application/json; charset=utf-8 indique que le corps contient du JSON encodé en texte UTF-8. JSON représente des valeurs nommées entre accolades. Des guillemets doubles entourent les noms et les valeurs textuelles ; une valeur numérique n’est pas entre guillemets.
L’objet plat contient service, visibility, database_file et request_count. Pour cette application, service vaut workshop-portal, visibility vaut internal, le fichier de base de données est un chemin absolu et le compteur de requêtes est un entier non négatif. Le chemin du fichier provient de la configuration du site en cours d’exécution : sa page publique d’ateliers et son téléchargement CSV lisent cette véritable base de données SQLite. SQLite stocke une petite base de données dans un fichier. Le compteur change au fil des requêtes. Cette combinaison constitue le contrat de diagnostic publié dans scope.txt. Ce n’est pas une définition universelle d’une vulnérabilité.
Une requête non authentifiée a reçu ces valeurs internes. Notez son en-tête X-Audit-Event : le serveur attribue un identifiant différent à chaque réponse réelle. Consignez cet identifiant dans un endroit privé pour l’évaluation finale. Vous pourrez référencer cette preuve sans recopier les valeurs internes dans votre synthèse.
Comparez le deuxième site :
curl -i http://workshop.test:8080/archive/maintenance/diagnostics
Attendez-vous à 401 Unauthorized et à une explication indiquant qu’un identifiant de maintenance est requis. Ce refus est intentionnel. Vous ne disposez d’aucun identifiant dans le périmètre autorisé et ne devez pas essayer de contourner cette protection. curl -i peut se terminer normalement en affichant HTTP 401 : recevoir correctement un refus est différent d’obtenir une autorisation.
Examinez maintenant le troisième site :
curl -i http://workshop.test:8080/manual/maintenance/diagnostics
Il renvoie HTTP 200 et du JSON, mais les champs de diagnostic sont imbriqués dans un objet example. Ils documentent un format de réponse ; ils ne constituent pas l’objet de diagnostic actif au premier niveau de ce site. Comparez la structure et le sens, plutôt que de rechercher simplement le mot internal. Conservez également l’identifiant d’événement de cette réponse.
Si vous voyez 404, comparez soigneusement l’URL avec la route fournie et répétez la requête corrigée. Could not resolve host ou Failed to connect signifie que la requête n’a pas obtenu la réponse prévue ; elle ne permet pas de conclure à l’absence ou à la présence d’une exposition. Vérifiez l’orthographe ainsi que le nom d’hôte et le port exacts du cours. Ne remplacez pas la cible par un site Web public.
Examiner un résultat Nuclei trop large
Dans cette étape, vous allez voir comment une vérification peut s’exécuter correctement tout en formulant une conclusion trop large. Restez dans Auditor. Nuclei est un scanner piloté par des modèles : un modèle décrit les requêtes et les conditions de réponse qui produisent des résultats. Un résultat signifie que ces conditions ont été satisfaites ; vous devez encore juger si elles établissent le problème que vous souhaitiez vérifier.
Lisez le modèle de départ préparé :
cat too-broad.yaml
YAML utilise l’indentation pour regrouper les paramètres. Ce modèle de départ envoie un GET vers la route de diagnostic de chaque URL de base, puis ne recherche que le statut HTTP 200. L’espace réservé {{BaseURL}} est remplacé par l’URL de base approuvée courante. Le modèle n’examine pas la signification de l’objet de diagnostic.
Exécutez le modèle de départ sur la liste fournie. -t sélectionne un modèle local ; -l lit la liste des cibles ; -o enregistre les résultats ; et -elog enregistre les erreurs de requête. -jsonl écrit un résultat JSON par ligne, et -ot omet le modèle encodé dans cette sortie. Les options de préparation -duc et -ni désactivent les recherches de mises à jour et les rappels Interactsh externes. Notre modèle n’a besoin ni des unes ni des autres. Conservez ces options pour cet exercice isolé.
nuclei -t too-broad.yaml -l targets.txt -duc -ni -nc -jsonl -ot -o broad-findings.jsonl -elog broad-errors.jsonl
-nc supprime les codes de couleur du terminal. Cette commande effectue de véritables requêtes en lecture seule. Attendez-vous à des résultats pour studio et manual, car les deux ont renvoyé 200. La route protégée archive ne correspond pas. Un scan qui n’affiche aucun résultat ne constitue pas automatiquement une vérification négative achevée.
Lisez le journal natif des erreurs de requête avant de juger les résultats :
cat broad-errors.jsonl
Un journal vide signifie qu’aucune erreur de requête n’a été enregistrée pendant cette exécution. Un échec de connexion peut tout de même laisser le code de sortie du processus Nuclei à zéro : ni ce code ni un fichier de résultats vide ne suffisent donc à eux seuls. Si le journal contient une erreur, corrigez le problème de cible ou de connexion avant de conclure. Conservez la preuve de l’erreur initiale ; utilisez un nouveau nom de fichier de sortie lors d’une nouvelle tentative.
Examinez les résultats :
cat broad-findings.jsonl
Chaque ligne contient une URL matched-at et les preuves de la requête et de la réponse. Comparez le résultat de manual à l’exemple de documentation imbriqué que vous avez déjà lu. Il s’agit d’un faux positif pour la question d’exposition des diagnostics que vous vouliez poser, même si le critère de statut du modèle de départ a fonctionné tel qu’il était écrit. La réponse de studio satisfait bien les conditions d’exposition définies.
Ces réponses synthétiques ne contiennent aucun véritable secret. Lors d’une évaluation réelle, les résultats bruts peuvent contenir des éléments sensibles et doivent être traités de manière privée. Ne les téléversez pas vers un scanner externe et ne les collez pas dans un rapport public.
Enregistrer une évaluation reliée aux preuves
Dans cette étape, vous allez distinguer votre conclusion de la correspondance trop large du scanner. Restez dans Auditor. Créez assessment.json avec une entrée par site. Chaque entrée consigne l’événement de réponse réel que vous avez examiné et votre conclusion. Utilisez exposed, access-denied et documentation-example pour les trois résultats étudiés ci-dessus.
Le bloc suivant est un here-document shell complet. cat > assessment.json écrit un fichier ; > remplace son contenu. <<'JSON' demande au shell de copier littéralement le texte qui suit jusqu’à la ligne contenant uniquement JSON. Le délimiteur entre guillemets empêche les expansions du shell dans le texte. Remplacez chaque valeur REPLACE_... par un véritable X-Audit-Event provenant de la réponse de diagnostic du site concerné avant d’exécuter le bloc. Conservez les guillemets doubles et les virgules JSON.
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
Si vous n’avez pas conservé un identifiant, répétez la requête curl -i de ce site à l’étape 2 et utilisez son nouvel identifiant. Répéter une lecture crée une autre réponse réelle et peut augmenter request_count ; cela ne répare ni ne modifie la politique d’accès du site.
Affichez le fichier enregistré :
cat assessment.json
Si un guillemet, une virgule ou une valeur d’événement est incorrect, répétez le here-document complet après correction. Ne recopiez pas littéralement les valeurs de remplacement. Livrez assessment.json sous forme de fichier ordinaire lisible dans cet espace de travail. La vérification compare vos conclusions aux réponses existantes ; elle ne génère pas les requêtes d’évaluation manquantes. Elle ne vous demande pas non plus de copier l’hôte de diagnostic ou le corps brut dans cette courte synthèse.
Votre résultat confirme l’exposition sur studio, observe un véritable refus sur archive et explique la correspondance trompeuse de documentation sur manual. Il n’affirme pas que toutes les autres routes ou vulnérabilités ont été testées. Le prochain lab guidé démarre un nouveau scénario et vous apprend à remplacer le critère trop large par une vérification Nuclei native et portable.
Résumé
Vous avez utilisé le programme public des ateliers, examiné les statuts HTTP et la structure JSON, puis confirmé une exposition de diagnostics internes. Vous avez exécuté une véritable vérification Nuclei de départ et expliqué son faux positif lié à la documentation. Votre évaluation relie chaque conclusion à une réponse existante tout en préservant l’accès public normal.
