Valider les redirections HTTP pour les requêtes d'agents authentifiées

La validation des redirections HTTP doit avoir lieu avant qu'un agent ne transmette des identifiants à l'URL suivante. Une redirection n'est pas la simple continuation inoffensive d'une requête. C'est une instruction envoyée par un serveur distant pour effectuer une autre requête, souvent vers une autorité différente, avec une méthode différente et une autre destination réseau.

Cette distinction se perd facilement lorsqu'on relie un agent à un client d'API en laissant le paramètre de redirection automatique activé par défaut. L'agent envoie une requête à une API approuvée. L'API renvoie 302 Location: https://somewhere-else/.... Le client suit la redirection. Si l'authentification est ajoutée trop tôt, un attaquant qui contrôle le premier point de terminaison, un paramètre de redirection ou une dépendance compromise peut transformer un appel autorisé en service de transmission d'identifiants.

J'ai déjà vu ce risque écarté au motif que les bibliothèques HTTP reconnues suppriment souvent Authorization lorsque l'hôte change. Cette protection est utile, mais elle n'est ni universelle ni suffisante. Elle ne dit rien des en-têtes d'identification personnalisés, des paramètres de requête signés, des cookies, des corps de requête redirigés, des changements DNS ou des redirections vers une terminaison dangereuse sur le même hôte. Prenez une décision explicite pour chaque redirection au lieu de considérer les valeurs par défaut de la bibliothèque comme votre politique.

Les redirections créent une nouvelle décision d'autorisation

Chaque étape d'une redirection doit être examinée aussi attentivement que la première URL, car c'est le serveur qui choisit la destination suivante. Le client a demandé une ressource et reçoit une réponse qui propose un autre URI dans le champ Location. L'autorisation initiale ne couvre pas automatiquement l'URI proposé.

La RFC 9110 définit les redirections par leurs codes d'état et indique aux agents utilisateurs comment ils peuvent ou doivent réagir. Elle ne dit pas qu'un identifiant d'API ajouté à la requête initiale est autorisé pour chaque URI qu'un serveur pourrait renvoyer. Cette décision revient à l'appelant. Pour une passerelle d'agent, c'est à l'appelant de décider quelles actions en aval il effectuera.

Gardez ces deux événements distincts dans le code et dans les journaux :

1. Le serveur envoie une réponse de redirection pour une requête déjà effectuée.
2. Le client choisit d'envoyer une nouvelle requête vers la cible résolue.

Le premier événement est un fait. Le second est une action privilégiée. Si votre implémentation combine les deux dans un appel pratique comme client.Do(request) avec les redirections automatiques activées, vous avez masqué le moment où la politique doit s'appliquer.

Une redirection peut franchir plusieurs frontières à la fois. https://api.example.test/v1/export peut pointer vers https://downloads.example.test/file, qui pointe ensuite vers une URL temporaire d'objet chez un fournisseur de stockage. Cette chaîne peut être légitime. Elle montre aussi qu'une règle vague comme « le premier hôte est approuvé » ne dit presque rien de la connexion finale.

Les redirections relatives demandent la même prudence. Résolvez Location: ../admin par rapport à l'URL qui l'a produite, avec un analyseur d'URL conforme aux normes. Ne concaténez pas les chaînes. Un chemin commençant par // est relatif au schéma et peut changer d'hôte. Les délimiteurs encodés et les formes inhabituelles, comme une valeur Location vide, ont créé suffisamment d'incohérences entre les clients pour qu'une passerelle refuse l'ambiguïté au lieu de deviner.

Injectez les identifiants seulement après validation de la destination

L'ordre sûr est simple : recevoir la réponse, analyser la destination candidate, la valider, construire la requête suivante, puis injecter uniquement les identifiants approuvés pour cette destination. L'injection des identifiants doit avoir lieu au moment de l'envoi final, pas dans un objet de requête mutable qui survivrait à une chaîne de redirections.

