La protection contre le DNS rebinding exige une résolution à l'exécution

Une approbation pour api.example.test n'est pas une approbation pour toute adresse que ce nom renverra plus tard. Si un agent peut effectuer une requête HTTP authentifiée, le DNS rebinding transforme une décision obsolète sur un nom d'hôte en route vers un service local, un endpoint de métadonnées cloud ou un plan de contrôle interne. L'injection d'identifiants peut fonctionner exactement comme prévu. C'est la décision sur la destination qui a échoué.

J'ai vu des équipes créer des écrans d'approbation soignés, puis laisser la bibliothèque HTTP résoudre le nom au tout dernier moment sans vérifier la réponse. Cette faille est facile à manquer, car le DNS ordinaire se comporte correctement. Un attaquant n'a pas besoin que le DNS ordinaire coopère. Il lui faut un nom qu'il contrôle, une courte durée de cache et un client qui confond un nom d'hôte avec une destination permanente.

La protection contre le DNS rebinding exige une résolution au moment de l'exécution. Résolvez juste avant d'ouvrir la connexion, examinez l'ensemble de la réponse, sélectionnez une adresse autorisée et connectez-vous précisément à cette adresse. Conservez le nom d'hôte d'origine pour HTTP et la validation TLS. Recommencez chaque fois que le client ouvre une autre connexion, suit une redirection ou change de protocole.

L'approbation désigne une catégorie de destination, pas une adresse IP pour toujours

Un nom d'hôte est une instruction de résolution, pas une identité stable pour un pair réseau. Cette distinction semble pointilleuse jusqu'à ce qu'un agent reçoive une URL depuis un ticket, un journal de build, une réponse d'outil ou un autre service. L'agent peut demander l'autorisation d'appeler reports.partner.test ; la personne qui approuve voit une destination publique plausible. Quelques minutes plus tard, le même nom peut renvoyer 127.0.0.1, une adresse de bouclage IPv6 ou une adresse accessible uniquement depuis le réseau de la machine.

La séquence habituelle de rebinding comporte deux phases. Durant la première, le serveur DNS faisant autorité renvoie une adresse publique. Le client ou le relecteur accepte le nom d'hôte, parfois après une requête de pré-vol semblable à celle d'un navigateur. Durant la seconde, l'attaquant modifie la réponse et compte sur l'expiration, une reconnexion, une redirection, une nouvelle tentative ou une seconde requête pour déclencher une autre résolution. Le service cible voit une requête provenant d'une machine locale, à laquelle les pare-feu réseau accordent souvent davantage d'accès qu'à l'internet public.

Une passerelle d'agents présente une version plus aiguë de ce problème. Elle peut ajouter un jeton bearer, des identifiants basic ou un en-tête d'autorisation personnalisé uniquement après qu'une personne a approuvé l'action. Si la passerelle vérifie le processus de l'agent mais pas l'adresse du pair, elle peut transmettre un identifiant légitime au mauvais endroit. Une requête vers un service d'administration local peut ne pas avoir besoin de l'identifiant. L'attaquant peut utiliser la requête seulement pour faire lire à la machine une réponse que l'agent pourra ensuite recevoir.

Ne résolvez pas ce problème en enregistrant pour toujours la première adresse IP résolue. Les services publics utilisent l'équilibrage de charge, des changements d'adresse et IPv6. L'affirmation sûre est plus restreinte : chaque connexion doit utiliser une adresse qui a passé la validation au moment où cette connexion a commencé. Une approbation antérieure peut autoriser le nom d'hôte et l'utilisation de l'identifiant. Elle ne peut pas justifier une adresse ultérieure qui appartient à un réseau bloqué.

Résolvez juste avant l'ouverture du socket

L'ordre des opérations détermine si le contrôle a le moindre sens. Résolvez le nom d'hôte, validez la réponse du résolveur, choisissez une adresse et transmettez directement cette adresse à la routine de connexion. Si vous validez une adresse puis appelez une API pratique qui résout de nouveau le nom d'hôte, vous avez vérifié une destination et vous vous êtes connecté à une autre.

Conservez quatre valeurs distinctes tout au long de la requête :

• origin_host est le nom d'hôte approuvé par l'utilisateur et que le certificat doit couvrir.
• peer_ip est l'unique adresse validée choisie pour ce socket.
• port est le port demandé après application par le client de ses règles sur les ports autorisés.
• scheme détermine si le client exige TLS.

