32. Host, Forwarded et confiance des mandataires

Comprendre le mécanisme

Un reverse proxy peut transmettre l’hôte, le schéma ou une adresse d’origine au serveur applicatif. Des champs comme Forwarded ou des variantes historiques X-Forwarded-* ne doivent pas être crus simplement parce qu’ils sont présents. Si le client externe peut fournir la même information sans être neutralisé, l’application risque de générer de mauvais liens, de journaliser une fausse origine ou d’appliquer une décision fondée sur une entrée hostile.

Raisonner et vérifier

Configurez explicitement les mandataires de confiance et les champs qu’ils reconstruisent. Distinguez connexion observée par PHP et connexion externe terminée en TLS au frontal. Utilisez une origine publique de confiance pour les liens sensibles lorsque le besoin s’y prête. Testez les accès directs à l’application et le passage normal par le proxy ; une configuration correcte suppose aussi que les chemins non prévus sont bornés.

Provenance

Forwarded est une donnée à interpréter selon sa provenance. Un client peut envoyer un champ de ce nom. Un client direct peut envoyer Forwarded avec proto=https ou une fausse IP. La valeur n’est fiable que dans une chaîne où son producteur et le nettoyage des entrées externes sont maîtrisés.

Proxies admis

Les adresses de proxies admis doivent être maîtrisées. L’affirmation reçue ne prouve pas l’émetteur. Configurez des adresses ou réseaux de confiance correspondant à l’infrastructure réelle. Une confiance globale peut permettre à tout appelant d’influencer des décisions fondées sur des métadonnées supposées internes.

Nettoyage

Le proxy peut supprimer et reconstruire les champs attendus. Une chaîne fiable demande une politique de frontière. Le proxy d’entrée peut supprimer les headers clients concernés puis reconstruire les valeurs fiables. Vérifiez cette règle et les accès directs éventuels au backend, qui pourraient contourner cette frontière.

Schéma perçu

Le schéma perçu influence les URL générées. Les composants peuvent utiliser cette information pour générer des URL. Le schéma reconstruit influence cookies Secure, redirections et URL absolues. Derrière une terminaison TLS, une mauvaise configuration peut produire des liens HTTP ou des boucles sans que le navigateur utilise ce schéma initialement.

Host

Le Host doit suivre les contraintes du service. Une entrée hostile peut influencer des URL et décisions. Un lien de réinitialisation construit depuis un Host libre peut viser un domaine contrôlé par l’appelant. Limitez les hôtes du service et utilisez un contexte maîtrisé pour générer les liens sensibles.

Adresse et quotas

La confiance trop large peut affecter la limitation par IP. Un émetteur peut alors influencer l’identité réseau perçue. Un attaquant qui choisit une fausse IP annoncée peut contourner un quota naïf. Définissez quelle adresse représente le client selon la chaîne réelle et testez accès direct et accès via proxy.

Topologie testée

Le trajet réel doit être reproduit dans les tests. Le chemin peut transformer les métadonnées. Reproduisez les sauts, terminaisons et headers dans l’environnement de vérification. Un test direct sur localhost ne démontre pas que la reconstruction d’identité réseau fonctionne derrière le proxy hébergé.

Réseaux évolutifs

Les réseaux de confiance peuvent évoluer. La configuration doit suivre l’infrastructure réelle. Des adresses d’intermédiaires peuvent changer lors d’une migration. Prévoyez la maintenance et la validation régulière de la liste admise ; une ancienne plage trop large peut conserver une confiance inutile.

Trajet interne

Le transport interne demande sa propre vérification. La terminaison TLS marque une frontière de protection. TLS au frontal ne démontre pas le chiffrement entre proxy et application. Vérifiez réseau, authentification et transport de ce segment selon les données et les capacités qu’il transporte.

Corrélation

La corrélation ne doit pas divulguer les secrets. Des métadonnées minimisées peuvent suffire au diagnostic. Transmettez des identifiants de trace non sensibles et validés. Ne faites pas voyager cookies ou bearer tokens dans un identifiant de diagnostic pour faciliter le rapprochement des journaux.

Atelier guidé : lire, expliquer et vérifier le code

Forwarded: for=192.0.2.42;proto=https;host=portal.example.test

La ligne Forwarded contient une adresse et un schéma, mais aucune preuve de son producteur. Décrivez les conditions nécessaires pour les accepter : proxy admis, nettoyage des valeurs externes et impossibilité de contourner ce trajet. Vérifiez ensuite les liens générés et la limitation par IP.

Le nom ne protège pas sa provenance. Le serveur doit lier ces métadonnées à un producteur admis. La déclaration client n’observe pas tout le trajet. Le champ ne vérifie pas une identité.

Travail pratique : Simulez un champ d’origine falsifié depuis le client, puis vérifiez les liens générés et les attributs de cookies derrière le proxy de laboratoire.

Critères de correction : Comparez requête directe et requête relayée. Vérifiez les champs effectivement reconstruits, les proxys déclarés et la génération d’URL. Confirmez qu’un appelant non autorisé ne peut pas choisir l’origine d’un lien sensible.