Un groupe hôtelier utilise un domaine principal pour son site de réservation WordPress, et avait fait développer, deux ans auparavant, un micro-site événementiel sur un sous-domaine dédié pour un salon professionnel ponctuel. Le salon terminé, le sous-domaine avait été abandonné sans être formellement supprimé : son hébergement avait simplement cessé d’être renouvelé par l’agence externe qui l’avait mis en place, jusqu’à expiration silencieuse.
Un attaquant a profité de cette expiration pour reprendre le contrôle du sous-domaine (une technique connue sous le nom de « subdomain takeover », qui exploite un enregistrement DNS pointant vers un service ou un hébergement qui n’existe plus, mais reste réclamable par quiconque le repère) et y a déployé une page web sous son contrôle. Ce sous-domaine compromis a ensuite pu lire les cookies d’authentification du site principal de réservation, permettant l’usurpation de sessions de plusieurs clients connectés à leur espace personnel.
Comprendre pourquoi un sous-domaine peut lire les cookies du domaine principal
WordPress définit, via la constante COOKIE_DOMAIN dans wp-config.php, le périmètre de domaine sur lequel ses cookies d’authentification sont valides. Par défaut, si cette constante n’est pas définie explicitement, WordPress restreint généralement ses cookies au domaine exact sur lequel il est installé. Mais un développeur avait, sur ce projet, explicitement défini une valeur plus permissive pour un besoin ponctuel de partage de session entre le site principal et un ancien sous-domaine de préproduction, sans jamais revenir sur ce réglage une fois le besoin disparu :
// Trouvé tel quel dans wp-config.php, ajouté deux ans plus tôt
define( 'COOKIE_DOMAIN', '.groupe-hotelier.example' );Le point précédant le nom de domaine est déterminant : selon la spécification des cookies HTTP, un domaine préfixé par un point rend le cookie valide non seulement pour le domaine exact, mais pour tous ses sous-domaines, présents et futurs. C’est exactement ce mécanisme qui a permis au sous-domaine repris par l’attaquant de recevoir, dans chaque requête du navigateur d’un visiteur déjà connecté au site principal, les mêmes cookies d’authentification que ceux envoyés au site légitime.
Ce que l’attaquant a pu faire avec ces cookies
Les cookies d’authentification WordPress (wordpress_logged_in_... notamment) contiennent un identifiant de session lié au compte, signé avec les clés d’authentification du site pour empêcher leur falsification. Un attaquant qui parvient à les lire — pas à les forger, simplement à les lire, puisqu’ils sont automatiquement envoyés par le navigateur à toute requête vers un domaine ou sous-domaine pour lequel ils sont valides — peut les réutiliser tels quels dans ses propres requêtes vers le site principal, tant que la session n’a pas expiré ni été invalidée. C’est une usurpation de session par vol de cookie, sans avoir besoin de connaître le mot de passe du compte visé.
Le mécanisme précis d’interception reposait sur une page piégée déposée sur le sous-domaine compromis, qui effectuait une requête en arrière-plan (une simple balise <img> ou un appel JavaScript) vers un point de collecte contrôlé par l’attaquant, en s’assurant que le navigateur de la victime, s’il visitait cette page pour une raison quelconque (un ancien lien encore indexé, un favori oublié), joigne automatiquement ses cookies valides pour l’ensemble du domaine parent.
Le correctif immédiat et le correctif structurel
La première action a été de nettoyer intégralement le DNS pour retirer tout enregistrement pointant vers une ressource non maîtrisée, refermant immédiatement la possibilité pour l’attaquant de continuer à contrôler le sous-domaine. Cette étape seule aurait suffi à arrêter l’attaque en cours, mais pas à corriger la faiblesse structurelle qui l’avait rendue possible.
Le correctif de fond a consisté à restreindre COOKIE_DOMAIN au strict nécessaire, sans le point de tête qui étend la portée à tous les sous-domaines :
// Correctif : restriction au domaine exact, sans extension aux sous-domaines
define( 'COOKIE_DOMAIN', 'groupe-hotelier.example' );Dans la très grande majorité des cas, ne pas définir COOKIE_DOMAIN du tout reste le choix le plus sûr : WordPress calcule alors automatiquement une valeur adaptée au domaine réel de l’installation, sans extension implicite. La constante ne devrait être définie explicitement que pour un besoin précis et documenté de partage de cookies entre domaines apparentés, jamais par défaut ni « pour éviter des problèmes » non identifiés, comme cela avait été fait ici deux ans plus tôt.
Une vérification systématique pour tout portefeuille de domaines
Cet incident a conduit à instaurer, pour ce client comme pour l’ensemble de nos projets disposant de sous-domaines historiques, une revue régulière des enregistrements DNS pointant vers des ressources externes (hébergement tiers, service SaaS, CDN) afin de détecter toute ressource expirée ou abandonnée avant qu’elle ne devienne réclamable par un tiers :
# Vérifie qu'un enregistrement CNAME pointe vers une ressource encore active
dig +short sous-domaine-oublie.groupe-hotelier.example CNAME
# Puis vérification manuelle que la cible répond encore légitimement,
# et non par une page d'erreur générique du fournisseur ("non trouvé, réclamez-le")Sur ce dossier, la leçon retenue dépasse la seule configuration de cookie : tout sous-domaine créé pour un besoin ponctuel doit être supprimé activement à la fin de ce besoin, DNS compris, plutôt que laissé à l’abandon en espérant qu’il ne dérange jamais personne.
Ce que cette étude de cas ne couvre pas
Ce cas ne détaille pas le fonctionnement général des cookies d’authentification WordPress (leur contenu, leur durée de vie, leur mécanisme de signature), un sujet de fond traité séparément. Il montre une conséquence précise et sous-estimée d’un réglage de portée trop large, combiné à une hygiène DNS insuffisante sur des ressources devenues obsolètes.
