CNAME cloaking : enquêter sur un sous-domaine tiers

Le CNAME cloaking consiste à faire apparaître un service tiers sous un sous-domaine du site, grâce à un alias DNS. Le navigateur peut demander mesure.example.com tandis que la résolution mène à l’infrastructure d’un prestataire. Un contrôle fondé uniquement sur le nom visible risque alors de manquer cette relation.

Tous les CNAME externes ne sont pas des dispositifs de pistage. La même technique sert des usages ordinaires d’hébergement ou de support. L’enquête doit établir le service réellement utilisé, les données échangées et la responsabilité de son maintien avant de choisir une mesure.

Distinguer l’alias DNS d’une redirection web

Un CNAME associe un alias à un nom canonique dans le DNS. La RFC 1034 décrit ce mécanisme. Il ne s’agit pas d’une redirection HTTP : l’URL visible peut conserver son nom initial pendant que le DNS résout la destination.

Voici un schéma fictif. example.com, les domaines .example et l’adresse IP sont réservés à la documentation.

Requête du navigateur : https://mesure.example.com/collect
DNS : mesure.example.com CNAME collecte.prestataire.example
DNS : collecte.prestataire.example A 192.0.2.126

La propriété du nom initial et l’exploitation du serveur final sont deux questions différentes. Conservez les deux noms dans la fiche d’enquête. Si votre outil n’affiche que l’IP, ajoutez aussi le nom demandé et la chaîne observée, afin de ne pas attribuer tout le trafic de cette adresse à un seul client.

Partir d’une requête réelle

Choisissez une page et une action utilisateur à reproduire : ouverture d’une fiche produit, connexion ou validation d’un formulaire. Utilisez un compte de test et des données fictives. Notez le navigateur, sa version, l’heure, l’état du consentement et les extensions actives.

Dans les outils de développement, trouvez la requête vers le sous-domaine étudié et son initiateur. S’agit-il d’un script directement intégré, d’un gestionnaire de balises ou d’une ressource chargée par un autre fournisseur ? L’initiateur permet de joindre l’équipe responsable du code ou du paramétrage.

Conservez une trace expurgée des secrets. Un export HAR peut contenir des cookies, des jetons et des données de formulaire. Gardez l’original dans l’espace d’enquête autorisé et préparez une version minimale pour les échanges avec le prestataire.

Le point à démontrer n’est pas « ce domaine ressemble à notre site ». C’est « cette action provoque cette requête, avec ces données, vers ce service ». Cette formulation rend l’observation reproductible et évite d’attribuer une collecte à un composant simplement présent sur la page.

Suivre la résolution depuis le bon contexte

Relevez les réponses DNS obtenues dans le contexte du test, avec le résolveur et l’heure. Pour une vérification sur un domaine que vous gérez, une commande comme celle-ci permet d’afficher la réponse disponible :

dig mesure.example.com CNAME +noall +answer

Cette commande utilise un nom d’illustration ; remplacez-le par le nom autorisé à examiner. Si la réponse contient un alias supplémentaire, poursuivez la chaîne. Consultez également les réponses A et AAAA nécessaires à la destination, sans supposer qu’une seule famille d’adresses est utilisée.

Comparez cette observation aux journaux de résolution du poste si vous cherchez à expliquer un événement passé. Une réponse actuelle peut différer de celle de l’incident. L’absence de CNAME visible dans une réponse synthétisée ne démontre pas non plus l’absence de prestataire : demandez la configuration de zone au propriétaire du domaine lorsque vous y avez accès.

Pour élargir l’inventaire, la méthode d’énumération des sous-domaines aide à retrouver les noms associés à vos services. Chaque découverte demande ensuite une attribution interne et un usage validé.

Examiner ce que le serveur reçoit

Contrôlez l’URL, les paramètres, les en-têtes et le corps de la requête de test. Recherchez les identifiants de compte, les données métier et les cookies qui n’étaient pas nécessaires au service. Une requête sans cookie peut encore transmettre une donnée personnelle dans son corps ; l’analyse ne doit donc pas s’arrêter au stockage du navigateur.

Un cookie configuré avec Domain=example.com peut s’appliquer aux sous-domaines. HttpOnly empêche sa lecture par JavaScript, mais ne supprime pas son envoi HTTP lorsque les autres conditions sont réunies. La documentation MDN sur les cookies précise le rôle de ces attributs. Vérifiez le contenu réellement envoyé, sans conclure à une exposition à partir de la seule configuration.

Distinguez également same-site et same-origin. Deux sous-domaines peuvent appartenir au même site tout en étant des origines différentes. Un alias DNS ne fusionne pas les règles d’origine du navigateur. Une politique qui autorise tous les sous-domaines et une politique limitée à une origine exacte n’accordent pas les mêmes permissions.

WebKit a documenté l’usage du CNAME cloaking par des traceurs et les protections associées. Ces protections expliquent pourquoi deux navigateurs peuvent produire des observations différentes. Elles ne dispensent pas le propriétaire du site de maîtriser les données envoyées à son prestataire.

Faire confirmer le service et son périmètre

Envoyez au propriétaire interne le nom d’hôte, la cible DNS, l’initiateur et un exemple de requête expurgé. Demandez à quoi sert l’intégration, quel compte fournisseur la contrôle et quelles données sont attendues. Une facture d’abonnement confirme une relation commerciale, pas nécessairement cette configuration précise.

Comparez ensuite les données observées au besoin annoncé. Si une simple mesure de fréquentation reçoit des éléments liés à une session de compte, faites préciser leur nécessité et leur traitement. Si l’intégration n’a plus de propriétaire, inscrivez-la comme dépendance à examiner avant son maintien.

L’article sur la prise de contrôle de sous-domaines et le DNS orphelin traite le cas où la ressource du prestataire a été libérée. Un alias encore présent ne prouve pas qu’un tiers peut reprendre la cible, mais il justifie de vérifier le cycle de décommissionnement.

Choisir une correction et la vérifier

Si le service est autorisé mais reçoit trop de données, corrigez le composant qui les envoie et la portée des cookies concernés. Testez les parcours métier affectés, car une modification de cookie peut toucher la connexion ou d’autres sous-domaines.

Si le service est abandonné, planifiez son retrait avec le responsable DNS et le propriétaire de l’application. Retirez les références actives et neutralisez l’alias avant de libérer définitivement une ressource réutilisable. Vérifiez ensuite les requêtes restantes et les effets du cache.

Si le comportement reste inexpliqué, appliquez la restriction adaptée à votre contexte et gardez une condition de réexamen. Pour compléter le dossier, consultez un rapport IsMalicious sur le nom initial et sur la cible pertinente. Des résultats de réputation différents sont possibles ; c’est leur relation avec la requête observée qui donne un sens à la décision.