Fixation de session inter-sous-domaines (CWE-384) : un sous-domaine ennemi pose un cookie Domain=.example.com avec un token connu avant la connexion de la victime à l'application principale.
TL;DR
Domain=.example.com peut définir des cookies de session pour le domaine parent depuis n'importe quel sous-domaine__Host- est le contrôle préventif complet — le navigateur rejette les écritures de cookies inter-sous-domaines pour les noms avec préfixe __Host-Domain=.example.com (point initial) dans Set-Cookie est signalable indépendamment comme HIGHLa fixation inter-sous-domaines exploite le modèle de portée des cookies du navigateur pour planter un identifiant de session connu depuis un sous-domaine, ciblant l'application principale. L'attaque ne nécessite ni XSS, ni interception réseau, ni exécution de code sur l'application principale — seulement la capacité d'émettre des réponses HTTP depuis un sous-domaine dans le même eTLD+1.
Le mécanisme clé est l'attribut Domain dans les réponses Set-Cookie. Quand un serveur définit un cookie avec Domain=.example.com (ou Domain=example.com sous RFC 6265), le navigateur accepte le cookie et l'inclut dans les requêtes vers tout sous-domaine de example.com, y compris la racine. Un attaquant qui prend le contrôle de static.example.com, uploads.example.com ou tout autre sous-domaine abandonné peut émettre un cookie de session que le navigateur de la victime enverra à app.example.com ou example.com lors des requêtes suivantes — y compris la page de connexion.
Le prérequis — prise de contrôle de sous-domaine — est l'une des classes de vulnérabilités les plus régulièrement signalées dans les programmes de bug bounty. Les enregistrements DNS qui restent actifs après que le service sous-jacent a été décommissionné (GitHub Pages, Heroku, Netlify, Azure App Service, AWS S3) sont la principale source.
La réponse du sous-domaine contrôlé par l'attaquant :
-- sub.example.com contrôlé par l'attaquant sert : --
HTTP/1.1 200 OK
Content-Type: text/html
Set-Cookie: session=VALEUR_CONNUE_ATTAQUANT; Domain=.example.com; Path=/; Max-Age=86400
<html><body><p>Chargement...</p></body></html>Après connexion de la victime sur l'application principale :
POST /login HTTP/1.1
Host: app.example.com
Cookie: session=VALEUR_CONNUE_ATTAQUANT
email=victime%40example.com&password=correct
HTTP/1.1 302 Found
Location: /tableau-de-bord
-- Pas de Set-Cookie : identifiant de session non renouvelé --| Technique | Source du sous-domaine | Attribut cookie | Prévention |
|---|---|---|---|
| Prise de contrôle de sous-domaine (CNAME) | CNAME abandonné vers fournisseur cloud | Domain=.example.com | Préfixe __Host- |
| Sous-domaine expiré | Enregistrement DNS pour service décommissionné | Domain=.example.com | Préfixe __Host- |
| Sous-domaine wildcard | *.example.com + cert wildcard HTTPS | Domain=.example.com | Préfixe __Host- |
| Sous-domaine dev/staging | dev.example.com avec auth faible | Domain=.example.com | __Host- + durcissement sous-domaine |
| XSS sur sous-domaine | XSS stocké dans sub.example.com | Peut définir Domain=.example.com | HttpOnly + __Host- |
La prise de contrôle de sous-domaine est le prérequis le plus courant. Des outils comme subfinder, amass et subzy peuvent énumérer des milliers de sous-domaines en quelques minutes et identifier ceux pointant vers des ressources cloud non revendiquées. L'attaque ne nécessite pas de compromettre l'infrastructure du fournisseur cloud — seulement de revendiquer la ressource spécifique pointée par le CNAME.
HackerOne #1234231 — Tossing de cookie de sous-domaine Auth0
Une application utilisant Auth0 avec la configuration de cookie Domain=.app.example.com avait un CNAME abandonné pointant vers un service décommissionné. L'attaquant a revendiqué la ressource orpheline sur le fournisseur cloud, a servi une réponse avec Set-Cookie: auth_session=CONNU; Domain=.app.example.com, puis a attendu que les utilisateurs visitent le locataire Auth0 principal. La session non-renouvelée après le callback OAuth2 donnait un accès complet au compte. Gravité Moyenne escaladée à Haute en raison de la portée des comptes admin.
HackerOne #963569 — Fuite JSESSIONID Referer IBM ($2 500)
Le JSESSIONID était embarqué dans des URL et divulgué via les en-têtes Referer vers des scripts d'analyse tiers. Combiné avec des cookies de session Domain=.ibm.com, un fournisseur d'analyse compromis aurait pu toss des identifiants de session connus pour toute propriété *.ibm.com. La découverte a motivé un audit de portée des cookies de session.
CVE-2024-46977 — OAuth2 Gitea + contexte sous-domaine (CVSS 8.1)
Les instances Gitea déployées avec une configuration de cookie Domain=.org-domain.com étaient additionnellement exposées au tossing de sous-domaine. Les organisations utilisant Gitea avec des sous-domaines wildcard pour les référentiels d'équipe pouvaient avoir leurs cookies de session fixés depuis n'importe quel sous-domaine de référentiel d'équipe.
CVE-2024-21661 — Portée Domain des cookies Vaultwarden (CVSS 7.5)
Vaultwarden (le serveur compatible Bitwarden non officiel) avant 1.30.3 définissait les cookies de session avec un préfixe Domain=. lors d'un déploiement sous un sous-domaine (ex. vault.example.com). Cela provoquait la portée du cookie de session sur le domaine parent plutôt que sur l'hôte spécifique, permettant à tout sous-domaine du domaine de déploiement d'effectuer du cookie tossing. Une instance auto-hébergée sur vault.company.com émettait des cookies de session lisibles par tout autre service *.company.com, y compris des sous-domaines de développeurs avec des postures de sécurité plus faibles. Corrigé dans la version 1.30.3 en supprimant l'attribut Domain avec point initial et en adoptant une portée de cookie liée à l'hôte uniquement.
Paquets npm avec portée cookie Domain mal configurée — Modèle courant (2023–2025)
Plusieurs paquets de l'écosystème npm pour la gestion de session (notamment les premières versions de iron-session et certaines configurations d'adaptateurs next-auth) utilisaient par défaut une portée de cookie Domain=. lorsque l'option domain était définie avec le nom d'hôte de l'application plutôt que laissée non définie. Cela se manifestait dans des déploiements où la documentation de la bibliothèque affichait domain: process.env.DOMAIN comme exemple, amenant les utilisateurs à définir Domain=.example.com sans comprendre les implications de portée des sous-domaines. Tout sous-domaine sous le même eTLD+1 pouvait toss les cookies de session de l'application principale.
Prise de contrôle de sous-domaine + fixation de session — Pattern bug bounty Plusieurs rapports HackerOne publics (2023-2025) combinent la prise de contrôle de sous-domaine avec la fixation de session. Le pattern : (1) trouver un CNAME abandonné via subfinder/subzy, (2) revendiquer la ressource, (3) servir Set-Cookie avec Domain=.cible.com, (4) démontrer que le cookie planté est envoyé à l'application principale. Primes de 500 $ (informatif si l'app principale a HttpOnly) à 5 000 $+ quand l'ATO complet est démontré.
Domain=.example.com (point initial) dans un en-tête Set-Cookie de cookie de session est signalable indépendamment comme HIGH même quand l'application renouvelle correctement les sessions à la connexion. Le point initial permet le cookie tossing depuis n'importe quel sous-domaine et représente un échec de défense en profondeur qui élargit la surface d'attaque pour les futures compromissions de sous-domaines.
Set-Cookie de réponse pour le cookie de session. Vérifier Domain=. (point initial) ou Domain=example.com (sans préfixe de sous-domaine). Les deux configurations permettent le tossing de sous-domaine.subfinder -d cible.com -o sous-domaines.txt. Exécuter subzy run --targets sous-domaines.txt pour identifier les candidats à la prise de contrôle.Set-Cookie: cookie_test=FIXE; Domain=.cible.com depuis un sous-domaine. Visiter l'application principale et inspecter les cookies — si cookie_test=FIXE est présent, le tossing est confirmé.# Scan complet de prise de contrôle de sous-domaine
subfinder -d cible.com | tee sous-domaines.txt | httpx -silent | nuclei -t http/takeovers/
# Vérifier Domain= dans les cookies de session Set-Cookie
curl -sI https://cible.com/login | grep -i "set-cookie" | grep -i "domain="
# subzy pour la détection d'empreintes de prise de contrôle
subzy run --targets sous-domaines.txt --hide-fails --output vulnerables.txt
# modèles nuclei de prise de contrôle de sous-domaine
nuclei -l sous-domaines.txt -t http/takeovers/ -o prises-de-controle.txt__Host-Le contrôle unique le plus efficace :
# Python FastAPI — préfixe __Host- empêche complètement le tossing de sous-domaine
response.set_cookie(
key="__Host-session", # préfixe __Host- = liaison à l'hôte uniquement
value=nouveau_jeton_session,
httponly=True,
secure=True, # obligatoire pour __Host-
samesite="strict",
max_age=3600,
path="/", # obligatoire pour __Host-
# domain= DOIT être omis pour que __Host- soit valide
)// Java — préfixe __Host- via ResponseCookie (Spring)
import org.springframework.http.ResponseCookie;
ResponseCookie sessionCookie = ResponseCookie.from("__Host-session", jeton)
.httpOnly(true)
.secure(true)
.sameSite("Strict")
.path("/")
.maxAge(Duration.ofHours(1))
// .domain() intentionnellement omis — __Host- exige l'absence de domain
.build();
response.addHeader(HttpHeaders.SET_COOKIE, sessionCookie.toString());Si le préfixe __Host- ne peut pas être appliqué immédiatement :
# Supprimer l'attribut Domain — le cookie devient lié à l'hôte
response.set_cookie(
key="session",
value=jeton,
httponly=True,
secure=True,
samesite="strict",
# domain= OMIS — cookie limité à l'hôte exact uniquement
)# Auditer les enregistrements CNAME pointant vers des fournisseurs cloud
dig +short CNAME www.example.com
dig +short CNAME static.example.com
# Automatiser : comparer les cibles CNAME aux empreintes non revendiquées des fournisseurs
subfinder -d example.com | dnsx -cname | grep -E "(github\.io|heroku\.com|netlify\.app|azurewebsites\.net|s3\.amazonaws\.com)"Implémenter une surveillance TTL des enregistrements CNAME. Alerter sur tout CNAME de sous-domaine pointant vers une ressource cloud non revendiquée. Décommissionner les enregistrements DNS simultanément avec le service cloud.
Un CNAME de sous-domaine abandonné coûte environ 5 minutes à un attaquant pour être exploité à des fins de livraison de fixation de session. La prise de contrôle du sous-domaine elle-même (revendiquer un référentiel GitHub Pages ou une application Heroku) est souvent gratuite et prend moins de 10 minutes. Les organisations avec plus de 50 sous-domaines devraient mettre en place une surveillance automatisée des sous-domaines (scans périodiques subzy/nuclei) comme pratique standard.
La fixation inter-sous-domaines utilise un sous-domaine compromis ou contrôlé par un attaquant pour définir des cookies pour le domaine parent en incluant un attribut Domain=.example.com. Tout sous-domaine de example.com peut définir des cookies pour le domaine racine si ce sous-domaine peut émettre des réponses HTTP avec des en-têtes Set-Cookie. Un attaquant qui contrôle sub.example.com peut planter un identifiant de session connu dans le navigateur de la victime, qui est ensuite envoyé à example.com lors de la connexion.
La prise de contrôle de sous-domaine se produit quand un enregistrement DNS (typiquement CNAME) pointe vers un service cloud (GitHub Pages, Heroku, Netlify, Azure, AWS S3) qui a été déprovisionné. Un attaquant qui revendique la ressource sur le service cloud ciblé peut servir des réponses HTTP depuis le sous-domaine, incluant des en-têtes Set-Cookie avec des attributs Domain= ciblant le domaine parent. C'est l'une des classes de vulnérabilités les plus signalées dans les programmes de bug bounty.
Le point initial dans Domain=.example.com (spec Netscape / cookie v1) ou le Domain=example.com nu (RFC 6265) causent tous deux l'envoi du cookie par le navigateur dans les requêtes vers tous les sous-domaines et le domaine parent. Un cookie défini par sub.example.com avec Domain=.example.com est envoyé à www.example.com, api.example.com et example.com. Sans attribut Domain (ou avec le préfixe __Host-), le cookie est lié à l'hôte et ne peut pas être hérité par d'autres sous-domaines.
Oui, complètement. Le préfixe __Host- force le navigateur à n'accepter les cookies que de l'hôte exact qui a émis la réponse, sans attribut Domain, avec l'attribut Secure obligatoire, et Path=/. Un en-tête Set-Cookie avec __Host-session de sub.example.com est rejeté pour example.com. Toute application utilisant __Host- pour son cookie de session est immune à la fixation inter-sous-domaines.
Le cookie tossing est le terme général pour la technique où un sous-domaine définit des cookies pour un domaine parent. La fixation inter-sous-domaines est l'application du cookie tossing spécifiquement à la gestion de session — où le cookie envoyé est un identifiant de session. Les termes sont souvent utilisés de façon interchangeable.
Tout sous-domaine du même eTLD+1 que l'application cible est précieux. Cibles de haute valeur : sous-domaines de contenu statique (static.example.com, assets.example.com, cdn.example.com) souvent provisionnés sur des CDN externes puis oubliés. Sous-domaines 'anciens' (legacy.example.com, v1.example.com, dev.example.com) sont des candidats courants à la prise de contrôle. Tout CNAME pointant vers un fournisseur cloud où la ressource originale a été supprimée.
subzy vérifie les enregistrements DNS CNAME par rapport à une base de données d'empreintes de fournisseurs cloud permettant la revendication de ressources (GitHub Pages, Heroku, Netlify, Azure, AWS S3). Il vérifie si la ressource cible retourne une page 'non revendiquée'. Des outils comme subjack et les modèles nuclei de prise de contrôle de sous-domaine effectuent des vérifications similaires.
HSTS (includeSubDomains) empêche la livraison par interception réseau sur les sous-domaines mais n'empêche pas le cookie tossing depuis un sous-domaine légitimement possédé ou compromis. Un sous-domaine servant des réponses HTTPS peut toujours émettre des en-têtes Set-Cookie avec Domain=.example.com. HSTS ne restreint pas la portée des cookies qu'un sous-domaine peut définir — seul le préfixe __Host- y parvient.
Les règles de portée des cookies permettent à un sous-domaine de définir des cookies pour ses propres domaines ou ancêtres (Domain=.example.com). Si le cookie de session de l'application principale utilise Domain=.example.com, un sous-domaine compromis PEUT l'écraser en émettant un nouveau Set-Cookie avec le même nom et Domain=.example.com. Le préfixe __Host- l'empêche car les contraintes de nom imposent que le Set-Cookie du sous-domaine pour __Host-session serait rejeté.
Une attaque de chaîne CNAME se produit quand plusieurs enregistrements CNAME existent entre le sous-domaine et le point de terminaison cloud final. Les scanners de sécurité manquent parfois des prises de contrôle impliquant deux ou trois sauts CNAME. Des outils comme les modèles nuclei et subjack résolvent la chaîne CNAME complète pour trouver des candidats de prise de contrôle profondément imbriqués.