C'est l'erreur de conception à l'origine de la plupart des fuites. Un wrapper construit une requête avec Authorization: Bearer ..., l'envoie, puis laisse le client HTTP cloner ou rejouer la requête après une redirection. Le wrapper peut destiner le jeton à un seul hôte, mais il ne contrôle plus chaque envoi.

Utilisez une description de requête qui ne contient aucun secret. Elle peut transporter la méthode, le corps, la référence de l'identifiant autorisé et l'URL initiale. Pour chaque étape, créez une nouvelle requête réseau après validation. La couche d'envoi ne recherche l'identifiant qu'une fois la cible autorisée.

Un modèle compact ressemble à ceci :

request intent:
  method: POST
  initial URL: https://api.acme.test/v1/reports
  credential reference: billing-api-prod
  body digest: sha256:...

for each response:
  if status is not a supported redirect: return response
  target = resolve(response.request_url, response.headers["Location"])
  decision = validate(target, request intent, response.status)
  if decision is reject: record rejection and stop
  next_request = build(decision.method, target, permitted body)
  inject(credential reference, target, next_request)
  send(next_request)

Le point essentiel n'est pas le pseudo-code, mais la durée de vie du secret. Le jeton n'existe que dans la requête qui a déjà passé la validation de destination. Il ne reste jamais dans un objet générique qu'un rappel de redirection pourrait transmettre par erreur.

Cet ordre permet aussi de faire respecter la portée des identifiants. Un jeton bearer pour api.acme.test ne doit pas automatiquement authentifier uploads.acme.test, même si les deux noms appartiennent à la même entreprise. Donnez à chaque règle de destination une référence d'identifiant explicite. Si deux services partagent volontairement un identifiant, documentez cette relation dans la règle au lieu de la déduire d'un suffixe DNS.

La correspondance d'origine évite une fuite, mais pas les autres

Une correspondance stricte de l'origine bloque les changements d'hôte évidents, mais elle ne suffit pas à déterminer si une requête redirigée est sûre. Une origine comprend le schéma, l'hôte et le port. Traitez toute modification de l'un de ces champs comme une frontière, sauf exception explicite.

Le schéma compte. Une redirection de HTTPS vers HTTP peut exposer des en-têtes ou le contenu de la requête sur le réseau. Refusez les rétrogradations pour le trafic authentifié. Une redirection de HTTP vers HTTPS peut sembler sûre, mais elle modifie tout de même l'autorité et peut masquer une terminaison inattendue. Validez-la normalement.

Le port compte également. https://api.example.test et https://api.example.test:8443 sont des origines différentes. Les développeurs l'oublient souvent parce que les navigateurs masquent les ports par défaut et que les environnements de test locaux utilisent constamment des ports alternatifs. Un jeton destiné à l'API publique peut se retrouver sur un service d'administration si votre règle d'autorisation ne vérifie que le nom d'hôte.

Le chemin compte lorsqu'un hôte d'API héberge des applications sans lien entre elles. Une redirection de /v1/files vers /internal/debug/export reste sur la même origine, mais elle peut exposer un corps ou provoquer une modification d'état dangereuse. N'utilisez pas une liste de chemins autorisés comme substitut à l'autorisation applicative, mais limitez les cibles de redirection aux préfixes d'API réellement nécessaires à votre intégration.

Les paramètres de requête exigent une attention particulière. Une cible de redirection peut contenir une URL pré-signée, un paramètre d'état ou un jeton de téléchargement à usage unique. En pratique, ces valeurs sont des identifiants, même si elles n'utilisent pas l'en-tête Authorization. Ne recopiez pas les paramètres de requête de l'ancienne requête dans la nouvelle URL. Utilisez exactement la cible de redirection analysée, après application des règles qui interdisent les champs userinfo, les fragments ou les paramètres ressemblant à des identifiants.

