Introduction
L’équipe du studio a modifié la manière dont Sign out this browser traite les sessions. Mettre fin à toutes les sessions ferait échouer l’ancien cookie, mais interromprait également un autre navigateur que le membre souhaite toujours utiliser. L’acceptation doit couvrir à la fois le résultat de sécurité et le comportement normal promis.
Vous conserverez les requêtes originales du compte et de la réservation de Browser A dans Burp Repeater, établirez une session Browser B distincte pour le même membre et testerez les deux après la déconnexion de A. Les éléments à remettre combinent des preuves HTTP privées et une décision d’acceptation sans mot de passe. L’environnement est indépendant : aucun fichier, aucune session et aucun onglet Burp antérieurs ne sont repris.
Terminez d’abord Rejouer une requête de réservation après la déconnexion. Vous devez savoir démarrer le projet temporaire de Burp, laisser l’interception désactivée, envoyer des lignes d’historique vers Repeater, lire un statut HTTP et enregistrer un élément XML. Ce lab reprend le parcours opérationnel et ajoute une comparaison entre sessions indépendantes. Tous les comptes et toutes les réservations sont synthétiques. Prévoyez environ 60 minutes, lecture et erreurs courantes comprises ; il s’agit d’une estimation de l’auteur.
Établir l’accès normal à la réservation dans Browser A
Dans cette étape, vous allez établir le parcours normal de ce nouveau déploiement. Ouvrez Auditor et lisez l’identité, l’adresse et l’autorisation fournies :
cat scope.json
Utilisez uniquement http://members.test:8080/autumn, le nom d’utilisateur morgan et le mot de passe PaperDay!47. La réservation appartient à Morgan Reed : Printmaking, place P12. Préservez le périmètre fourni, la configuration, les données et les processus de la cible.
Si un espace de travail graphique affiche Disconnected, cliquez sur son bouton Reconnect en haut. Cela reconnecte la fenêtre existante en conservant ses cookies de navigateur, les requêtes Burp et la progression sur la cible.
Ouvrez Burp. Laissez Temporary project sélectionné, cliquez sur Next, laissez Use Burp defaults sélectionné et cliquez sur Start Burp. Si Burp Suite is out of date apparaît, cliquez sur OK pour continuer avec la version préparée pour la formation. Dans la fenêtre principale, choisissez Proxy → Intercept et assurez-vous que le bouton affiche Intercept is off. S’il affiche Intercept is on, cliquez dessus une fois pour que les requêtes normales ne soient pas mises en pause.
Passez à Browser A. Cliquez dans la barre d’adresse de Chromium, saisissez cette URL et appuyez sur Entrée :
http://members.test:8080/autumn/
Choisissez View my booking, saisissez morgan dans Username et PaperDay!47 dans Password, puis cliquez sur Sign in. Choisissez Never si Chromium propose d’enregistrer le mot de passe. Confirmez Morgan Reed, Printmaking et la place P12 sur Your next day of making, puis cliquez sur Download booking. Le véritable CSV contient ce membre, cet atelier et cette place.
Une faute de saisie dans les identifiants produit Sign-in unsuccessful ; utilisez try again et corrigez les valeurs fournies. En cas de chemin incorrect, revenez à l’URL de base exacte. Une erreur de connexion du navigateur n’est pas un refus HTTP : terminez l’assistant de Burp, vérifiez l’interception et l’adresse exacte, puis naviguez de nouveau. Fermer un onglet LabEx ne réinitialise pas le scénario.
Conserver les requêtes réussies de Browser A
Dans cette étape, vous allez préserver la session originale de Browser A avant d’introduire un autre navigateur. Passez à Burp, puis à Proxy → HTTP history. Trouvez la ligne GET /autumn/account pour members.test:8080, faites un clic droit dessus et choisissez Send to Repeater. Répétez pour GET /autumn/booking.csv. Si un filtre d’historique masque le CSV, ouvrez la barre de filtre et activez Show all.
Ouvrez l’onglet principal Repeater. Dans le premier onglet de requête, confirmez le chemin du compte et l’en-tête original Cookie: studio_session=..., puis cliquez sur Send. Lisez la réponse Raw : HTTP 200 avec la réservation de Morgan Reed. Sélectionnez le deuxième onglet de requête et cliquez sur Send. Il doit renvoyer HTTP 200 avec la véritable ligne CSV de réservation.
Les deux requêtes utilisent le même cookie de session original de Browser A. Gardez-les inchangées, y compris leur hôte, leurs chemins et leurs cookies. Les onglets numérotés de Repeater identifient les requêtes, tandis que les onglets LabEx Browser A et Browser B identifient des profils de navigateur indépendants. Changer d’onglet LabEx ne change pas la requête sélectionnée dans Repeater.
Ces réponses réussies constituent la référence initiale. Un cookie qui n’a jamais fonctionné ne permet pas de déterminer si la déconnexion a ensuite invalidé une véritable session. Si vous avez sélectionné la mauvaise ligne d’historique, envoyez le bon chemin vers Repeater et utilisez cet onglet de requête à la place ; identifiez-le par le chemin au lieu de deviner un numéro d’onglet.
Tester la limite de la session courante
Dans cette étape, vous allez vérifier que la déconnexion d’un navigateur ne met fin qu’à sa propre session. Un profil de navigateur indépendant possède son propre stockage de cookies. Un deuxième onglet dans Browser A partagerait le cookie de A et ne permettrait pas cette comparaison.
Passez à l’onglet LabEx Browser B. Dans sa barre d’adresse Chromium, accédez à :
http://members.test:8080/autumn/login
Connectez-vous en tant que même membre, morgan, avec PaperDay!47. Choisissez Never si l’enregistrement du mot de passe est proposé. Confirmez la réservation et cliquez sur Download booking. Laissez Browser B connecté. Ses requêtes réussies du compte et du téléchargement doivent avoir lieu avant la déconnexion de A.
Pour comparer directement les identités de session, passez à Burp → Proxy → HTTP history. Sélectionnez la requête /autumn/account la plus récente de B et examinez sa requête Raw. Sa valeur studio_session diffère de celle conservée dans les onglets Repeater originaux de A. Les deux sessions représentent Morgan Reed, mais constituent des états d’authentification distincts. Ne copiez aucun des cookies dans votre rapport et ne remplacez pas le cookie conservé de A par celui de B.
Passez à Browser A et cliquez sur Sign out this browser. La page de connexion apparaît. Passez ensuite à Burp → Repeater et cliquez sur Send pour la requête originale du compte de A. Attendez-vous à 401 Unauthorized et à Sign in required. Envoyez également la requête originale de réservation de A : attendez-vous à HTTP 401, sans CSV de réservation du membre. Gardez les deux cookies d’origine intacts ; une requête sans cookie ne testerait pas l’invalidation de l’ancienne session de A.
Lisez le Cookie inchangé dans le volet gauche et 401 Unauthorized avec Sign in required dans le volet droit. Il s’agit d’un refus de la session de A qui fonctionnait auparavant.
Passez maintenant à Browser B. Cliquez sur le bouton d’actualisation de Chromium à côté de sa barre d’adresse. Sa page de réservation doit toujours afficher celle de Morgan Reed. Cliquez de nouveau sur Download booking et confirmez un véritable téléchargement. Ces nouvelles requêtes établissent le maintien de l’accès ; une page laissée à l’écran sans actualisation pourrait être obsolète. Si B perdait également son accès, mettre fin à toutes les sessions violerait le contrat explicite this browser de ce cours, même si l’ancien cookie de A était rejeté. D’autres produits peuvent proposer intentionnellement une action séparée de déconnexion générale ; il s’agit d’un autre contrat.
Enfin, passez à Browser A, reconnectez-vous avec les identifiants fournis, consultez la réservation et cliquez sur Download booking. Une nouvelle session fonctionne toujours. Revenez à Burp sans modifier les requêtes Repeater originales de A. Leurs dernières réponses restent les deux réponses HTTP 401 obtenues après la déconnexion.
Vous pouvez accepter cette modification délimitée : l’ancienne session de A échoue sur les deux ressources protégées, la session indépendante de B déjà établie fonctionne toujours et une nouvelle connexion fonctionne. Cela ne permet pas d’établir tous les aspects de la sécurité des sessions.
Si vous avez accidentellement déconnecté B ou remplacé l’ancien cookie de A, établissez deux nouvelles sessions indépendantes et répétez la séquence complète : établissez les références des deux ressources dans les deux navigateurs, conservez les requêtes de A, déconnectez A, rejouez A, actualisez et téléchargez dans B, puis confirmez une nouvelle connexion dans A. Rouvrir un onglet ne crée pas à lui seul une session de substitution.
Préserver les preuves du test accepté
Dans cette étape, vous allez livrer des preuves privées et la décision d’acceptation étayée. Passez à Auditor, qui démarre dans /home/labex/project. Comme enseigné précédemment, umask 077 restreint les nouveaux fichiers dans ce shell, mkdir -p crée le répertoire de preuves et chmod 700 rend ce répertoire privé.
umask 077
mkdir -p evidence
chmod 700 evidence
Passez à Burp → Repeater. Sélectionnez la requête originale du compte de A et confirmez que sa dernière réponse est le HTTP 401 obtenu après la déconnexion. Faites un clic droit dans l’éditeur Request, sélectionnez Save item et saisissez ce File Name absolu :
/home/labex/project/evidence/account-after.xml
Laissez Base64-encode requests and responses cochée et cliquez sur Save. Fermez une notification de réussite avec OK si elle apparaît. Répétez pour la requête originale de réservation de A, dont la dernière réponse doit également être HTTP 401 :
/home/labex/project/evidence/booking-after.xml
Ces éléments XML contiennent le cookie d’origine de A. Base64 est un encodage, pas un chiffrement. Passez à Auditor et restreignez les fichiers à leur propriétaire :
chmod 600 evidence/account-after.xml evidence/booking-after.xml
ls -l evidence
Attendez-vous à -rw------- sur les deux fichiers. Utilisez le même format littéral de here-document que précédemment pour un rapport sans mot de passe. > remplace assessment.json ; le JSON final doit être seul sur sa ligne.
cat > assessment.json <<'JSON'
{
"decision": "accept",
"account_after_logout": 401,
"booking_after_logout": 401,
"independent_browser_preserved": true,
"fresh_sign_in_works": true
}
JSON
cat assessment.json
Livrez les paires XML originales et ce rapport, en gardant les mots de passe, les cookies et les requêtes brutes hors du rapport. Les faits existants du serveur étayent l’accès indépendant de B et la nouvelle connexion ; la vérification n’effectue pas les connexions, les déconnexions ou les requêtes de rejeu manquantes. Sa requête de vérification de la préservation de la page publique peut ajouter une entrée au journal d’accès, et les évaluations répétées préservent vos fichiers.
En cas de nom de fichier incorrect, exportez la même véritable réponse vers le bon chemin et réappliquez chmod 600. Si votre shell se trouve ailleurs, utilisez pwd pour le vérifier et cd /home/labex/project pour revenir. Gardez le site public normal et toutes les ressources cibles intacts.
Résumé
Vous avez testé une déconnexion corrigée du navigateur courant sur la page du compte et le téléchargement de réservation. L’ancien cookie a été rejeté, une session de navigateur distincte préexistante a conservé son accès et une nouvelle connexion fonctionnait toujours. Des paires XML Burp privées et une évaluation sans mot de passe préservent la décision d’acceptation étayée.
Le défi indépendant change le membre, l’adresse de déploiement et la réservation. Appliquez le même contrat complet et laissez les véritables réponses des deux ressources déterminer la décision.
