33. SSRF et sorties HTTP du serveur

Comprendre le mécanisme

Une SSRF utilise la capacité du serveur à effectuer des requêtes vers des destinations choisies ou influencées par un appelant. Le serveur peut disposer d’accès réseau que le navigateur n’a pas. Une simple vérification de préfixe de chaîne ne couvre pas les formes d’URL, résolutions DNS, adresses ou redirections possibles. La politique doit décrire les protocoles, destinations, ports et chemins réellement nécessaires.

Raisonner et vérifier

Préférez des identifiants de fournisseurs connus à une URL libre. Contrôlez chaque saut de redirection et les adresses effectivement utilisées avec les protections réseau appropriées. Bornez temps, taille de réponse et nombre de sauts. Les restrictions de sortie doivent rester effectives même si la validation applicative comporte un défaut. Les tests utilisent des récepteurs de laboratoire, sans explorer des réseaux dont vous n’êtes pas responsable.

Politique de sortie

Une URL serveur doit suivre une politique de destination. TLS vers une destination hostile ne la rend pas admise. Définissez schémas, hôtes, ports et opérations distantes admis. Une URL syntaxiquement valide peut viser un service interne ou une capacité privilégiée ; sa validité ne suffit pas à l’autoriser.

Identifiant fournisseur

Un identifiant de fournisseur peut être résolu côté serveur. Une résolution maîtrisée réduit les destinations disponibles. Le client peut choisir partner-42 tandis que le serveur résout une configuration contrôlée. Ce modèle réduit la liberté de destination, mais doit encore vérifier que l’acteur a droit à ce fournisseur et cette opération.

Redirections

Les redirections demandent une validation à chaque étape. Une redirection peut viser un autre réseau. Un partenaire admis peut renvoyer vers localhost ou un réseau privé. Validez chaque saut ou refusez le suivi selon le contrat ; la validation initiale ne couvre pas la chaîne complète.

DNS

La résolution DNS doit être considérée dans le modèle. La destination réseau effective peut différer des attentes. La résolution peut changer entre validation et connexion. Utilisez un client et une architecture qui maintiennent la politique sur la destination réellement jointe, avec contrôle réseau complémentaire et tests de résolution maîtrisés.

Réseaux sensibles

Les réseaux privés et métadonnées sensibles doivent être considérés. Les sorties peuvent exposer des capacités internes. Incluez loopback, réseaux internes et services de métadonnées dans le modèle. Ne réduisez pas l’analyse à une seule chaîne 127.0.0.1 : adresses, familles et représentations doivent être traitées par des composants adaptés.

Budgets

Des limites de taille et de durée restent nécessaires. Un service autorisé peut être lent ou volumineux. Même une destination autorisée peut répondre lentement ou sans limite. Bornez connexion, durée globale et volume lu, y compris après décompression si le client l’effectue automatiquement.

Egress

Une politique de sortie réseau complète le contrôle applicatif. Les couches apportent des garanties différentes. Une politique réseau de sortie peut bloquer des destinations que l’application n’aurait jamais dû joindre. Cette défense complète le contrôle applicatif et limite l’impact d’une erreur de validation ou d’une nouvelle route vulnérable.

Schémas

Les schémas d’URL doivent être bornés. Les capacités des schémas diffèrent et doivent être limitées. N’admettez que les schémas nécessaires, généralement HTTPS dans ce contrat d’import. Un parseur acceptant plusieurs protocoles ne signifie pas que votre produit doit exposer toutes leurs capacités.

Laboratoire

Un test SSRF doit rester dans un laboratoire autorisé. Le périmètre d’essai doit protéger les tiers et l’infrastructure. Utilisez services factices et destinations autorisées pour tester refus et redirections. Les tests ne doivent pas sonder des infrastructures tierces ou des métadonnées réelles pour démontrer la propriété pédagogique.

Opération précise

L’autorisation doit porter sur l’opération distante admise. Le rôle ne rend pas toute destination légitime. Une destination partenaire autorisée peut exposer plusieurs chemins aux capacités différentes. Limitez méthode, route et données transmises selon le besoin métier, pas seulement le nom du serveur distant.

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

{
  "allowedHost": "partner.example.test",
  "initialUrl": "https://partner.example.test/lab/export",
  "redirectLocation": "http://127.0.0.1/internal"
}

L’URL initiale correspond au partenaire, mais Location vise une interface locale interne. Le suivi doit être refusé par la politique montrée. Ajoutez un test qui observe l’absence de connexion vers la cible interdite, puis un saut conforme pour vérifier le fonctionnement nominal du client.

Les redirections doivent rester dans le contrat de sortie. La confiance ne se propage pas arbitrairement. HTTP ne fournit pas ce chiffrement. La destination initiale ne prouve pas les autres pairs.

Travail pratique : Construisez deux récepteurs locaux, l’un admis et l’autre refusé. Simulez une redirection du premier vers le second.

Critères de correction : Vérifiez le refus au bon saut et la borne de temps. Ajoutez les cas de port non prévu, schéma non admis et résolution incompatible avec la politique. Contrôlez également les règles de sortie réseau du service.

SSRF : appliquer la politique à la connexion réelle

Le produit n’a besoin que de partenaires identifiés. Remplacer une URL libre par un identifiant résolu côté serveur réduit fortement la surface, mais la configuration partenaire et son parcours réseau demandent encore une vérification.

Une résolution DNS peut changer et une réponse initialement admise peut rediriger vers une cible interdite. La politique doit porter sur la destination réellement jointe, revalider chaque redirection et être complétée par un filtrage réseau de sortie. Limitez schémas, ports, méthodes et chemins au besoin, avec délais et taille maximale de réponse.

Ne tentez pas de résoudre le problème par une simple recherche textuelle de localhost ou par une seule résolution avant un second appel indépendant. Utilisez des composants adaptés et une topologie qui préserve le lien entre décision et connexion. Les tests se font avec DNS et serveurs factices autorisés, en vérifiant surtout l’absence d’appel aux destinations interdites et un chemin nominal partenaire qui continue de fonctionner.

Points de vigilance : Un domaine peut figurer dans le chemin, les identifiants ou un sous-domaine trompeur. Une politique de destination appliquée à la connexion, aux redirections et au réseau réduit les contournements. Une résolution ultérieure ou une redirection peut viser une autre destination. TLS authentifie un nom ; il n’autorise pas l’application à joindre n’importe quelle ressource.