Une base pratique consiste à n'autoriser les redirections de même origine que si le schéma reste HTTPS, si le port reste approuvé, si le chemin cible appartient à la surface d'API autorisée par l'intégration et si le code de redirection permet la méthode prévue. Traitez les redirections entre origines comme une catégorie distincte, avec des règles de destination nommées.

Les codes d'état de redirection changent la requête qui peut être envoyée

Les codes d'état de redirection portent une sémantique liée à la méthode. Un client qui l'ignore peut transformer une lecture sûre en écriture inattendue ou rejouer un corps sensible. Ne réduisez pas chaque réponse 3xx à « suivre Location ».

La RFC 9110 indique que 307 et 308 préservent la méthode et le contenu de la requête. Si la requête initiale était un POST contenant la définition d'un rapport, une réponse 307 ou 308 demande au client d'envoyer ce même POST et ce même corps à la nouvelle cible. C'est le cas de redirection le plus risqué, car le nouvel hôte peut recevoir à la fois des données métier et une requête ayant des effets de bord.

Le code 303 demande au client de récupérer une représentation avec GET ou HEAD, quelle que soit la méthode initiale. Cela se produit généralement après une soumission de type formulaire. Pour une action d'agent, ne l'autorisez que si la cible du GET redirigé est approuvée séparément et si votre intégration prévoit ce fonctionnement. Un 303 ne doit pas reprendre un en-tête d'autorisation simplement parce que le POST initial en avait un.

Les cas historiques problématiques sont 301 et 302. La RFC 9110 décrit la pratique ancienne consistant à transformer POST en GET pour ces réponses, tandis que 307 et 308 existent pour les appelants qui doivent préserver les méthodes. Les bibliothèques diffèrent dans leurs détails, notamment pour les méthodes autres que POST et les corps. Ne laissez jamais cette ambiguïté décider de ce qu'envoie un client autonome.

Écrivez clairement le comportement attendu. Par exemple :

• Ne suivez les 301 et 302 que pour les requêtes GET et HEAD.
• Ne suivez les 303 qu'en envoyant un GET ou un `HEAD sans identifiants, puis validez à nouveau la cible avant d'ajouter un identifiant de lecture approuvé.
• Ne suivez les 307 et 308 que lorsque la règle de destination autorise explicitement la méthode initiale et la catégorie de corps.
• Refusez une redirection après une méthode non idempotente comme POST, PATCH ou DELETE, sauf si l'intégration dispose d'un flux de redirection documenté.

Cela peut casser une API mal conçue. C'est préférable au rejeu silencieux d'une instruction de paiement, d'un téléversement de code source ou d'une commande d'administration vers un endroit choisi par un serveur distant. Si un fournisseur exige des écritures redirigées, ajoutez une exception étroitement limitée et testez la séquence exacte.

Les règles de destination ont besoin de champs, pas d'une simple chaîne d'hôte

Un validateur de redirection utile évalue une cible par rapport à une règle suffisamment détaillée pour décrire le service que vous vouliez appeler. Une liste d'hôtes autorisés est séduisante parce qu'elle est courte. C'est aussi là que les exceptions s'accumulent, jusqu'à ce que plus personne ne puisse expliquer ce qu'un agent peut envoyer et où.

Pour chaque destination de redirection autorisée, décidez des points suivants :

• Quels schémas sont autorisés, normalement HTTPS uniquement.
• Quels noms d'hôte normalisés et quels ports sont autorisés.
• Quelles méthodes et quels préfixes de chemin la requête redirigée peut utiliser.
• Quelle référence d'identifiant, le cas échéant, peut être injectée.
• Si la cible peut être résolue vers des adresses de réseau privées ou locales.

Normalisez avant la comparaison. Mettez les noms d'hôte DNS en minuscules, retirez systématiquement le point final, analysez correctement les littéraux IPv6 entre crochets et refusez les encodages en pourcentage mal formés. Ne comparez jamais les URL brutes. Dans https://[email protected]/, l'hôte est evil.test, même si un nom approuvé apparaît avant le caractère @.

