La SSRF est un problème d’identité cloud, pas seulement de filtrage des URL

En bref : Une falsification de requête côté serveur peut transformer une fonctionnalité de récupération apparemment anodine en un moyen d’accéder à des services internes et à des identifiants cloud. Des défenses durables limitent conjointement les destinations, les redirections, la résolution DNS et l’identité de la charge de travail.

La fonctionnalité vulnérable paraît souvent inoffensive

Les applications récupèrent du contenu distant pour générer des aperçus de liens, traiter des webhooks, importer des documents, traiter des images et effectuer des analyses de sécurité. Le danger apparaît lorsqu’un attaquant contrôle une partie quelconque de la destination et que le serveur peut atteindre des réseaux auxquels l’attaquant n’a pas accès. L’application devient alors un proxy qui transporte la confiance du serveur vers l’espace interne.

Bloquer une courte liste de chaînes de caractères ne suffit pas. Les représentations alternatives des adresses IP, les formes IPv6, les redirections, la syntaxe des informations utilisateur et la réassociation DNS peuvent transformer une URL apparemment publique en une requête vers une adresse de bouclage, un service privé ou un point de terminaison de métadonnées cloud après que la validation a déjà été effectuée.

Validez chaque décision réseau

• Autorisez uniquement les schémas et les ports nécessaires, et rejetez les identifiants, les fragments, les syntaxes d’hôte ambiguës et les formes d’adresse non canoniques.
• Résolvez le nom d’hôte, classez chaque adresse retournée et rejetez les plages de bouclage, privées, locales au lien, multicast et réservées, aussi bien pour IPv4 que pour IPv6.
• Validez à nouveau chaque cible de redirection et verrouillez la connexion sur l’adresse validée afin que le DNS ne puisse pas changer entre la vérification et la requête.
• Appliquez des limites de taille de réponse, de type de contenu, de délai d’attente et de nombre de redirections afin qu’une récupération autorisée ne puisse pas devenir un vecteur d’épuisement des ressources.

Les contrôles réseau doivent renforcer les vérifications applicatives

La validation applicative évolue et peut subir des régressions ; l’environnement d’exécution a donc besoin d’une limite indépendante pour les flux sortants. Un service de récupération dédié, doté d’une liste d’autorisation restreinte, d’un chemin réseau isolé et d’aucun accès aux plans de contrôle de production, réduit considérablement ce qu’une erreur d’analyse syntaxique peut atteindre.

Les protections des métadonnées cloud sont également importantes. Exigez des protocoles de métadonnées orientés session lorsqu’ils sont pris en charge, bloquez les routes vers les métadonnées au niveau du réseau et attribuez à la charge de travail chargée de la récupération l’identité la plus restreinte possible. Si une requête atteint malgré tout un point de terminaison interne fournissant des identifiants, elle ne devrait y trouver que peu de choses utiles à dérober, voire aucune.

Testez les catégories de contournement, pas une seule charge utile

Une requête unique vers une adresse de métadonnées connue ne constitue qu’un test superficiel. Une suite de tests SSRF complète couvre les astuces d’encodage, les adresses décimales et hexadécimales, les notations IPv6 mixtes, les chaînes de redirections, les changements DNS, les divergences entre analyseurs et les noms d’hôtes internes. Elle vérifie également que les échecs ne divulguent ni les temps de réponse ni des fragments du corps de la réponse.

L’approche de KENSAI fondée sur les preuves consigne la classification de la destination et l’adresse à laquelle la connexion a réellement été établie. Elle transforme ainsi un blocage apparent en preuve vérifiable que la requête n’a jamais franchi la limite réseau prévue.

À retenir

Considérez la récupération de contenu distant comme un accès réseau privilégié. Validez et verrouillez les destinations, vérifiez à nouveau les redirections, restreignez les flux sortants et réduisez au minimum l’identité de la charge de travail afin qu’une simple erreur d’analyse syntaxique ne puisse pas compromettre le cloud.