PhpBB Lab Académie

Distinguer le chiffrement HTTPS de la gestion des sessions, puis relever les paramètres des cookies du clone sans les modifier.

L’adresse indique aussi comment le navigateur communique

Vous avez déjà saisi l’adresse du laboratoire. Son début, http://, désigne le protocole utilisé pour la communication. Sur un site public, HTTPS protège le transport des échanges entre le navigateur et le serveur. Le navigateur vérifie aussi un certificat présenté pour le nom du site. Cela ne garantit pas que les conseils du site sont fiables, ni qu’un compte possède les bonnes permissions. Une page malveillante peut elle aussi être servie en HTTPS.

Un navigateur peut annoncer une connexion sécurisée ou présenter des informations dans le menu de l’adresse. Ne fondez pas le contrôle uniquement sur la couleur d’un symbole. Lisez l’adresse complète, puis les informations de connexion disponibles dans votre navigateur. Face à une alerte de certificat sur un site public, ne passez pas outre pour saisir vos identifiants. Les explications de cette leçon ne vous demandent ni d’installer un certificat ni de modifier un serveur.

Notre clone, lui, utilise volontairement l’adresse locale http://localhost/forum-ecole-restauration/. Nous y apprenons avec des comptes d’exercice. Remplacer simplement http par https dans la barre d’adresse ne configure pas le serveur. Ne faites pas cette substitution, et ne rendez pas WampServer accessible depuis Internet pour l’exercice. « Local en HTTP » et « site public préparé pour HTTPS » sont deux situations différentes.

Pourquoi le forum vous reconnaît-il sur la page suivante ?

Une session permet au serveur de rattacher vos demandes successives à votre connexion. Un cookie est une petite donnée conservée par le navigateur et renvoyée dans les échanges concernés. phpBB s’appuie notamment sur des cookies pour retrouver la session ; vous n’avez ainsi pas à ressaisir votre mot de passe à chaque lien. Le cookie ne donne pas davantage de permissions : le serveur continue de vérifier les droits du compte.

Le nom du cookie aide à distinguer les données d’un forum. Le domaine et le chemin définissent où le navigateur peut les envoyer. Dans notre ensemble de copies locales, des valeurs mal choisies pourraient mélanger des usages ou perturber la connexion. Les réglages isolés préparés précédemment sont donc conservés. Nous relevons les paramètres définis dans l’administration, pas le contenu secret des cookies stockés dans le navigateur.

« Cookies sécurisés » demande à phpBB de marquer ses cookies pour le transport sécurisé. Cette case n’active pas HTTPS sur le serveur. Le comportement exact sur localhost peut varier selon le navigateur, qui peut lui appliquer une exception technique ; cette exception n’est pas une raison de modifier notre configuration. Sur ce clone HTTP, nous laissons l’option désactivée. Sur un véritable site HTTPS, son réglage doit être cohérent avec le service réellement installé et testé.

Un relevé sans changement

1. Le forum reste fermé. Depuis la fenêtre de CamilleAdmin, vérifiez l’adresse du clone, puis ouvrez le panneau d’administration. Dans « Général », trouvez la rubrique « Configuration du serveur » et le lien « Paramètres des cookies ».

2. Lisez successivement « Domaine des cookies », « Nom des cookies », « Chemin des cookies » et « Cookies sécurisés ». Utilisez les libellés de champs et les commandes de lecture de votre lecteur d’écran. Ne changez pas une valeur pour voir ce qui arrive. Le domaine et le chemin notés dans votre état initial priment sur des exemples génériques.

3. Dans le carnet, créez une fiche linéaire : « Paramètre : Cookies sécurisés. Avant : valeur lue. Essai : lecture seule sur le clone HTTP. Après : inchangé. » Faites de même pour le nom, le domaine et le chemin. Le nom configuré n’est pas la valeur du cookie de session ; ne cherchez pas cette dernière.

4. Vérifiez la cohérence avec votre fiche du chapitre 1. Le clone est en HTTP et l’option Cookies sécurisés doit y rester désactivée. Si elle est déjà activée ou si les autres valeurs diffèrent de l’état attendu, consignez cet écart et arrêtez les essais de connexion suivants jusqu’au diagnostic. N’envoyez pas au hasard un formulaire corrigé.

5. Quittez l’écran avec un lien de navigation, sans utiliser « Envoyer ». Le résultat attendu est un relevé daté et aucun changement. La fermeture du forum, les styles, les permissions et les courriels restent dans leur état précédent.

Et le paramètre sid dans une adresse ?

phpBB peut ajouter un identifiant de session, écrit sid, à certaines adresses. Cela peut se produire quand la session n’est pas retrouvée par cookie, ou pour certaines opérations qui l’exigent. Sa seule présence ne prouve pas une intrusion. Une adresse contenant cet identifiant ne doit cependant pas être publiée dans un message, une capture de support ou le carnet.

Pour l’atelier, ouvrez le forum par l’adresse de base connue. Pour une demande d’aide, décrivez la page et masquez les paramètres de session. Ne retirez pas manuellement ces paramètres d’un bouton de déconnexion ou d’un formulaire pour « nettoyer » l’application : le lien peut participer à la vérification de l’action. De même, les protections de formulaire, qui aident à empêcher une action provoquée depuis un autre site, restent actives. Un problème d’URL publique se corrige dans la génération des liens et leur référencement, sans neutraliser les contrôles de connexion.

Camille lit « Cookies sécurisés : Désactivé » dans son clone HTTP et laisse cette valeur. Elle voit ensuite sid dans une adresse de déconnexion. Elle utilise le lien du forum sans le réécrire et ne copie pas l’adresse dans son carnet. Son compte rendu dit : « Paramètres relevés, aucune modification ; déconnexion à vérifier dans la leçon suivante. » Elle n’affirme pas avoir testé HTTPS : ce laboratoire ne le propose pas.

Rédigez deux conclusions à partir de votre relevé. La première répond à la question : faut-il activer Cookies sécurisés pour transformer notre clone HTTP en site HTTPS ? La seconde répond à cette situation : une adresse contient sid ; que pouvez-vous conclure et que devez-vous éviter de partager ? Indiquez ensuite un point que cet audit en lecture seule n’a pas testé.

HTTPS protège le transport ; une session permet de retrouver une connexion ; un cookie peut transporter l’identifiant nécessaire. Ces rôles sont distincts. Relevez les paramètres du clone sans les modifier. Conservez Cookies sécurisés désactivé sur ce laboratoire HTTP et gardez les identifiants de session hors des documents partagés.