Introduction
Les membres de Fieldwork Studio peuvent consulter un atelier réservé et télécharger leur confirmation de réservation. L’équipe a ajouté Sign out this browser. Le retour à la page de connexion semble convaincant, mais il ne permet pas de savoir si une session capturée auparavant fonctionne encore.
Vous utiliserez Burp Suite Community Edition dans Kali comme proxy HTTP et son outil Repeater pour conserver les requêtes originales et tester les deux ressources protégées après la déconnexion. Vous livrerez des preuves privées de requêtes et de réponses ainsi qu’une courte décision d’acceptation sans mot de passe. Vous évaluez l’application ; vous ne réparez pas son serveur.
Seules la saisie de commandes élémentaires dans un terminal et la navigation entre les onglets sont supposées acquises. Ce lab présente les réponses HTTP, les cookies et les commandes de Burp. Toutes les identités et les réservations sont synthétiques, et l’environnement fourni est isolé. Utilisez uniquement le compte et la cible du cours qui vous sont fournis. Prévoyez environ 65 minutes, lecture et erreurs courantes comprises ; il s’agit d’une estimation de l’auteur, pas d’une mesure issue d’un essai avec des débutants.
Établir une véritable réservation de membre
Dans cette étape, vous allez établir l’utilisation normale avant de tester la déconnexion. Ouvrez Auditor, le terminal Kali. Il démarre dans /home/labex/project. cat affiche un fichier texte. Lisez l’autorisation, l’identité et l’adresse du service fournies :
cat scope.json
L’URL de base est http://members.test:8080/autumn. Utilisez le nom d’utilisateur morgan et le mot de passe PaperDay!47. Votre membre est Morgan Reed, avec la place P12 pour Printmaking. Le point d’exclamation fait partie du mot de passe ; saisissez-le dans le formulaire du navigateur. Ne testez pas d’autres identités ou sites externes et ne modifiez ni les données, ni le code, ni 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. Burp Community est déjà installé. Dans son assistant de démarrage, laissez Temporary project sélectionné et cliquez sur Next. Laissez Use Burp defaults sélectionné, puis 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. Attendez la fenêtre principale. Un projet temporaire conserve l’espace de travail actif en mémoire ; ce cours utilise des exports XML explicites pour les fichiers de preuve, plutôt qu’une fonctionnalité payante de projet sur disque.
Burp est un proxy : les navigateurs préparés lui transmettent leurs requêtes HTTP afin que vous puissiez examiner les échanges réels. Dans Burp, choisissez l’onglet principal Proxy et le sous-onglet Intercept. Le bouton doit afficher Intercept is off. S’il affiche Intercept is on, cliquez dessus une fois. L’interception mettrait les requêtes en pause ; vous voulez qu’elles circulent normalement tout en enregistrant leur historique.
Passez à l’onglet LabEx Browser A. Il s’agit d’un navigateur Chromium préparé dans le même conteneur d’audit que Burp. Cliquez dans sa barre d’adresse, saisissez l’URL suivante et appuyez sur Entrée :
http://members.test:8080/autumn/
Lisez la page publique des ateliers et choisissez View my booking. Remplissez Username et Password avec les identifiants fournis, puis cliquez sur Sign in. Si Chromium propose d’enregistrer le mot de passe, choisissez Never. Vous devriez arriver sur Your next day of making, qui affiche Morgan Reed, Printmaking et la place P12.
Cliquez sur Download booking. Le véritable fichier fieldwork-booking.csv contient le membre, l’atelier et la place. La barre de téléchargements de Chromium, en bas, affiche le fichier téléchargé ; Show all ouvre sa liste de téléchargements. La consultation publique des ateliers, celle de votre réservation et ce téléchargement sont les fonctions normales à préserver.
Vérifiez le membre, l’atelier et la place dans la carte de réservation avant de télécharger.
Un mot de passe incorrect produit Sign-in unsuccessful, avec un lien try again. Suivez ce lien et saisissez de nouveau les valeurs fournies. Une réponse Page not found signifie que le chemin est incorrect ; revenez à l’URL de base exacte ci-dessus. Une erreur de connexion du navigateur signifie qu’aucune réponse de l’application n’a été obtenue : vérifiez l’URL, terminez l’assistant de Burp et assurez-vous que l’interception est désactivée. Ne considérez pas un échec de connexion comme un refus de sécurité.
Browser B est un profil de navigateur indépendant pour le prochain lab ; ne l’utilisez pas ici. Les deux onglets de navigateur et Burp sont des fenêtres d’un même conteneur d’audit, pas des machines virtuelles séparées. Changer d’onglet LabEx ne réinitialise ni la cible ni votre travail.
Conserver les requêtes originales dans Repeater
Dans cette étape, vous allez préserver des requêtes qui ont déjà fonctionné. Passez à Burp, sélectionnez Proxy, puis HTTP history. Trouvez la requête GET vers /autumn/account sur members.test:8080. Une requête est ce que le navigateur envoie ; une réponse est ce que le serveur renvoie. GET lit une ressource. HTTP 200 OK signifie que cette requête a reçu une réponse réussie.
Cliquez sur la ligne du compte. Dans son éditeur de requête, choisissez Raw et repérez l’en-tête Cookie. La connexion a émis un cookie de session nommé studio_session : le navigateur envoie cette valeur pour identifier sa session authentifiée. La possession de l’ancien cookie est la condition que vous testez. Effacer un cookie du navigateur puis essayer une nouvelle requête sans cookie poserait une autre question.
Faites un clic droit sur la ligne du compte et choisissez Send to Repeater. Repeater permet de renvoyer une requête conservée et d’examiner la nouvelle réponse. Trouvez ensuite la requête GET vers /autumn/booking.csv, faites un clic droit dessus et choisissez Send to Repeater. Si un filtre d’historique masque la requête CSV, cliquez sur la barre de filtre au-dessus du tableau et activez Show all, puis fermez la boîte de dialogue du filtre et retrouvez le chemin exact. Appuyez-vous sur l’hôte et le chemin, pas seulement sur la position de la ligne.
Choisissez l’onglet principal Repeater. Le premier onglet de requête numéroté, 1, correspond à la requête du compte ; 2 correspond à celle de réservation, dans l’ordre où vous les avez envoyées. Dans 1, confirmez que la cible est http://members.test:8080, que la ligne de requête est GET /autumn/account HTTP/1.1 et que le cookie studio_session d’origine est toujours présent. Cliquez sur Send. Dans le volet de réponse, choisissez Raw pour lire HTTP/1.0 200 OK et le contenu de la page de réservation.
Sélectionnez 2 et cliquez sur Send. Attendez-vous à 200 OK, à un type de contenu text/csv et aux véritables lignes de réservation. La version HTTP du serveur peut différer de celle de la requête ; les observations significatives sont le statut et le véritable contenu de réservation du membre.
Les deux requêtes conservées doivent utiliser le même cookie de session. Comparez les valeurs dans Burp sans les copier dans un rapport. Gardez ces deux requêtes Repeater inchangées pendant toute la déconnexion : ne retirez ni ne remplacez leurs cookies, ne remplacez pas la cible et n’envoyez pas de requête de déconnexion depuis ces onglets. Leur réussite initiale donne du sens à la comparaison ultérieure.
Si vous avez envoyé la mauvaise ligne d’historique, fermez uniquement cet onglet de requête Repeater et envoyez la bonne ligne. Identifiez la bonne requête par son chemin ; les numéros d’onglet peuvent alors différer. Fermer un onglet de requête est différent de fermer Burp ou de réinitialiser la VM.
Tester l’ancien cookie après la déconnexion
Dans cette étape, vous allez distinguer la déconnexion visible dans un navigateur de l’invalidation de session côté serveur. Passez à Browser A. Sur la page de réservation, cliquez sur Sign out this browser. Le navigateur revient à Welcome back, la page de connexion.
Ce changement de page ne prouve pas à lui seul que le serveur a cessé d’accepter l’ancien cookie. Passez à Burp, ouvrez Repeater, sélectionnez votre requête originale du compte et cliquez de nouveau sur Send. Gardez son cookie inchangé. Attendez-vous à 200 OK et au contenu de réservation de Morgan Reed. L’ancienne session donne toujours accès au compte après la déconnexion.
Sélectionnez votre requête originale de réservation et cliquez de nouveau sur Send. Attendez-vous à 200 OK, text/csv et à la ligne de réservation du même membre. Il s’agit d’une véritable réponse de téléchargement réussie obtenue avec l’ancien cookie ; une page de navigateur qui semble indiquer une réussite ou un HTTP 200 ne contenant qu’un formulaire de connexion ne l’établirait pas.
Pour une déconnexion du navigateur courant qui fonctionne, les deux requêtes protégées conservées devraient plutôt recevoir 401 Unauthorized, ce qui signifie que l’application rejette cette session. Ici, le serveur l’accepte encore pour les deux ressources. Rejetez la modification de déconnexion sur la base des preuves observées. Vous avez démontré cette défaillance de session précise, pas toutes les faiblesses possibles de l’application.
Confirmez que l’utilisation ordinaire reste possible. Passez à Browser A, reconnectez-vous avec morgan et PaperDay!47, consultez la réservation et cliquez sur Download booking. Cela émet une nouvelle session et préserve le parcours normal du membre. Revenez à Burp sans remplacer les cookies de vos deux requêtes Repeater originales. Leurs réponses les plus récentes doivent toujours être celles obtenues après la déconnexion, que vous exporterez ensuite.
Comparez le Cookie inchangé dans le volet Request de gauche avec 200 OK et la véritable ligne du membre dans le volet Response de droite. Un statut de réussite ne suffirait pas, à lui seul, à prouver l’accès à cette réservation.
Si vous écrasez accidentellement un cookie d’origine ou fermez les deux requêtes conservées, répétez un test complet : capturez une nouvelle session réussie sur les deux ressources, conservez ses requêtes, déconnectez cette session et rejouez ensuite ces requêtes exactes. Le cookie d’une nouvelle connexion ne remplace pas celui de la session que vous avez déconnectée.
Livrer des preuves privées et une décision claire
Dans cette étape, vous allez enregistrer les véritables preuves HTTP tout en gardant les identifiants hors de l’évaluation. Passez à Auditor. Les preuves de requêtes et de réponses contiennent un cookie de session utilisable : restreignez donc leur accès avant de les enregistrer.
umask 077 rend les fichiers et répertoires nouvellement créés privés pour votre utilisateur. Il s’applique à cette session de terminal, pas à tous les shells futurs. mkdir -p crée le répertoire nommé si nécessaire. chmod 700 donne à son propriétaire les droits de lecture, d’écriture et d’accès aux entrées du répertoire, sans aucun accès pour le groupe ou les autres utilisateurs.
umask 077
mkdir -p evidence
chmod 700 evidence
Passez à Burp et sélectionnez la requête originale du compte dans Repeater. Confirmez que sa réponse actuelle est la page de réservation 200 OK obtenue après la déconnexion. Faites un clic droit à l’intérieur de l’éditeur Request et choisissez Save item. Cette action enregistre la requête et la réponse ensemble ; Copy to file enregistrerait d’autres éléments.
Dans la boîte de dialogue Select a file, saisissez ce chemin absolu dans File Name :
/home/labex/project/evidence/account-after.xml
Utilisez le champ File Name vers le bas ; l’option Base64 cochée se trouve en dessous.
Laissez Base64-encode requests and responses cochée, puis cliquez sur Save. Base64 représente les octets originaux de manière sûre dans le XML ; il ne chiffre pas le cookie. Fermez une notification de réussite avec OK si elle apparaît. Répétez Save item pour la requête originale de réservation, en utilisant :
/home/labex/project/evidence/booking-after.xml
Passez à Auditor. chmod 600 autorise uniquement le propriétaire à lire et écrire chaque fichier. ls -l affiche les permissions ; attendez-vous à -rw------- pour les deux fichiers XML.
chmod 600 evidence/account-after.xml evidence/booking-after.xml
ls -l evidence
Écrivez l’évaluation sans mot de passe ci-dessous. > remplace le fichier nommé. <<'JSON' démarre un here-document : le shell copie littéralement les lignes suivantes jusqu’au JSON final, seul sur sa ligne. Les valeurs numériques de statut sont sans guillemets ; le true JSON est une valeur booléenne. Gardez les cookies, les mots de passe et les requêtes brutes hors de ce rapport.
cat > assessment.json <<'JSON'
{
"decision": "reject",
"account_after_logout": 200,
"booking_after_logout": 200,
"fresh_sign_in_works": true
}
JSON
Lisez votre évaluation pour repérer les erreurs de saisie courantes :
cat assessment.json
Les éléments à remettre sont les deux éléments XML privés et cette évaluation. Les éléments conservent les requêtes avec leur cookie d’origine et leurs véritables réponses ; le rapport communique la décision étayée sans répéter les secrets. La vérification contrôle ces relations par rapport aux faits existants du serveur. Elle ne crée pas à votre place les connexions, les déconnexions ou le trafic de rejeu manquants et laisse vos fichiers inchangés. Sa requête ordinaire de vérification de la préservation de la page publique peut ajouter une entrée au journal d’accès.
Si un nom de fichier est incorrect, répétez Save item vers le chemin absolu indiqué et réappliquez chmod 600. Si vous avez changé de répertoire, pwd affiche le répertoire courant et cd /home/labex/project vous ramène à l’espace de travail. Ne remplacez pas des preuves manquantes par une ligne de réussite écrite à la main ou une capture d’écran.
Résumé
Vous avez établi une référence de réservation réelle, conservé deux requêtes avec leur cookie d’origine dans Burp Repeater, effectué la déconnexion et démontré que le serveur acceptait toujours les deux requêtes. Le retour d’un navigateur à sa page de connexion ne prouvait pas l’invalidation de la session. Vous avez préservé le parcours normal et livré des preuves HTTP privées avec une décision de rejet sans mot de passe.
Le prochain lab examine un déploiement corrigé. Un navigateur indépendant aidera à distinguer la fin de la session courante de la fermeture inutile de toutes les sessions du même membre.
