SSRF et métadonnées cloud : les couches de défense qui tiennent

Dès qu'un serveur va chercher une URL fournie par quelqu'un d'autre, il prête sa position réseau à cette personne. Un webhook sortant configurable, un import d'image par lien, un aperçu de page, un rendu PDF à partir de HTML : dans chacun, l'utilisateur choisit la destination et c'est votre machine qui s'y connecte, depuis l'intérieur de votre réseau, avec ses routes à elle.

La destination qui rend cette faille grave est le service de métadonnées du fournisseur cloud. Il écoute sur une adresse de lien local, joignable uniquement depuis la machine, sans authentification puisque « seule la machine peut l'atteindre ». Il distribue, entre autres, des identifiants temporaires pour le rôle attaché à l'instance. Un SSRF transforme donc une fonctionnalité d'import d'image en accès à votre stockage objet. Aucune validation d'URL ne tient seule, et la défense se conçoit en couches dont chacune suppose que la précédente a cédé.

DNS, délai, redirections : pourquoi filtrer l'URL échoue

La première parade qu'on écrit est un filtre sur l'URL, qui refuse localhost et les adresses privées. Elle échoue pour une raison de structure, puisqu'on valide une chaîne de caractères alors que la connexion se fait vers une adresse IP. Entre les deux interviennent trois traductions qu'on ne contrôle pas.

Le DNS. Un nom parfaitement public peut résoudre vers une adresse interne ; il suffit que son propriétaire publie cet enregistrement. Le filtre voit un nom de domaine honnête.

Le temps. On résout le nom pour le vérifier, puis le client HTTP le résout à nouveau pour se connecter. Entre les deux requêtes DNS, la réponse peut changer, la première donnant une adresse publique et la seconde une adresse interne. Cette faille de type « vérifié puis utilisé » se provoque avec un simple TTL très court.

Les redirections. La première URL est publique et saine. Elle répond par une redirection vers l'interne, que le client suit sans repasser par le filtre.