Qu'est-ce que le SSRF et pourquoi le service de métadonnées cloud est-il une cible ?
Réponse courte
Le SSRF pousse un serveur à effectuer des requêtes HTTP (ou autres) vers une destination choisie par l'attaquant, en abusant de la position réseau du serveur pour atteindre des services internes derrière le pare-feu. Dans le cloud, c'est particulièrement grave car le service de métadonnées d'instance (par exemple 169.254.169.254) peut renvoyer des identifiants IAM, transformant un SSRF en compromission du compte cloud.
La falsification de requête côté serveur (SSRF) survient quand une application prend une URL ou une adresse d'une entrée utilisateur et effectue une requête vers celle-ci depuis le serveur. Pensez à une fonctionnalité qui récupère une image distante, valide un webhook ou importe un document depuis un lien. L'attaquant fournit une URL que le développeur n'avait jamais prévue, et le serveur — situé à l'intérieur de la frontière de confiance — effectue la requête pour le compte de l'attaquant.
Pourquoi la position du serveur est le butin
Le serveur peut atteindre des choses que l'attaquant ne peut pas : panneaux d'administration internes, bases de données, autres microservices et adresses link-local, tous derrière le pare-feu. Le SSRF transforme effectivement le serveur vulnérable en un proxy vers le réseau interne, permettant le balayage de ports internes et l'accès à des API internes non authentifiées. Les formes que prennent ces requêtes — adresses link-local, astuces de schéma, contournements par encodage — sont cataloguées dans des collections de payloads SSRF.
La particularité des métadonnées cloud
Les instances cloud exposent un service de métadonnées d'instance à une adresse link-local (AWS/GCP/Azure utilisent 169.254.169.254). Il renvoie la configuration de l'instance — et surtout, des identifiants IAM temporaires pour le rôle attaché à l'instance. Un SSRF qui atteint ce point de terminaison peut lire ces identifiants et les utiliser contre le compte cloud, faisant d'un simple bug web une compromission cloud étendue. C'est le chemin derrière plusieurs grosses violations.
Atténuations
- IMDSv2 (AWS) nécessite un jeton de session obtenu via une requête
PUTavec une limite de sauts, ce qu'un simpleGETSSRF ne peut pas réaliser — bloquant la voie de vol d'identifiants. - Mettez sur liste d'autorisation les destinations sortantes plutôt que sur liste de blocage ; les listes de blocage manquent le DNS rebinding, les redirections, l'IPv6, les encodages d'IP en décimal/octal et
0.0.0.0. - Résolvez et validez l'IP cible après la résolution DNS, désactivez les schémas d'URL inutiles et isolez le récupérateur dans un segment réseau restreint.
Les recruteurs recherchent la définition « le serveur effectue des requêtes choisies par l'attaquant », l'escalade métadonnées/identifiants IAM, IMDSv2, et l'idée que la liste de blocage est fragile, donc la liste d'autorisation est préférée.
Questions de suivi probables
- Comment IMDSv2 atténue-t-il le SSRF basé sur les métadonnées ?
- Pourquoi mettre 'localhost' sur liste de blocage est-il une défense SSRF incomplète ?
- Comment le SSRF peut-il être utilisé pour le balayage de ports internes ?