N'utilisez pas endsWith("example.test") pour vérifier une autorité. Cette règle accepte notexample.test. Même une règle de suffixe tenant compte du séparateur, comme *.example.test, nécessite un examen de propriété. Les sous-domaines génériques peuvent inclure des systèmes de préproduction, des noms contrôlés par des clients, des redirecteurs ou des infrastructures gérées par une autre équipe.

Le validateur doit renvoyer une décision motivée plutôt qu'un simple booléen. Les opérateurs doivent savoir s'il a refusé une rétrogradation de schéma, un port non approuvé, une méthode interdite, une adresse privée ou une limite de redirections atteinte. Ces informations doivent figurer dans l'enregistrement de l'action, sans valeurs de jeton.

Définissez une limite de redirections petite et fixe. Elle arrête les boucles et rend visibles les chaînes longues. N'acceptez pas un nombre fourni par l'agent. La passerelle possède cette limite puisqu'elle contrôle les actions réseau.

Un flux de téléchargement courant peut fuir une requête privilégiée

Les cas dangereux ne se présentent presque jamais comme des attaques. Ils ressemblent souvent à des points de terminaison pratiques qui acceptent une URL ou renvoient un emplacement de téléchargement.

Imaginez qu'un agent doive récupérer un rapport auprès d'une API de facturation approuvée. Il envoie POST /v1/exports avec un jeton bearer. L'API renvoie un 303 vers une URL de téléchargement. La passerelle la suit automatiquement et transmet le jeton bearer parce que son injecteur d'en-têtes personnalisé s'exécute avant le gestionnaire de redirection de la bibliothèque HTTP.

Au départ, l'hôte de téléchargement est un autre service géré par la même équipe. Quelques mois plus tard, une modification de configuration permet au point de terminaison d'export d'accepter un paramètre destination afin que les clients puissent utiliser un fournisseur de stockage. Un attaquant ayant accès aux paramètres du rapport fournit une URL qu'il contrôle. L'API approuvée renvoie une redirection vers cette URL. La bibliothèque HTTP la traite comme un 303 ordinaire, et la passerelle a déjà ajouté X-Service-Token.

Rien d'exotique ne s'est produit. La première requête vers l'API était autorisée, la syntaxe de redirection était valide et le jeton n'est jamais apparu dans un prompt d'agent. L'échec vient du fait que les identifiants ont été attribués avant de connaître la cible.

Une implémentation correcte enregistre le 303, résout la cible, constate que l'hôte ne possède aucune règle de destination et s'arrête. L'opérateur voit une redirection refusée plutôt qu'un appel sortant mystérieux. Si le service de téléchargement doit être accessible, créez une règle distincte pour son hôte exact et utilisez un identifiant de téléchargement qui ne peut pas appeler l'API de facturation.

Les agents ajoutent une autre voie à cet échec. Un agent peut influencer une URL par le texte d'un ticket, un fichier de configuration de dépôt, un champ de réponse d'API ou une instruction provenant d'un outil. Ne supposez pas qu'une URL vient d'un développeur simplement parce qu'elle apparaît dans une requête créée par votre agent. Une donnée peut très vite devenir une instruction de routage.

Les vérifications DNS doivent avoir lieu au moment de la connexion

La validation du nom d'hôte ne suffit pas à empêcher la falsification de requêtes côté serveur. Un nom d'hôte peut se résoudre vers une adresse publique pendant l'examen, puis vers la boucle locale, une plage link-local ou une adresse privée au moment où le client se connecte. La gestion des redirections donne à un attaquant des occasions répétées d'exploiter cet écart.

