Qu’est-ce que les attaques d’en-tête d’hôte HTTP ?
Les attaques d’en-tête d’hôte HTTP sont devenues très prisées des hackers et présentent plusieurs variantes. Avant de nous y intéresser davantage, commençons par expliquer ce qu’est un en-tête d’hôte HTTP.
Qu’est-ce qu’un en-tête d’hôte HTTP ?
Un en-tête d’hôte HTTP fournit des informations sur l’hôte et le port et aide les serveurs d’origine à déterminer quelles ressources utiliser lorsqu’ils traitent des requêtes pour plusieurs domaines.
Autres en-têtes d'hôte
Parfois, les applications complètent un en-tête d’hôte avec des en-têtes supplémentaires similaires, tels que « X-Forwarded-Host », « X-Host » et d’autres variantes. Nous les utiliserons dans certaines descriptions d’attaques ci-dessous, car ils sont aussi vulnérables que l’en-tête d’hôte si ils sont mal utilisés.
Les types d’attaques d’en-tête d’hôte HTTP
L’en-tête d’hôte est une partie critique de l’utilisation d’Internet, mais les applications s’exposent à des vulnérabilités lorsque l’en-tête d’hôte est implicitement fiable, utilisé pour des fonctionnalités supplémentaires ou mal configuré. Les hackers peuvent exploiter ce comportement en injectant différents types de contenu dans l’en-tête d’hôte, conduisant alors à des vulnérabilités plus graves, notamment :
Empoisonnement de l'en-tête Host
Empoisonnement du cache Web
Empoisonnement de la réinitialisation du mot de passe
Falsification de requête côté serveur
Selon la manière dont une application utilise les valeurs fournies par l’en-tête d’hôte, elle pourrait également permettre d’autres attaques telles que le cross-site scripting ou l’injection SQL, tout comme n’importe quelle autre entrée fournie par l’utilisateur pourrait le faire si elle n’était pas traitée de manière sécurisée. Pour l’instant, supposons que vous n’utilisez pas l’en-tête d’hôte dans les requêtes SQL brutes et que nous couvrons les attaques plus directes.
1. Empoisonnement de l'en-tête Host
Dans les cas les plus simples, une application peut utiliser la valeur de l’en-tête d’hôte pour rediriger le trafic, par exemple vers la page de connexion de l’application. Si l’application utilise l’en-tête d’hôte pour créer un lien de redirection, un hacker peut envoyer la requête HTTP suivante :
GET / HTTP/1.1
Host: www.attackers-domain.example.com
Et générer une réponse de redirection vers son domaine contrôlé :
HTTP/1.1 302 Found
...
Location: http://www.attackers-domain.example.com/login.php
Seule, cette attaque n’est pas très utile puisqu’il est difficile d’amener un utilisateur ciblé à effectuer cette requête. Cependant, l’empoisonnement de l’en-tête d’hôte peut être combiné à d’autres attaques pour en augmenter l’efficacité.
2. Empoisonnement du cache web
L’empoisonnement du cache web n’est pas une vulnérabilité de l’en-tête d’hôte en soi, mais un mécanisme de distribution qui rend l’empoisonnement de l’en-tête d’hôte susmentionné exploitable. Supposons qu’une application n’utilise pas l’en-tête d’hôte pour créer ses liens de redirection (bien !) mais qu’elle utilise un autre en-tête tel que X-Host pour les créer (pas bien !). Dans ce scénario, un hacker peut alors injecter son domaine dans X-Host pour empoisonner la redirection. Cependant, il doit encore trouver un moyen de livrer cette redirection aux utilisateurs.
C’est là qu’intervient l’empoisonnement du cache web. Les caches web utilisent généralement des parties d’une requête HTTP comme « clés » pour savoir quand utiliser le contenu du cache plutôt que d’envoyer la requête à l’origine. Cette clé inclut généralement l’en-tête d’hôte et peut inclure d’autres en-têtes. Dans notre exemple, si X-Host ne fait pas partie de la clé du cache mais est utilisé de manière non sécurisée dans la réponse (comme dans notre exemple de redirection), les hackers peuvent utiliser le cache pour livrer aux autres utilisateurs leur redirection malveillante. Le hacker trouve alors un moyen de faire mettre sa requête en cache pour la servir à d’autres utilisateurs.
Examinons un exemple d’empoisonnement du cache web. Tout d’abord, le hacker obtient la requête suivante mise en cache, qui inclut son domaine malveillant dans l’en-tête X-Host, et qui sera utilisée dans une redirection :
GET / HTTP/1.1
Host: www.super-cool-fun-domain.example.com
X-Host : www.attackers-domain.example.com
Un utilisateur légitime décide alors de se rendre sur l’application, en envoyant une requête standard :
GET / HTTP/1.1
Host: www.super-cool-fun-domain.example.com
X-Host: www.super-cool-fun-domain.example.com
En supposant que la requête du hacker ait été mise en cache en fonction du chemin et de l’en-tête d’hôte, l’utilisateur légitime reçoit maintenant la réponse empoisonnée mise en cache, le redirigeant vers la page du hacker :
HTTP/1.1 302 Found
...
Location: http://www.attackers-domain.example.com/login.php
Les attaques par empoisonnement du cache web reposent sur la discordance entre les en-têtes utilisés comme clé de cache et les en-têtes utilisés par l’application pour formuler les réponses. Dans l’exemple ci-dessus, l’en-tête X-Host a permis d’empoisonner les réponses mises en cache, redirigeant des utilisateurs vers un site malveillant au lieu de l’application légitime.
3. Empoisonnement de la réinitialisation du mot de passe
L’empoisonnement de la réinitialisation du mot de passe est très similaire à l’attaque d’empoisonnement de l’en-tête d’hôte, dans la mesure où l’application vulnérable utilise l’en-tête d’hôte pour créer le lien de réinitialisation du mot de passe qu’elle envoie à l’utilisateur demandé pendant le processus de réinitialisation. Par exemple, supposons qu’un hacker envoie la requête POST suivante pour demander une réinitialisation du mot de passe pour l’utilisateur « alice » :
POST /password-reset HTTP/1.1
Host: www.attackers-domain.example.com
...
user=alice
L'application utilise la valeur de l'en-tête Host pour construire le lien de réinitialisation et envoie un courriel à l'utilisateur alice avec le lien :
www.attackers-domain.example.com?reset_token=super-random-reset-token-value-12345
Si l’utilisateur clique sur le lien, le hacker capture le jeton de réinitialisation et peut réinitialiser le mot de passe de l’utilisateur avec la valeur de son choix.
4. Falsification de requête côté serveur
La falsification de requête côté serveur (SSRF) est une vulnérabilité qui permet à un hacker de forcer l’application côté serveur à envoyer des requêtes vers un emplacement arbitraire. Dans une attaque SSRF d’en-tête d’hôte, le hacker exploite le routage utilisé par les systèmes situés entre l’utilisateur et l’application côté serveur. Si ce middleware (par exemple, un équilibreur de charge) est vulnérable à la SSRF d’en-tête d’hôte, le hacker peut potentiellement l’utiliser pour interagir avec des systèmes internes auxquels il n’aurait autrement pas accès. Un moyen courant de tester cela est de placer un domaine unique et contrôlé (par exemple, Burp Collaborator de Portswigger ou interactsh de ProjectDiscovery) dans la valeur de l’en-tête d’hôte. Si ce domaine unique reçoit une requête DNS ou une autre requête d’un système sur le chemin réseau des applications ciblées (par exemple, l’équilibreur de charge) lors d’une attaque d’en-tête d’hôte, il pourrait être vulnérable à une attaque SSRF. Ces attaques ont tendance à être complexes dans la pratique mais aussi dévastatrices, comme l’ont démontré de manière approfondie les recherches de James Kettle.
Exemples concrets d'attaques par en-tête HTTP Host
Passons maintenant à quelques exemples concrets.
CVE-2022-29933 : empoisonnement de la réinitialisation du mot de passe dans Craft CMS
SEC Consult a découvert que l’installation par défaut de Craft CMS construit des e-mails de réinitialisation de mot de passe en utilisant la valeur de l’en-tête HTTP « X-Forwarded-Host ». Dans cet exemple, un hacker injecte son domaine contrôlé dans la valeur X-Forwarded-Host pour empoisonner le lien de réinitialisation du mot de passe de l’utilisateur alice, comme suit :
POST /index.php?p=admin/actions/users/send-password-reset-email HTTP/1.1
Host: <installation-domain>
X-Forwarded-Host: www.attackers-domain.example.com
...
Cookie: CRAFT_CSRF_TOKEN=[...]
loginName=alice@example.com
Lorsque l’utilisateur alice@example.com reçoit son e-mail de réinitialisation du mot de passe, il contient un lien vers le domaine contrôlé par le hacker :
http://www.attackers-domain.example.com/index.php?p=admin/set-password&code=<reset-code>&id=<uuid>
Si l’utilisateur suit le lien, le hacker a maintenant capturé son code de réinitialisation et peut réinitialiser son mot de passe pour prendre le contrôle du compte.
SSRF à l'aveugle dans Slack via une injection X-Forwarded-Host
Cette attaque contourne la validation faible de X-Forwarded-Host pour réaliser une SSRF aveugle sur files.slack.com. Dans un premier temps, files.slack.com tente de valider l’en-tête d’hôte et l’en-tête X-Forwarded-Host lors du traitement, en renvoyant un code de réponse HTTP 500 lorsqu’ils ne sont pas files.slack.com. Cependant, la validation de X-Forwarded-Host peut être contournée en ajoutant un caractère @ à la fin du domaine. Ainsi, le hacker configure un domaine de rappel pour capturer les requêtes (par exemple avec Burp Collaborator, interactsh de ProjectDiscovery) et envoie la requête suivante à files.slack.com :
GET /<URI> HTTP/1.1
Host: files.slack.com
...
X-Forwarded-Host: files.slack.com@www.unique-attackers-domain.example.com
Le fichier files.slack.com figurant dans l’URL créée à partir de l’en-tête X-Forwarded-Host est traité en tant qu’utilisateur HTTP (HTTP BasicAuth). Le site www.unique-attackers-domain.example.com, lui, est traité en tant que nom d’hôte. Le hacker reçoit une requête d’un système en back-end confirmant la réussite de l’attaque SSRF. Ensuite, différentes techniques d’attaque SSRF à l’aveugle peuvent être déployées pour tenter de divulguer des informations, d’interagir avec les systèmes en back-end, etc.
Comment prévenir les attaques d’en-tête d’hôte HTTP
Il existe plusieurs solutions pour éviter les attaques d’en-tête d’hôte HTTP, avec différents inconvénients et degrés d’efficacité. Retrouvez ci-dessous des solutions concrètes pour prévenir ce type d’attaque.
Évitez d’utiliser la valeur de l’en-tête d’hôte et ses variantes dans le code de l’application
Le moyen le plus simple de prévenir les attaques d’en-tête d’hôte est d’éviter d’utiliser la valeur de l’en-tête d’hôte dans le code de votre application. En outre, l’utilisation de configurations côté serveur ou d’URL relatives permettra de contrecarrer complètement les attaques d’en-tête d’hôte.
Effectuez une validation stricte des valeurs de l'en-tête Host
Si vous devez utiliser la valeur de l’en-tête d’hôte, employez les techniques suivantes pour ne pas subir d’attaque :
Assurez-vous que l’en-tête d’hôte figure dans une liste de valeurs autorisées. Par exemple, si votre application n’utilise que trois domaines, assurez-vous que l’en-tête d’hôte corresponde uniquement à l’une de ces trois valeurs.
Vérifiez qu’il n’y a qu’un seul en-tête d’hôte. Les en-têtes d’hôte dupliqués peuvent parfois être utilisés pour contourner la validation, si la validation et l’utilisation de l’en-tête finissent par extraire des valeurs différentes de la requête.
Évitez d’utiliser des alternatives et des remplacements d’en-tête d’hôte tels que X-Host ou X-Forwarded-Host, et si vous devez le faire, suivez les mêmes recommandations fournies pour l’en-tête d’hôte.
Comment Fastly aide à prévenir les attaques d'en-tête Host HTTP
Suivez le guide de Fastly sur la prévention des empoisonnements du cache pour vous assurer que des protections supplémentaires sont en place.
Si vous utilisez le pare-feu d’application web de nouvelle génération de Fastly, vous pouvez ajouter des protections supplémentaires pour vous protéger des attaques d’en-tête d’hôte HTTP afin de bloquer toutes les requêtes contenant un en-tête d’hôte non valide (par exemple, celles qui ne figurent pas dans votre liste de domaines autorisés).
Résumé
L’en-tête d’hôte est une composante essentielle d’Internet (et de Fastly), mais lorsqu’il est implicitement fiable, utilisé pour des fonctionnalités supplémentaires ou mal configuré, les hackers peuvent exploiter ce comportement en y injectant différents types de contenus malveillants. Cela peut ouvrir les portes à plusieurs types d’attaques, y compris l’empoisonnement de l’en-tête d’hôte, l’empoisonnement du cache web, l’empoisonnement de la réinitialisation du mot de passe et la falsification des requêtes côté serveur (SSRF). Grâce aux solutions que nous avons décrites, combinées aux conseils de Fastly pour prévenir l’empoisonnement du cache, vous pouvez éviter à vos applications d’être victimes des variantes d’attaques d’en-tête d’hôte.
En savoir plus sur les fonctions de sécurité de Fastly
