Introduction
Fieldnote prépare Northline Print Fair. Les exposants se connectent pour récupérer le kit de leur propre stand : heure d’arrivée, point de livraison et liste de matériel. Un premier test Hydra semble découvrir plusieurs accès utilisables. Certains de ces résultats sont en réalité des pages d’erreur. Votre mission consiste à distinguer une véritable authentification d’une réponse trompeuse, puis à récupérer le kit complet de l’exposant qui vous est attribué.
Vous devez seulement savoir saisir des commandes simples, reconnaître des chemins et changer d’onglet. Hydra et le portail local sont prêts. Les champs de formulaire, les conditions de correspondance et les cookies sont expliqués avant leur utilisation. Workstation est votre terminal ; Exhibitor Portal est le site web. Il s’agit de deux interfaces d’un même conteneur de formation isolé, et non de deux machines. Tous les comptes et toutes les données métier sont synthétiques. Testez uniquement le formulaire d’exercice déclaré et le compte attribué avec les candidats fournis. Ne modifiez ni le serveur, ni les comptes, ni les documents.
Les 55 minutes estimées comprennent la lecture et les erreurs courantes ; cette durée n’a pas été mesurée avec des débutants. Vous remettrez un argument de formulaire réutilisable, un résultat Hydra original et le kit du stand obtenu après authentification, plutôt qu’un rapport rédigé.
Voir ce qu’ouvre une vraie connexion
Dans cette étape, ouvrez un compte d’aperçu dont le fonctionnement est connu et reliez-le aux informations de son propre stand. Une requête HTTP réussie signifie que le serveur a envoyé une réponse ; une authentification réussie signifie qu’il a accepté une identité. Ce sont deux faits différents.
Ouvrez l’onglet Exhibitor Portal. Sélectionnez Start at the practice desk, puis Practice sign-in. Saisissez l’identifiant d’exposant preview et le mot de passe Preview24, puis sélectionnez Sign in. Le résultat indique Signed in as preview. Sélectionnez Open your workspace. Le stand est DEMO et la note d’emballage précise qu’il s’agit d’un document d’exercice. C’est le fonctionnement métier normal ; ce kit d’aperçu n’est pas votre livrable final. Sélectionnez Sign out, puis le lien de navigation Practice desk.
L’identifiant d’exposant et le stand montrent qu’il s’agit de l’aperçu ; la seule présence d’un bouton de téléchargement ne prouve pas que ce kit vous est attribué.
Passez à Workstation. Les commandes de ce laboratoire commencent dans /home/labex/project/login-review. L’interface entre automatiquement dans ce répertoire ; pwd affiche le répertoire actuel pour le vérifier :
pwd
Vous devez obtenir /home/labex/project/login-review. Si vous êtes ailleurs, cd permet de changer de répertoire :
cd /home/labex/project/login-review
Le formulaire d’exercice envoie une requête POST à /practice/login. Un POST transporte des champs nommés dans le corps de la requête. Ici, les noms sont username et password, séparés par &. curl envoie une requête depuis le terminal, indépendamment du navigateur. Dans la commande suivante, --data fournit les champs, -s masque l’indicateur de progression, -o enregistre le corps de la réponse et -w affiche le statut HTTP. Les guillemets simples gardent ensemble les espaces, & et %{http_code} pour curl, au lieu de les laisser interpréter par le shell.
Envoyez volontairement un mauvais mot de passe :
curl -s -o wrong.html -w 'HTTP %{http_code}
' --data 'username=preview&password=Wrong24' http://127.0.0.1:8080/practice/login
La sortie est HTTP 200. Cela signifie que l’application a renvoyé une page, pas que le mot de passe a fonctionné. wrong.html contient cette page. grep recherche du texte ; son option -o affiche uniquement le texte correspondant, ce qui évite de lire les balises HTML autour :
grep -o 'Incorrect password' wrong.html
Vous devez voir Incorrect password. Le même statut HTTP peut accompagner une véritable réussite ou un refus de connexion. Dans cette leçon, une simple faute de frappe dans un mot de passe est récupérable : corrigez la valeur et renvoyez-la. Une erreur de connexion réseau signifie que la requête n’a pas atteint le service ; vérifiez 127.0.0.1, le port 8080 et le chemin déclaré avant d’interpréter le résultat. Ne réinitialisez pas la VM pour corriger une faute de frappe.
Reproduire un résultat trompeur
Dans cette étape, vous exécuterez une règle de classification volontairement défectueuse sur quatre petites paires d’exercice. Il s’agit de la démonstration d’un mauvais test, pas d’un audit fiable.
Restez dans Workstation. cat affiche un fichier. La liste préparée contient des paires complètes username:password, à raison d’une par ligne :
cat practice-pairs.txt
preview:Wrong24
retired:Wrong24
offline:Wrong24
preview:Preview24
retired est un exemple synthétique de compte indisponible. offline est un exemple contrôlé d’erreur de service : le gestionnaire d’exercice renvoie HTTP 503 sans créer de session. Il ne s’agit ni d’une véritable panne en amont ni d’un exposant réel. La dernière paire est l’accès d’aperçu connu pour fonctionner. Conservez ce petit ensemble autorisé ; ne l’étendez pas à des combinaisons arbitraires d’utilisateurs et de mots de passe.
Le module http-post-form de Hydra envoie chaque paire au formulaire. Son argument comporte trois parties séparées par des deux-points : le chemin POST, les champs et une condition de réponse. ^USER^ et ^PASS^ sont des espaces réservés de Hydra. F= signifie « considérer comme un échec toute réponse contenant ce motif ». Une autre réponse peut alors être classée comme une réussite. Cette commande ne reconnaît délibérément que Incorrect password et ne couvre pas les autres types d’échec.
Les options sont -I pour ignorer une ancienne demande de reprise dans cet espace, -C pour les candidats appariés, -s pour le port, -t 1 pour un seul processus de travail, -o pour le nom du fichier de résultats et -b json pour le format JSON. Le dernier argument, entre guillemets, reste un argument unique malgré ses espaces et &.
hydra -I -C practice-pairs.txt -s 8080 -t 1 -o misleading.json -b json 127.0.0.1 http-post-form '/practice/login:username=^USER^&password=^PASS^:F=Incorrect password'
Pour lire du JSON sans écrire de programme, utilisez le formateur intégré json.tool de Python. python3 -m exécute un module installé :
python3 -m json.tool misleading.json
Lisez la liste results. La paire d’aperçu connue apparaît, mais une paire liée au compte indisponible ou à l’erreur de service peut aussi apparaître. Un résultat est une affirmation produite par la condition, pas la preuve d’un espace réellement authentifié. Le champ supérieur success: true décrit l’exécution de Hydra, pas la validité de chaque mot de passe annoncé. N’utilisez pas ce fichier trompeur comme résultat final d’audit.
Si Hydra signale une erreur de syntaxe ou de connexion réseau, comparez l’argument complet entre guillemets et le port à la commande ci-dessus, corrigez la faute et relancez ce test d’exercice limité. Une connexion réseau échouée n’établit ni un mot de passe valide ni un résultat négatif valable.
Calibrer avec des réponses connues
Dans cette étape, enregistrez une condition réutilisable qui accepte une véritable réussite et rejette les trois cas connus qui n’en sont pas. Restez dans Workstation. Examinez d’abord les autres réponses avec le même format de requête.
La requête du compte indisponible renvoie volontairement HTTP 200 :
curl -s -o retired.html -w 'HTTP %{http_code}
' --data 'username=retired&password=Wrong24' http://127.0.0.1:8080/practice/login
grep -o 'Sign-in unavailable' retired.html
La requête d’erreur de service contrôlée renvoie volontairement HTTP 503. Il n’existe aucune session valide, même si la page ne contient pas Incorrect password :
curl -s -o offline.html -w 'HTTP %{http_code}
' --data 'username=offline&password=Wrong24' http://127.0.0.1:8080/practice/login
grep -o 'Service unavailable' offline.html
Obtenez maintenant la réponse positive connue. Cette requête curl dispose de sa propre session, distincte de celle du navigateur :
curl -s -o preview.html --data 'username=preview&password=Preview24' http://127.0.0.1:8080/practice/login
grep -o 'Signed in as preview' preview.html
Signed in as identifie ici le résultat authentifié. Welcome apparaît aussi sur les pages d’échec et ne permet donc pas de distinguer l’authentification. S= de Hydra sélectionne un motif positif : la réponse doit le contenir pour être comptée comme une réussite. Consultez l’aide du module installé avec -U ; elle explique le chemin, les champs et la syntaxe de la condition :
hydra -U http-post-form
Enregistrez l’argument d’exercice complet. cat > calibration.txt écrit du texte dans un fichier ; > remplace le fichier s’il existe déjà. Un here-document fournit plusieurs lignes jusqu’à la ligne finale EOF. Entourer 'EOF' d’apostrophes conserve son contenu littéral. Placez le marqueur de fin seul sur sa ligne, sans espaces devant :
cat > calibration.txt <<'EOF'
/practice/login:username=^USER^&password=^PASS^:S=Signed in as
EOF
Une variable de shell conserve du texte à réutiliser dans ce terminal. $(cat calibration.txt) lit le fichier ; form= stocke le résultat, sans espaces autour de =. Plus tard, les guillemets dans "$form" gardent les espaces à l’intérieur d’un seul argument. Cette variable appartient à la session de terminal actuelle ; après une reconnexion, exécutez de nouveau l’affectation.
form=$(cat calibration.txt)
hydra -I -C practice-pairs.txt -s 8080 -t 1 -o calibration.json -b json 127.0.0.1 http-post-form "$form"
python3 -m json.tool calibration.json
Seule la paire preview:Preview24 doit être annoncée. Le mauvais mot de passe, le compte indisponible et HTTP 503 ne sont pas authentifiés. Le calibrage doit aussi inclure le positif connu : une condition qui rejette tout est également incorrecte. Un motif d’échec suffisamment large peut être équivalent à ce motif positif ; aucune écriture particulière de S= n’est imposée. L’argument enregistré est testé indépendamment avec chaque réponse connue, et n’est pas accepté simplement parce qu’il contient un mot-clé.
Récupérer le kit de l’exposant attribué
Dans cette étape, appliquez la méthode calibrée à l’exposant attribué, puis authentifiez-vous indépendamment et récupérez son véritable document métier.
Ouvrez Exhibitor Portal, puis Exhibitor sign-in et View your review assignment. Le compte attribué est papertrail ; son chemin POST est /signin. Seuls les trois mots de passe de candidates.txt sont autorisés. Le compte d’exercice appartient à un autre formulaire. Passez à Workstation et lisez les candidats :
cat candidates.txt
Enregistrez un second argument réutilisable avec le chemin attribué, les mêmes champs et la même condition :
cat > form.txt <<'EOF'
/signin:username=^USER^&password=^PASS^:S=Signed in as
EOF
form=$(cat form.txt)
Contrairement à -C, -l papertrail fournit un nom d’utilisateur fixe et -P candidates.txt ses mots de passe autorisés. Exécutez ce petit audit attribué et enregistrez un nouveau résultat JSON original :
hydra -I -l papertrail -P candidates.txt -s 8080 -t 1 -o findings.json -b json 127.0.0.1 http-post-form "$form"
python3 -m json.tool findings.json
L’unique résultat véritable identifie papertrail avec le mot de passe InkPaper7. Cette conclusion s’applique uniquement au compte et à l’ensemble de candidats déclarés ; elle n’affirme pas que le site entier est sûr.
Passez à Exhibitor Portal. Sélectionnez Exhibitor sign-in, saisissez la paire découverte et sélectionnez Sign in, puis Open your workspace. Vérifiez papertrail, le stand N-14, l’arrivée 09:15 et North loading door. Sélectionnez Download booth kit pour obtenir le véritable téléchargement du navigateur. Ce fichier se trouve dans l’emplacement de téléchargement du navigateur ; il n’apparaît pas automatiquement dans le conteneur de formation.
Vérifiez les champs exposant et stand au-dessus de la note d’emballage avant d’utiliser ce téléchargement.
Revenez dans Workstation pour enregistrer la copie requise dans la VM. Un cookie est un identifiant de session émis par le serveur. -c exhibitor.cookies enregistre les cookies reçus lors de cette connexion depuis le terminal. Ce fichier de cookies appartient à curl ; le navigateur et Hydra ne le partagent pas automatiquement. Le corps de la réponse est enregistré dans signin.html :
curl -s -c exhibitor.cookies -o signin.html --data 'username=papertrail&password=InkPaper7' http://127.0.0.1:8080/signin
Lisez le téléchargement authentifié avec le même fichier. -b envoie ses cookies. -f fait retourner un statut non nul en cas de refus HTTP, au lieu d’enregistrer silencieusement une page d’erreur comme un kit :
curl -f -s -b exhibitor.cookies http://127.0.0.1:8080/kit.json -o booth-kit.json
Un 403 ou le code de sortie 22 de curl signifie que ce client ne possède aucune session acceptée. Vérifiez l’utilisateur, le mot de passe, le chemin du formulaire et le nom du fichier de cookies, relancez la commande de connexion, puis le téléchargement. Un 404 signifie que le chemin est erroné. Ces erreurs sont récupérables ; ne remplacez pas le kit par une copie du fichier d’aperçu.
python3 -m json.tool booth-kit.json
Comparez l’exposant, le stand et l’heure d’arrivée à la page. Le kit complet comprend aussi trois présentoirs à imprimés, deux nappes et la note concernant les pochettes numérotées des imprimés. L’existence du fichier ou un nom d’exposant concordant ne suffit pas à prouver que le document entier est correct.
Enfin, ouvrez Visitor guide dans Exhibitor Portal. Les informations publiques d’arrivée doivent toujours être accessibles. Vous n’avez modifié que vos fichiers et vos sessions, en préservant le service, les comptes et les données métier. Les livrables finaux sont form.txt, findings.json et booth-kit.json dans l’espace de travail. Les vérifications observent les faits de connexion et de téléchargement existants et testent l’argument enregistré dans un service distinct et jetable ; elles ne complètent pas les actions manquantes sur le portail réel.
Résumé
Vous avez comparé des espaces réellement authentifiés aux réponses de mauvais mot de passe, de compte indisponible et d’erreur de service. Vous avez reproduit un faux positif de Hydra, calibré une condition de formulaire réutilisable avec des exemples positifs et négatifs, puis vérifié l’identité attribuée et récupéré son kit complet avec une session de cookies distincte. HTTP 200, un indicateur de bonne exécution ou un message Welcome générique ne prouvent pas à eux seuls une authentification.
