PhpBB Lab Académie

Contrôler l’adresse HTTPS réellement utilisée, vérifier les paramètres natifs de phpBB et tester une redirection HTTP sans transmettre d’identifiants sur une connexion non chiffrée.

Trois mécanismes à vérifier séparément

HTTPS protège les échanges entre navigateur et serveur grâce à TLS, le protocole de sécurisation du transport. Le certificat présenté doit convenir au nom demandé et être accepté par le navigateur. Une redirection est une réponse qui demande au navigateur de continuer vers une autre adresse. Enfin, les cookies permettent notamment de retrouver la session phpBB. Aucun de ces mécanismes ne remplace les deux autres.

Le certificat a été préparé au chapitre 2 avant toute saisie d’identifiants. Nous allons maintenant vérifier son usage dans le parcours phpBB. Le forum reste fermé, derrière la protection du dossier. Une demande de nom et mot de passe provenant de cette protection peut précéder le formulaire phpBB : les deux comptes sont distincts, et aucun de leurs secrets ne doit être recopié dans le carnet.

Notre adresse de référence reste le sous-domaine propre à la démonstration, sans variante ajoutée. N’inventez pas un deuxième nom avec www et ne changez pas les autres sites du domaine. Un certificat peut couvrir un nom sans couvrir toutes les variantes imaginables. L’adresse finale du carnet est celle sur laquelle les tests seront effectués et les futurs messages de service devront pointer.

Confirmer une connexion chiffrée réellement disponible

1. Dans le navigateur, ouvrez directement l’adresse complète commençant par https:// et votre nom d’hôte exact. Lisez l’adresse après chargement avec la barre d’adresse. Les informations de connexion du navigateur doivent correspondre à ce nom, sans alerte de certificat. Le dessin ou la couleur d’un symbole ne suffit pas : utilisez aussi son intitulé accessible.

2. Si le navigateur affiche une alerte, ne la contournez pas pour saisir un mot de passe. Conservez le nom concerné et le sens de l’erreur, puis faites vérifier le certificat par l’hébergeur. Si la protection empêche son renouvellement, demandez également la procédure prévue pour ce cas ; ne retirez pas la protection du forum pour expérimenter.

3. Franchissez la protection du dossier uniquement après cette vérification HTTPS. Si CamilleAdmin n’est pas déjà connecté, connectez ce compte et ouvrez son panneau d’administration. La première visite de la leçon 7 reste la référence ; il n’y a pas de second forum à créer.

Relire les valeurs de phpBB dans leurs écrans

4. Dans « Général », rubrique « Configuration du serveur », ouvrez « Paramètres du serveur ». Vérifiez « Nom de domaine », « Port du serveur », « Protocole du serveur » et « Chemin du script ». Notre destination racine prévoit le nom d’hôte seul, 443, https:// et un chemin vide. « Forcer les paramètres URL du serveur » reste sur « Non ». Lisez les valeurs sans modifier les emplacements des images ou des autres ressources de cet écran.

5. Ouvrez « Paramètres des cookies ». Retrouvez le nom phpbbjardinspub, le domaine exact du forum, le chemin / et « Cookies sécurisés : Activé ». Ces valeurs doivent correspondre à celles relues dans la base. Le forum local resté sur votre ordinateur conserve ses propres valeurs HTTP ; vous n’appliquez pas cette fiche à toutes les installations.

6. Si un lien administratif renvoie vers localhost, vers un mauvais sous-domaine ou vers un ancien dossier, relevez précisément le lien concerné sans publier son identifiant de session. Revenez aux paramètres et au cache de la leçon 7. Si seuls certains liens restent incorrects, leur provenance sera recherchée en leçon 9. N’activez pas un forçage d’URL au hasard pour dissimuler la cause.

Un hébergement peut placer un intermédiaire technique devant le serveur ; une mauvaise reconnaissance de HTTPS à ce niveau peut produire des liens ou redirections incohérents. Il faut alors demander au fournisseur de vérifier la détection du protocole et sa configuration. Ce cours ne vous demande pas d’inventer des règles Apache ou Nginx ni de modifier plusieurs protections pour voir laquelle fait disparaître le symptôme.

