剣 KENSAI

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

25 juillet 2026 recherche-en-sécurité

En bref : Une falsification de requête côté serveur peut transformer une fonctionnalité de récupération anodine en un accès aux services internes et aux 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 semble 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. D’autres représentations d’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 une fois la validation déjà effectuée.

Validez chaque décision réseau

Les contrôles réseau doivent servir de protection complémentaire aux vérifications applicatives

La validation applicative évolue et peut régresser ; l’environnement d’exécution a donc besoin d’une frontière de trafic sortant indépendante. 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 réseau et accordez à 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 contenant des identifiants, il ne devrait y avoir que peu ou rien d’utile à dérober.

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

Une seule requête vers une adresse de métadonnées connue ne constitue qu’un test rapide. Une suite 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 délais de réponse ni des fragments du corps de la réponse.

L’approche de KENSAI fondée sur la preuve consigne la classification de la destination et l’adresse réellement utilisée pour la connexion. Elle transforme ainsi un blocage apparent en preuve vérifiable que la requête n’a jamais franchi la frontière réseau prévue.

À retenir

Considérez la récupération de contenu distant comme un accès réseau privilégié. Validez et associez les destinations, vérifiez à nouveau les redirections, restreignez le trafic sortant et minimisez l’identité de la charge de travail afin qu’une seule erreur d’analyse syntaxique ne puisse pas conduire à une compromission du cloud.

Protégez votre organisation avec KENSAI

Bénéficiez d’une surveillance continue de la sécurité, d’une analyse des vulnérabilités et de pistes de preuves prêtes pour la conformité.

Lancer une analyse gratuite