Une application récupère côté serveur une URL fournie par l'utilisateur (par ex. pour des aperçus de liens). Quel est le risque et comment le corriger ?
Réponse courte
Récupérer côté serveur des URL contrôlées par l'attaquant relève du Server-Side Request Forgery (SSRF) : cela permet d'atteindre des services internes ou le point de terminaison de métadonnées cloud pour voler des identifiants. Pour l'atténuer, restreignez les hôtes et schémas autorisés par allow-list, bloquez les plages privées et link-local (en revérifiant après chaque redirection) et durcissez l'accès aux métadonnées avec IMDSv2. Dire qu'il n'y a aucun risque ignore l'accès que confère la requête, et un spinner de chargement ou une mise en cache ne change rien aux destinations que le serveur peut joindre.
Quand votre serveur récupère une URL contrôlée par un utilisateur — pour un aperçu de lien, un webhook, l'import d'un avatar — il devient un « adjoint confus ». L'attaquant n'effectue pas la requête lui-même, mais il choisit où votre serveur l'effectue. C'est le Server-Side Request Forgery (SSRF), et sur une infrastructure cloud c'est l'une des classes de failles les plus dangereuses.
Pourquoi c'est le vrai risque
Le serveur se trouve généralement dans un réseau de confiance, avec une portée bien supérieure à celle d'un client externe. En fournissant une URL comme http://169.254.169.254/latest/meta-data/, un attaquant peut extraire les métadonnées cloud de l'instance — y compris des identifiants IAM temporaires — et pivoter dans votre compte. Il peut aussi atteindre des consoles d'administration internes, des bases de données et des microservices non authentifiés qui supposent que « si tu peux m'atteindre, tu es de confiance ». C'est exactement ainsi que plusieurs grandes brèches cloud sont parties d'une simple fonction d'aperçu.
La bonne correction
Défendez en profondeur :
- Allow-list des hôtes et schémas exacts que vous comptez récupérer (uniquement
https, uniquement des domaines connus). Une allow-list échoue de manière fermée ; une deny-list des « mauvaises » plages laisse toujours passer quelque chose. - Résolvez vous-même le nom d'hôte et bloquez les plages privées, de bouclage et link-local (
127.0.0.0/8,10/8,192.168/16,169.254/16, équivalents IPv6) — et revérifiez après chaque redirection, car un hôte autorisé peut vous renvoyer en 302 vers169.254.169.254. - Durcissez les métadonnées avec IMDSv2, qui exige un jeton de session signé via une requête PUT, déjouant le simple GET qu'un SSRF peut effectuer.
Pourquoi les autres réponses sont fausses
« Aucun risque — ce n'est qu'une requête HTTP » est précisément l'état d'esprit qui livre du SSRF ; le danger tient à la position réseau, pas au protocole. Un spinner de chargement est un détail d'UX. Mettre la réponse en cache peut même aggraver les choses en stockant des données internes. Aucune de ces options ne restreint où le serveur se connecte, ce qui est tout le problème que l'examinateur cherche à sonder.
Questions de suivi probables
- Comment empêcher le SSRF via le DNS rebinding ou une redirection HTTP vers 169.254.169.254 ?
- Pourquoi une allow-list d'hôtes est-elle plus sûre qu'une deny-list de plages privées ?
- Qu'est-ce qu'IMDSv2 change quant à la manière dont le point de terminaison de métadonnées peut être atteint ?