Host Header Injection Attack for Domain or IP

Une faiblesse de type Host Header Injection a été identifiée sur le service web. Elle consiste à pouvoir manipuler l’en-tête HTTP Host envoyé par le navigateur afin d’influencer le comportement de l’application (génération d’URL, redirections, liens dans les emails, contrôle d’accès, etc.).

Le niveau de risque réel est faible à modéré, car l’impact dépend fortement de l’usage qui est fait de cet en-tête côté serveur et côté application. Dans un scénario défavorable, cette faiblesse peut permettre de provoquer des redirections vers un domaine contrôlé par un attaquant, d’empoisonner des liens générés automatiquement (réinitialisation de mot de passe, invitations), ou d’induire des comportements inattendus lorsque l’application se base sur Host pour déterminer l’URL “officielle”. Elle ne constitue pas, à elle seule, une compromission automatique, mais peut faciliter des attaques de phishing ou des contournements logiques.

Cette alerte apparaît généralement lorsque le serveur web accepte des valeurs de Host non prévues (domaines alternatifs, valeurs arbitraires, encodages inhabituels) ou lorsque l’application fait confiance à Host pour construire des URLs ou prendre des décisions de sécurité.

Les bonnes pratiques recommandées consistent à valider strictement l’en-tête Host (liste blanche des domaines attendus), à définir un domaine canonique et à forcer les redirections vers celui-ci, ainsi qu’à éviter d’utiliser Host pour générer des liens sensibles sans contrôle. Il est également recommandé de désactiver les “catch-all” trop permissifs côté serveur web et de journaliser les valeurs de Host anormales afin de détecter des tentatives.

Après mise en œuvre de ces mesures, le service web est considéré comme conforme aux bonnes pratiques et ne présente plus de risque significatif lié à la manipulation de l’en-tête Host.

Remédiation technique (OpenResty / Nginx)

1) Liste blanche de domaines (recommandé)

Dans le server {} qui sert exemple.domaine.com, refuser tout Host inattendu :

server {
  listen 80;
  listen 443 ssl http2;
  server_name exemple.domaine.com;

  # Optionnel : refuser si Host ne correspond pas exactement
  if ($host !~* ^exemple\.domaine\.com$) { return 444; }  # 444 = drop connection (nginx)
}

2) Empêcher les vhosts “catch-all” permissifs

Ajouter un serveur par défaut qui rejette :

server {
  listen 80 default_server;
  listen 443 ssl default_server;
  return 444;
}

3) Forcer le domaine canonique

Si tu as plusieurs alias, redirige explicitement :

server {
  listen 80;
  server_name _;
  return 301 https://exemple.domaine.com$request_uri;
}

4) Côté application

• Ne pas utiliser Host / X-Forwarded-Host pour construire des URLs sensibles sans validation.

• Utiliser une base URL configurée (ex: APP_BASE_URL=https://exemple.domaine.com).

• Si reverse-proxy : n’accepter X-Forwarded-* que depuis le proxy de confiance.

5) Vérification après correction

Relancer ton outil :

headerpwn -url http://exemple.domaine.com -headers headers.txt