Faire rejoindre HTTPS depuis HTTP

7. Dans cPanel, l’écran « Domains », c’est-à-dire les domaines hébergés, peut proposer « Force HTTPS Redirect » : redirection imposée vers HTTPS. Repérez seulement la ligne du domaine de démonstration. Si cette action y est disponible avec le certificat valide, activez-la pour ce domaine uniquement. Si elle est absente ou indisponible, demandez à l’hébergeur la méthode adaptée à ce sous-domaine ; les options ne sont pas identiques selon les offres. Ne modifiez pas le domaine principal pour obtenir un bouton actif.

8. Pour le test, utilisez un nouveau contexte privé sans identifiants de protection enregistrés. Saisissez cette fois http:// suivi du seul nom d’hôte de démonstration. N’envoyez aucun formulaire de connexion. L’adresse doit rejoindre https:// avec le même nom avant que vous transmettiez un secret. La protection du dossier reste ensuite attendue. Si la demande de mot de passe arrive alors que l’adresse est toujours HTTP, annulez-la et faites corriger l’ordre du parcours par l’hébergeur.

9. Vérifiez l’arrivée puis annulez la demande de protection dans ce contexte de contrôle : inutile d’y ouvrir une deuxième session phpBB. Si le navigateur annonce trop de redirections, si l’adresse alterne entre deux noms ou si HTTP reste affiché, notez le test en échec. Gardez les protections en place et faites examiner la règle ou le réglage responsable. Plusieurs redirections concurrentes ajoutées à l’aveugle peuvent compliquer le diagnostic.

10. Dans le contexte HTTPS autorisé de CamilleAdmin, ouvrez successivement l’index puis le panneau. Vérifiez le domaine final et la continuité de connexion. Déconnectez-vous avec le lien actuel de phpBB, puis ouvrez à nouveau son lien « Connexion » : le formulaire doit demander une connexion, sans session CamilleAdmin déjà ouverte. Une demande à ucp.php sans mode de connexion peut annoncer la fermeture du forum ; ce n’est pas un échec de déconnexion. Reconnectez CamilleAdmin pour la suite. Le forum reste fermé.

Décrire ce que le test prouve

Un navigateur peut mémoriser une redirection ou appliquer une politique qui transforme directement HTTP en HTTPS. Voir HTTPS à l’arrivée valide alors ce parcours navigateur, sans toujours démontrer la réponse HTTP brute du serveur. Notez cette limite et demandez au fournisseur de confirmer sa redirection si nécessaire. La réception du futur lien d’activation sera un autre contrôle utile au chapitre 4.

La présence occasionnelle de sid dans un lien d’action phpBB ne change pas le certificat et ne prouve pas une intrusion. Comme au cours 6, n’en partagez pas la valeur et ne retirez pas manuellement les paramètres des liens de déconnexion. La propreté des adresses publiques et la validation d’une action connectée sont des contrôles distincts.

Une fiche précise distingue : « HTTPS direct : accepté sans alerte pour le bon nom. Paramètres phpBB : relus et cohérents. Parcours saisi en HTTP : arrive en HTTPS avant toute transmission de secret ; protection du dossier toujours présente. Connexion phpBB : continue sur deux pages. » Si la redirection serveur n’a pas été confirmée indépendamment du navigateur, ajoutez cette limite au lieu d’annoncer une validation complète.

Trois cas fictifs : A, le bon domaine répond en HTTPS mais affiche une alerte de certificat ; B, HTTP demande le mot de passe de protection avant de rejoindre HTTPS ; C, l’administration fonctionne mais un seul lien dans une ancienne annonce retourne vers localhost. Indiquez pour chacun le premier contrôle adapté. Aucun identifiant ne doit être saisi pour résoudre A ou B.

Contrôlez le certificat, les paramètres phpBB et le chemin de redirection séparément. Saisissez les secrets uniquement sur HTTPS valide. Gardez un seul nom de référence et la protection du dossier. Un problème propre à l’hébergement doit recevoir une correction adaptée, pas des règles serveur improvisées.