Pour HTTPS, connectez le socket TCP à peer_ip, mais envoyez origin_host comme en-tête HTTP Host et utilisez origin_host pour SNI et la vérification du certificat. Un certificat associé à l'adresse IP ne suffit pas. Si le certificat ne correspond pas au nom d'hôte, faites échouer la requête. Désactiver la validation des certificats pour faciliter le pinning d'adresse remplace un problème de routage par un autre, bien plus grave.

Une frontière de connexion minimale peut ressembler à ceci :

origin_host = parse_url(request_url).host
answers = resolver.lookup_all(origin_host)
allowed = [ip for ip in answers if public_routable(ip)]
if allowed is empty:
    fail("DNS answer contains no permitted address")

peer_ip = choose_one(allowed)
socket = tcp_connect(peer_ip, request_port)
tls = tls_handshake(socket, server_name=origin_host, verify_name=origin_host)
send_http(tls, host_header=origin_host)

Cet exemple emploie volontairement lookup_all. Une recherche d'adresse unique masque une défaillance courante : le résolveur renvoie à la fois une adresse IPv4 publique autorisée et une adresse de bouclage IPv6. Une bibliothèque peut préférer IPv6 même si l'application n'a examiné qu'IPv4. Rejetez le nom d'hôte lorsqu'une réponse est bloquée, ou définissez une règle de sélection stricte qui ne transmet que des adresses validées au connecteur. Rejeter les réponses mixtes est plus simple à auditer et laisse moins de possibilités à un attaquant d'exploiter le comportement de course entre connexions.

Le mot « immédiatement » compte. Résolvez avant l'ouverture du socket, pas lorsque l'agent prépare une requête, pas quand la carte d'approbation s'affiche, ni lorsque l'utilisateur enregistre un identifiant. Un court intervalle subsiste entre la résolution et la connexion, mais le client a déjà sélectionné une adresse et n'a pas besoin de redemander au DNS pour ce socket.

Le filtrage IPv4 privé n'est que la première barrière

La RFC 1918 réserve des plages IPv4 aux réseaux privés. Elle définit trois blocs connus : 10.0.0.0/8, 172.16.0.0/12 et 192.168.0.0/16. Les bloquer est nécessaire pour un client tourné vers internet, mais considérer cette liste comme toute la défense est une erreur fréquente et coûteuse.

Un filtre de destination doit rejeter les catégories d'adresses qu'on ne peut pas traiter sans risque comme publiques. Rejetez au minimum les adresses de bouclage, non spécifiées, link-local, multicast, privées et les adresses locales uniques IPv6. Rejetez les formes IPv6 mappées IPv4 après les avoir normalisées, car ::ffff:127.0.0.1 reste en pratique une adresse de bouclage. Considérez les identifiants de zone IPv6 comme invalides pour les URL distantes. Ne laissez pas l'orthographe textuelle déterminer la sûreté : analysez l'adresse sous forme binaire et classez-la à ce stade.

Certaines plages nécessitent une décision produit explicite plutôt qu'un réglage par défaut accidentel. Les adresses NAT de niveau opérateur dans 100.64.0.0/10 ne sont pas joignables globalement. Les plages de documentation et de benchmarking ne doivent pas apparaître comme destinations de production ordinaires. La plage IPv4 link-local peut atteindre des services de métadonnées dans certaines configurations cloud. Les adresses IPv6 link-local exigent une portée d'interface et ne devraient jamais provenir d'une requête de nom d'hôte public. Le réglage le plus sûr pour une passerelle d'actions externe consiste à n'autoriser que les adresses unicast globales ordinaires, avec des exceptions nommées pour un mode de déploiement interne distinct.

N'utilisez pas de vérification de préfixe de chaîne. 127.1, 127.0.0.1, les formats entiers acceptés par un analyseur permissif, la compression IPv6 et les formes mappées la rendent peu fiable. Analysez l'hôte de l'URL comme un nom DNS ou un littéral IP. S'il s'agit d'un littéral IP, classez-le directement. S'il s'agit d'un nom DNS, résolvez-le et classez chaque adresse renvoyée. Rejetez les noms malformés avant la résolution.

