Utilisation réelle de l’en-tête X-Forwarded-Host?

J’ai trouvé des lectures intéressantes sur les en X-Forwarded-* têtes X-Forwarded-* , notamment la section Reverse Proxy Request Headers dans la documentation Apache, ainsi que l’article de Wikipedia sur X-Forwarded-For .

Je comprends que:

  • X-Forwarded-For donne l’adresse du client connecté au proxy
  • X-Forwarded-Port donne le port auquel le client est connecté sur le proxy (par exemple, 80 ou 443 )
  • X-Forwarded-Proto donne le protocole utilisé par le client pour se connecter au proxy ( http ou https )
  • X-Forwarded-Host donne le contenu de l’en-tête de l’ Host le client a envoyé au proxy.

Tout cela a du sens.

Cependant, je n’arrive toujours pas à comprendre un cas d’utilisation réelle de X-Forwarded-Host . Je comprends la nécessité de répéter la connexion sur un port différent ou en utilisant un schéma différent, mais pourquoi un serveur proxy changerait-il jamais l’en-tête de l’ Host lors de la répétition de la demande sur le serveur cible?

Si vous utilisez un service frontal tel qu’Apigee comme interface frontale avec vos API, vous aurez besoin de quelque chose comme X-FORWARDED-HOST pour comprendre quel nom d’hôte a été utilisé pour vous connecter à l’API, car Apigee est configuré Cela signifie que nginx et votre stack d’applications ne voient que l’en-tête Host comme nom DNS principal, et non le nom d’hôte appelé en premier lieu.

Je peux vous parler d’un problème réel, j’ai eu un problème en utilisant un portail IBM.

Dans mon cas, le problème était que le portail IBM avait un service de récupération qui récupérait une URL pour une ressource, quelque chose comme: {“url”: ” http://internal.host.name/path “}

Qu’est-il arrivé? Simple, lorsque vous entrez depuis l’intranet, tout fonctionne correctement car internalHostName existe mais … lorsque l’utilisateur entre par Internet, le proxy ne peut pas résoudre le nom d’hôte et le portail se bloque.

Le correctif pour le portail IBM consistait à lire l’en-tête X-FORWARDED-HOST, puis à modifier la réponse en quelque chose comme: {“url”: ” http://internet.host.name/path “}

Voir que je mets internet et non interne dans la seconde réponse.

C’est le scénario sur lequel j’ai travaillé aujourd’hui: les utilisateurs accèdent à certains serveurs d’applications à l’aide de l’URL ” https://neaturl.company.com ” qui pointe sur Reverse Proxy. Le proxy met ensuite fin à SSL et redirige les demandes des utilisateurs vers le serveur d’applications réel dont l’URL est ” http://192.168.1.1:5555 “. Le problème est que lorsque le serveur d’applications devait redirect l’utilisateur vers une autre page du même serveur en utilisant le chemin absolu, il utilisait cette dernière URL et les utilisateurs n’y avaient pas access. L’utilisation de X-Forwarded-Host (+ X-Forwarded-Proto et X-Forwarded-Port) permettait à notre proxy d’indiquer au serveur d’application l’utilisateur URL utilisé à l’origine et donc le serveur pour générer le chemin absolu correct dans ses réponses.

Dans ce cas, il n’existait aucune option pour arrêter le serveur d’applications afin qu’il génère des URL absolues, ni pour le configurer manuellement pour «URL publique».

Un exemple pourrait être un proxy qui bloque certains hôtes et les redirige vers une page de blocage externe. En fait, je suis presque certain que mon filtre scolaire le fait…

(Et la raison pour laquelle ils peuvent ne pas simplement transmettre l’ Host origine en tant Host est que certains serveurs [Nginx?] Rejettent tout trafic vers le mauvais Host .)

Pour le besoin de «x-forwarded-host», je peux imaginer un scénario d’hébergement virtuel dans lequel il existe plusieurs hôtes internes (réseau interne) et un proxy inverse entre ces hôtes et Internet. Si l’hôte demandé fait partie du réseau interne, l’hôte demandé se résout à l’adresse IP du proxy inverse et le navigateur Web envoie la demande au proxy inverse. Ce proxy inverse recherche l’hôte interne approprié et transfère la demande envoyée par le client à cet hôte. Ce faisant, le proxy inverse modifie le champ hôte pour correspondre à l’hôte interne et définit l’hôte x-forward-hôte sur l’hôte réel demandé par le client. Plus de détails sur le proxy inverse peuvent être trouvés dans cette page wikipedia http://en.wikipedia.org/wiki/Reverse_proxy .

Consultez cet article pour plus de détails sur l’en-tête x-forwarded-for et un simple script de démonstration Python qui montre comment un serveur Web peut détecter l’utilisation d’un serveur proxy: x-forwarded-for expliqué

X-Forwarded-Host vient de sauver ma vie. Les CDN (ou proxy inverse si vous souhaitez passer aux “arbres”) déterminent l’origine à utiliser par l’en-tête de l’hôte avec lequel un utilisateur accède. Ainsi, un CDN ne peut pas utiliser le même en-tête Host pour contacter l’origine – sinon, le CDN irait à lui-même dans une boucle plutôt que d’aller à l’origine. Ainsi, le CDN utilise l’adresse IP ou un nom de domaine complet fictif comme en-tête de l’hôte pour récupérer le contenu de l’origine. Maintenant, l’origine peut vouloir savoir quelle était l’en-tête de l’hôte (nom du site Web) que le contenu est demandé. Dans mon cas, une origine a servi 2 sites Web.

Dans un autre scénario, vous atsortingbuez une licence à votre application à une URL hôte, puis vous souhaitez charger le solde sur n> 1 serveurs.