Résolvez chaque nom d'hôte approuvé peu avant la connexion et évaluez chaque adresse renvoyée selon vos règles réseau. Refusez les plages de boucle locale, les adresses non spécifiées, les plages link-local, les plages privées, les adresses multicast et leurs équivalents IPv6, sauf si une règle les autorise explicitement. Appliquez le même traitement aux adresses IP littérales présentes dans les URL de redirection.

Ne résolvez pas un nom d'hôte une seule fois, n'approuvez pas une adresse, puis ne laissez pas une pile HTTP distincte le résoudre à nouveau. Cela crée un écart entre le moment du contrôle et celui de l'utilisation. La connexion doit utiliser l'ensemble d'adresses évalué, ou le transport doit fournir un moyen fiable de confirmer l'adresse du pair et de refuser toute discordance. C'est plus difficile qu'il n'y paraît lorsque les pools de connexions, les proxys et le DNS double pile entrent en jeu.

Les déploiements avec proxy d'entreprise ont besoin d'un modèle d'exception explicite. Si la passerelle ne se connecte qu'à un proxy précis, validez le proxy comme pair réseau et conservez les règles de destination applicative avant de former la requête destinée au proxy. Ne déclarez pas toutes les plages privées sûres simplement parce que l'organisation utilise des adresses de service privées. Nommez les hôtes et les ports internes nécessaires à l'agent.

Le DNS rebinding est une raison supplémentaire pour laquelle une règle de redirection ne peut pas constituer une approbation permanente d'un nom d'hôte. Le comportement des caches, les TTL et les différences entre résolveurs peuvent modifier la réponse. Prenez la décision pour la connexion que vous êtes sur le point d'effectuer et consignez l'adresse du pair sélectionné, sans la considérer comme la preuve que la destination applicative a été autorisée.

Les cookies, URL signées et corps sont aussi des identifiants

Les équipes protègent souvent Authorization tout en laissant les autres éléments sortants intacts. Une redirection peut exposer des identifiants ou des données sensibles par plusieurs autres canaux.

Les cookies obéissent à des règles de domaine et de chemin, mais une passerelle d'agent ne doit pas s'appuyer sur un magasin de cookies général, de type navigateur, pour les identifiants machine. Désactivez les cookies par défaut pour les appels privilégiés. Si une intégration en a besoin, limitez le magasin à cette intégration et réévaluez l'ajout des cookies pour chaque cible de redirection.

Les URL pré-signées placent volontairement l'autorisation dans la chaîne de requête. Elles devraient généralement fonctionner sans ajouter d'autre jeton de service. Si une règle de destination reconnaît une URL de stockage pré-signée, envoyez-la exactement avec les éléments d'autorisation déjà présents dans l'URL et une méthode limitée, généralement GET ou PUT. N'ajoutez pas vos en-têtes habituels par réflexe.

Les corps de requête contiennent eux aussi des secrets. Un corps JSON peut contenir une archive source, des données client ou une assertion signée opaque. Pour 307 et 308, exigez une règle explicite autorisant le rejeu du corps vers ce service précis. Pour les autres codes de redirection, ne transformez pas ni ne renvoyez silencieusement le corps. La commodité d'une bibliothèque cliente ne justifie pas de dupliquer du contenu sensible.

L'en-tête HTTP Referer peut divulguer des chemins et des valeurs de requête lorsqu'un client l'ajoute. Les clients d'API devraient généralement éviter de transmettre un en-tête Referer lors des redirections. De même, supprimez les en-têtes qui décrivent la route interne d'origine, la session de l'agent ou l'identité de l'utilisateur, sauf si la règle de destination en a explicitement besoin.

Classez les en-têtes en trois groupes : ceux qui peuvent toujours être régénérés, ceux qui ne sont autorisés que pour une destination nommée et ceux qui ne doivent jamais franchir une redirection. Cette méthode est plus fiable qu'une vague liste d'« en-têtes sensibles ». Content-Type peut être inoffensif pour un téléversement autorisé ; X-Internal-Actor peut identifier une personne qui n'a jamais autorisé l'hôte suivant.