C'est aussi ici que les équipes confondent DNS public et joignabilité publique. Un résolveur peut renvoyer une adresse publique qui passe par un proxy d'entreprise, un VPN ou un chemin réseau à horizon partagé. La réponse DNS est une donnée parmi d'autres, pas une promesse sur l'ensemble de la route. Le filtrage d'adresses bloque le rebinding direct vers des plages locales évidentes. Les règles de sortie réseau doivent toujours bloquer les chemins d'accès que l'hôte peut atteindre mais que le produit ne doit pas utiliser.

Les CNAME et les réponses mixtes exigent une décision unique

Un CNAME ne rend pas un nom sûr. Il délègue la réponse finale à un autre nom, qui peut lui aussi changer ou renvoyer un ensemble de réponses mixtes. Le résolveur suit normalement cette chaîne avant de donner à l'application des enregistrements A et AAAA, l'application doit donc juger les adresses finales qu'elle reçoit. Si l'API du résolveur expose la chaîne, journalisez-la pour le diagnostic, mais ne fondez pas le contrôle sur le fait que le premier nom semblait familier.

Une règle par défaut solide est simple : si une réponse finale pour un nom d'hôte demandé appartient à une catégorie bloquée, rejetez la requête. Cela peut rejeter un service qui publie une adresse privée inaccessible à côté d'une adresse publique, mais cette configuration crée déjà des clients imprévisibles. Une passerelle qui envoie des identifiants devrait demander au propriétaire du service de corriger l'enregistrement DNS plutôt que de choisir silencieusement une réponse qui l'arrange.

Certaines équipes préfèrent « utiliser n'importe quelle réponse autorisée ». Cette règle est populaire parce qu'elle maintient davantage d'intégrations en état de marche. Elle crée aussi des comportements difficiles à reproduire : un ordre de résolveur fonctionne, un autre se connecte quelque part de bloqué, et une implémentation Happy Eyeballs lance les tentatives IPv6 et IPv4 à des moments différents. Si vous choisissez cette voie, la couche de connexion ne doit recevoir que les adresses autorisées sélectionnées et ne doit jamais revenir au nom d'hôte d'origine. Une bibliothèque HTTP générique ne vous donne souvent pas cette garantie.

Enregistrez suffisamment d'éléments pour expliquer un rejet. Le journal de requêtes doit inclure le nom d'hôte d'origine, le port, l'ensemble des adresses résolues, l'adresse de pair sélectionnée s'il y en a une, le résultat de la politique et un identifiant de corrélation de requête. Ne journalisez pas les identifiants ni les corps de réponse uniquement pour simplifier le débogage. Les échecs de sécurité DNS sont généralement clairs à partir de la seule liste d'adresses.

Les pools de connexions ne sont sûrs que s'ils préservent le pair

Une connexion TLS réutilisée n'effectue pas une nouvelle résolution DNS et n'en a pas besoin. Le socket possède déjà une adresse de pair choisie et validée à son ouverture. Un client peut réutiliser cette connexion précise pour une autre requête vers la même origine si les règles HTTP habituelles sur les origines et les vérifications de certificat le permettent.

Une nouvelle connexion est différente. Les pools masquent souvent des reconnexions après un délai d'inactivité, une défaillance de transport, une limite de flux HTTP/2 ou un changement d'état du proxy. Si le pool demande à nouveau au système d'exploitation de se connecter par nom d'hôte, il rouvre la fenêtre de rebinding. Placez le résolveur et le connecteur sous le pool, pas à côté de la première requête.

Le regroupement de connexions demande de la prudence. HTTP/2 peut réutiliser une connexion TLS pour plus d'un nom d'hôte lorsque le certificat les couvre et que le pair convient. Un navigateur généraliste peut accepter ce compromis. Une passerelle d'actions doit rendre explicite la décision de destination pour chaque origine. Ne supposez pas qu'un socket ouvert pour un nom d'hôte approuvé peut transporter une requête avec identifiants pour un autre uniquement parce que le certificat liste les deux noms. La portée de l'approbation, l'autorité HTTP et la réutilisation de connexion sont des décisions distinctes.

Les nouvelles tentatives suivent la même logique. Une nouvelle tentative après un échec de connexion est une nouvelle tentative sortante. Résolvez de nouveau, reclassifiez, sélectionnez une adresse et ouvrez un nouveau socket. Ne mettez jamais en cache un résultat autorisé plus longtemps que la connexion qu'il a autorisée. Vous pouvez mettre brièvement en cache les résultats bloqués pour réduire le travail répété, mais ne transformez pas ce cache en autorité de routage non examinée.

