flawopen.com/SSRF/Métadonnées cloud et SSRF

Comment une SSRF peut-elle atteindre les métadonnées cloud et quand les identifiants sont-ils en danger ?

Page de référence

Explication simple

Imaginez le service de métadonnées comme un guichet interne verrouillé dans une machine cloud. Une SSRF peut transformer votre application en coursier jusqu’à ce guichet, mais ce qu’elle peut récupérer dépend des règles de requête du fournisseur, des paramètres de l’instance et du chemin réseau de l’application. L’accès au point de terminaison ne signifie pas automatiquement que des identifiants sont exposés.

Pourquoi le point de terminaison des métadonnées peut être dangereux

AWS EC2, Azure et Google Compute Engine documentent des services de métadonnées d’instance accessibles depuis les environnements VM pris en charge. 169.254.169.254 est une adresse link-local courante, mais les formats et contrôles diffèrent. Les métadonnées peuvent contenir des informations sensibles ; AWS peut fournir des identifiants temporaires de rôle lorsque le profil d’instance et le chemin de requête le permettent. La SSRF devient pertinente si un attaquant peut influencer une requête serveur qui atteint ce service. L’accessibilité seule ne prouve pas que des identifiants sont récupérables : en-têtes ou jetons requis, méthode HTTP, proxy, emplacement réseau et configuration de l’instance comptent.

Comment se forme la chaîne d’impact

L’impact suppose une chaîne de conditions : une entrée influence une requête serveur ; celle-ci atteint le service de métadonnées ; le service l’accepte selon les contrôles du fournisseur ; et les données renvoyées donnent un accès utile. L’ampleur finale dépend des permissions de l’identité de la charge de travail. Rompez la chaîne avec des destinations fixes, un contrôle strict du trafic sortant, les protections de métadonnées du fournisseur et des identités au moindre privilège.

Questions fréquentes

Tous les fournisseurs cloud utilisent-ils la même adresse ou le même contrôle ?

Non. Les adresses, en-têtes, méthodes, exigences de jeton et données disponibles varient. AWS IMDSv2 exige un jeton de session pour récupérer les métadonnées quand HttpTokens est défini sur required ; Azure exige l’en-tête Metadata: true ; Google documente Metadata-Flavor: Google. Ces contrôles peuvent atténuer certains chemins SSRF, mais ne remplacent ni le rejet des destinations contrôlées par l’utilisateur ni le blocage des sorties inutiles. Vérifiez la configuration précise des VM et conteneurs dans la documentation du fournisseur.

Sources et analyses associées

À voir aussi Falsification de requêtes côté serveur (SSRF, CWE-918) : fonctionnement et prévention dans chaque langage — flawopen.com Bots IA de revue de PR : prévenir SSRF — flawopen.com SSRF avec fetch() Node.js : récupérer des URL sans risque