Auditez la chaîne comme une seule action composée de plusieurs étapes

Un enregistrement d'audit doit afficher la chaîne de redirection sans exposer les éléments qui ont rendu la requête privilégiée. Une URL finale et un code d'état ne suffisent pas. Ils masquent le franchissement éventuel d'une origine, le changement de méthode, la suppression de l'authentification ou le refus d'une cible suspecte avant la connexion.

Enregistrez l'intention de la requête initiale, le code d'état de chaque réponse, chaque valeur Location après masquage, la cible résolue, le résultat de la politique, la méthode sélectionnée et la classe d'identifiant utilisée pour cette étape. Enregistrez un identifiant d'identifiant stable, jamais un jeton, un mot de passe ou une URL signée complète. Hacher une URL complète peut aider à établir des corrélations, mais un hachage ne constitue pas un masquage sûr lorsque l'entrée dispose d'une faible entropie.

Reliez toutes les étapes à un identifiant d'action parent. Un enquêteur peut ainsi distinguer « l'agent a demandé un export » de « la passerelle a effectué quatre appels réseau pour terminer l'export ». Un opérateur peut également révoquer une session active lorsque la chaîne commence à se comporter de façon inattendue.

Un journal inviolable apporte des éléments utiles après coup, mais il n'arrête pas une redirection dangereuse. La prévention doit se trouver dans le chemin de transfert. Sallyport enregistre les sessions d'agent et les appels individuels dans un journal d'audit chiffré et chaîné par hachage. Les enregistrements d'action tenant compte des redirections peuvent ainsi conserver la trace des décisions au lieu d'aplatir la chaîne en un résultat final.

Testez le journal avec des cas volontairement refusés. Déclenchez une redirection 302 entre origines, une redirection de HTTPS vers HTTP, un 307 après un POST, un champ Location mal formé et une cible qui se résout vers la boucle locale. Si ces enregistrements n'expliquent pas au lecteur pourquoi la passerelle s'est arrêtée, améliorez le schéma d'événement avant qu'un incident ne vous y oblige.

Faites du comportement des redirections une partie du contrat de l'outil

Un outil qui appelle une API HTTP doit indiquer à ses utilisateurs s'il suit les redirections et dans quelles conditions. « Utilise HTTP standard » n'est pas un contrat. Le comportement varie selon les bibliothèques et change lorsqu'une personne remplace un client, ajoute un proxy ou déplace l'authentification dans un middleware.

Écrivez des tests avec un dispositif local de redirection comportant des points de terminaison distincts. Ce dispositif doit renvoyer des codes d'état et des valeurs Location contrôlés, puis capturer la méthode reçue, le condensat du corps, l'hôte et les en-têtes. Vos assertions doivent prouver qu'une cible non approuvée ne reçoit aucun en-tête d'identification, qu'un 303 ne rejoue pas le corps d'un POST et qu'un 307 autorisé n'envoie que les en-têtes et le corps permis par la règle.

Ne laissez pas l'agent choisir une politique de redirection dans les arguments de l'outil. Un agent peut demander une intégration connue et fournir les paramètres ordinaires de la requête. La passerelle décide si le suivi des redirections existe pour cette intégration, combien d'étapes sont autorisées et quels identifiants peuvent être utilisés. Cette séparation empêche une injection de prompt de devenir follow_redirects=true.

Pour une première implémentation, choisissez un contrat volontairement étroit : ne suivez que les redirections HTTPS approuvées pour GET et HEAD, injectez les identifiants par destination après validation et refusez toute écriture redirigée. N'ajoutez des exceptions qu'après avoir expliqué le flux du fournisseur, la frontière de destination, le comportement de la méthode et l'enregistrement d'audit. Quelques refus explicites agaceront les développeurs. Un jeton envoyé à un attaquant agacera beaucoup plus de monde.