Les changements en cours d'appel ne permettent pas à un attaquant de déplacer une connexion TCP établie vers une nouvelle IP. TCP a déjà choisi son pair. Le danger vient du chemin de code qui crée une connexion de remplacement, suit une redirection, met à niveau un protocole ou émet une autre requête après la première réponse. Ne tester qu'une requête réussie ignore les chemins utilisés par les clients de production sous charge.

Les redirections sont des requêtes sortantes distinctes

Une redirection change l'URI cible. Traitez-la comme une nouvelle action, même si la bibliothèque HTTP la considère comme une fonction pratique. Analysez la valeur Location, rejetez les schémas non pris en charge, résolvez son nom d'hôte au moment de l'exécution, validez ses réponses et contrôlez son port avant la connexion. Transférer automatiquement les en-têtes d'autorisation lors d'un changement d'origine est un autre bug de fuite d'identifiants, retirez-les donc sauf si la nouvelle origine possède sa propre décision d'autorisation explicite.

Limitez les redirections à un petit nombre fixe. Un serveur de test de rebinding peut faire tourner les noms et les réponses à chaque saut, et des redirections illimitées transforment une simple action sortante en chaîne opaque. Journalisez chaque saut avec l'origine source, l'origine de destination, l'ensemble d'adresses, le pair sélectionné, le code d'état et la raison de tout rejet.

Les contrôles DNS concernent aussi des fonctions de protocole faciles à oublier. Un proxy HTTP modifie le destinataire de la connexion TCP initiale, validez donc l'adresse du proxy puis définissez ce que le proxy peut résoudre. Sinon, un tunnel CONNECT peut déplacer la résolution du nom d'hôte vers un composant qui n'applique pas les mêmes contrôles. Les webhooks, URL de rappel, endpoints de stockage d'objets et registres de paquets méritent tous le même traitement lorsqu'un agent peut influencer leur destination.

Une règle qui bloque les réponses DNS privées ne rend pas des URL arbitraires sûres. Elle n'empêche pas un serveur public d'émettre une commande dangereuse, de renvoyer une réponse énorme ou de rediriger vers un service approuvé mais hostile. La défense contre le DNS rebinding est une frontière parmi d'autres. Elle doit être suffisamment précise pour que personne ne la prenne pour un langage de politique généraliste.

Testez le résolveur et le connecteur comme une seule unité

Les tests unitaires qui transmettent 127.0.0.1 à un classificateur d'adresses sont nécessaires, mais insuffisants. L'échec se produit quand le client transmet un nom d'hôte à travers plusieurs couches et qu'une couche effectue une résolution sans protection. Vos tests doivent observer la destination réelle du socket.

Créez une zone de test faisant autorité et contrôlée avec un nom tel que flip.test. Lors de sa première résolution, renvoyez un endpoint de test public qui enregistre une requête inoffensive. Lors de la résolution suivante, renvoyez une adresse bloquée. Forcez ensuite une seconde connexion en fermant le premier endpoint après sa réponse. Le résultat attendu n'est pas une seconde requête réussie accompagnée d'un avertissement dans les journaux. Le connecteur doit refuser avant d'ouvrir un socket vers l'adresse bloquée.

Utilisez une matrice de tests qui ne modifie qu'une condition à la fois :

1. Renvoyez une réponse IPv4 publique, puis une réponse IPv4 de bouclage après un TTL faible.
2. Renvoyez une adresse IPv4 autorisée à côté de ::1 dans le même ensemble de réponses.
3. Renvoyez un CNAME dont la réponse finale passe de publique à locale unique IPv6.
4. Renvoyez une redirection vers un second nom d'hôte qui se résout vers une adresse bloquée.
5. Fermez une connexion du pool et vérifiez que la nouvelle tentative reçoit une validation fraîche.

Ajoutez une assertion à la frontière réseau. Un faux connecteur doit enregistrer l'IP numérique et le port qu'il reçoit. Le test échoue s'il reçoit un nom d'hôte, car cela signifie qu'un autre résolveur peut encore s'exécuter après la validation. Pour les tests d'intégration, placez un écouteur sur le port de bouclage bloqué et vérifiez qu'il n'enregistre aucune connexion. Une requête rejetée qui atteint l'écouteur a déjà franchi la frontière que vous vouliez protéger.

Les tests avec un TTL court comptent, car ils exposent des caches dans des endroits inattendus : le résolveur de l'application, le système d'exploitation, un proxy, un runtime de langage ou la bibliothèque HTTP. Testez à la fois un résolveur qui respecte le TTL et un autre qui renvoie immédiatement une réponse modifiée. La sécurité ne peut pas dépendre de la lenteur ou de la rapidité d'un cache particulier.

L'approbation et la validation d'adresse répondent à des questions différentes

L'approbation par session répond à « quel processus d'agent peut agir durant cette exécution ? ». L'approbation par appel répond à « cette utilisation d'identifiant mérite-t-elle maintenant une décision humaine ? ». La validation DNS répond à « quel pair réseau peut recevoir cette connexion ? ». Réunir ces éléments dans une seule demande d'approbation donne l'impression d'une interface plus simple tout en cachant une modification importante de ce que la personne a approuvé.

Affichez le nom d'hôte et le port dans une interface d'approbation, sans prétendre qu'un nom d'hôte est une adresse de pair immuable. L'implémentation doit valider l'adresse au moment de l'exécution, même si la personne a vu une demande quelques secondes plus tôt. Si le résultat est bloqué, refusez l'action et indiquez le nom d'hôte ainsi que la catégorie d'adresse classifiée. Un utilisateur peut corriger un enregistrement DNS erroné, il ne peut pas approuver utilement une course de rebinding invisible.

La porte du coffre-fort, l'autorisation de session et les approbations d'identifiants par appel de Sallyport contrôlent qui peut invoquer une action et quand une personne doit la confirmer. Son chemin d'action HTTP a toujours besoin de la même discipline de destination à l'exécution, car un coffre-fort qui ne remet jamais un secret à un agent doit aussi éviter d'envoyer ce secret à une réponse DNS que l'utilisateur ne voulait pas considérer comme fiable.

N'ajoutez pas un moteur de règles libre pour résoudre ce problème limité. Le comportement central peut rester déterministe : rejeter les réponses non publiques pour les actions HTTP externes, résoudre lors de la connexion, lier le socket à l'adresse sélectionnée et réévaluer à chaque nouvelle connexion. Une petite règle dotée d'une frontière testable est plus facile à garder correcte qu'une page d'exceptions que personne ne sait expliquer.

Les journaux doivent montrer la destination réellement utilisée

Un enregistrement d'audit limité au nom d'hôte ne peut pas répondre à la question importante après un incident : où le socket est-il allé ? Enregistrez à la fois l'origine demandée et l'adresse de pair sélectionnée pour chaque connexion autorisée. Pour les tentatives refusées, enregistrez l'ensemble des réponses renvoyées et la classification qui a entraîné le refus. Conservez un horodatage proche de la création de la connexion afin qu'un enquêteur puisse le corréler avec le comportement du résolveur.

Évitez de prétendre à une certitude que le journal ne peut pas étayer. Si la bibliothèque HTTP ne reçoit qu'un nom d'hôte, l'enregistrement d'audit peut indiquer que l'application a demandé un nom d'hôte, il ne peut pas prouver le pair numérique. Corrigez le connecteur avant de peaufiner l'entrée d'audit. Les preuves doivent venir de la couche qui contrôle le socket.

Pour une piste d'audit inviolable, incluez les enregistrements de décision DNS dans la même séquence que les événements d'autorisation, de connexion, de redirection et de réponse. Sallyport projette ses journaux Sessions et Activity depuis un journal d'audit chiffré, enchaîné par hachage et aveugle en écriture, et sp audit verify peut vérifier cette chaîne hors ligne sur du texte chiffré. Cela n'est utile que si l'enregistrement d'action inclut la destination résolue plutôt qu'un nom d'hôte rassurant mais incomplet.

Commencez par la фабrique de connexions. Trouvez chaque chemin qui accepte un nom d'hôte, faites-lui renvoyer un pair numérique validé et faites en sorte que l'API de socket rejette les noms d'hôte bruts. Une fois cet invariant en place, les TTL courts et les changements de réponse deviennent des cas de test ordinaires, au lieu d'une surprise de sécurité qui attend la prochaine reconnexion.