Attaques SSRF expliquées : comment le DNS est exploité

La falsification de requête côté serveur (SSRF) survient lorsqu'un attaquant amène un serveur à émettre une requête HTTP (ou autre requête réseau) en son nom, vers une destination qu'il a choisie plutôt que celle prévue par le développeur de l'application. Un vecteur classique : une fonctionnalité qui récupère une URL fournie par l'utilisateur (import d'image, cible de webhook, aperçu de lien), et l'attaquant fournit une URL qui pointe vers l'infrastructure interne plutôt que vers une ressource publique.

Où le DNS intervient dans l'attaque

La défense naïve consiste à vérifier si le nom d'hôte de l'URL fournie ressemble à une adresse interne. Elle se contourne trivialement : un attaquant enregistre un domaine public, fait pointer son enregistrement DNS vers une IP interne et transmet à votre serveur un nom d'hôte d'apparence parfaitement normale. Votre validation voit un domaine, pas une IP ; la partie dangereuse n'apparaît qu'après la résolution DNS, qui a souvent lieu au fond de la bibliothèque cliente HTTP qui émet la requête, bien après toute étape de validation préalable.

À quoi ressemble une vraie protection

• Résolvez vous-même le nom d'hôte, explicitement, avant d'émettre toute requête : ne laissez pas un client HTTP le résoudre de façon invisible pour votre compte.
• Vérifiez chaque adresse résolue (toutes : un domaine peut en renvoyer plusieurs) par rapport à une liste de blocage d'adresses privées, de bouclage, de lien local et de métadonnées cloud.
• Rejetez la requête si une seule adresse résolue est interdite, au lieu de ne contrôler que la première renvoyée.
• Revalidez au moment de la requête, et pas seulement à la saisie, pour combler la faille de DNS rebinding décrite séparément : SSRF et rebinding sont fréquemment combinés en pratique.

Les points de terminaison de métadonnées cloud méritent une mention spéciale : chez la plupart des fournisseurs cloud, une requête émise depuis l'intérieur d'une VM vers une adresse de lien local précise peut renvoyer des identifiants, des métadonnées d'instance ou une configuration qui n'étaient jamais censés être accessibles depuis l'extérieur de la machine. Une SSRF combinée à une cible de point de terminaison de métadonnées est l'une des chaînes d'exploitation réelles les plus courantes et aux conséquences les plus lourdes, et elle commence, à chaque fois, par un nom de domaine d'apparence ordinaire.

Les filtres qui contrôlent la chaîne, pas l'adresse, ne fonctionnent pas

Une adresse IP a plus de représentations textuelles valides que n'en prévoit la plupart du code de validation. Un filtre écrit comme une comparaison de chaîne avec « 127.0.0.1 » ou « localhost » laisse passer sans encombre chacune des formes alternatives ci-dessous, car aucune ne ressemble à la chaîne recherchée.

La seule défense fiable analyse d'abord l'adresse pour obtenir sa valeur numérique réelle, puis évalue la liste de blocage sur celle-ci : exactement l'approche du résolveur de cet outil, plutôt qu'une recherche de motif sur la façon dont l'adresse a été écrite. Un résolveur renvoie une adresse normalisée, quelle que soit la façon dont l'enregistrement du nom d'hôte d'origine l'a encodée, et c'est précisément pourquoi résoudre d'abord puis valider le résultat résolu est plus robuste que d'essayer de valider une chaîne brute sous toutes les formes qu'un attaquant pourrait choisir d'écrire.

Les redirections sont l'autre contournement courant

Même un système qui résout et valide correctement l'URL initiale peut être pris en défaut par une redirection HTTP. Une requête vers une URL publique approuvée peut répondre par un 302 pointant vers une adresse interne, et un client HTTP qui suit automatiquement les redirections (le comportement par défaut de la plupart des bibliothèques) émettra volontiers cette deuxième requête sans jamais relancer la validation qui avait réussi la première fois. Toute défense contre la SSRF qui valide une seule fois, en amont, puis laisse le client HTTP sous-jacent gérer seul les redirections présente une faille exactement de même forme que celle créée par la résolution DNS, et le remède est le même : valider à nouveau, explicitement, avant de suivre toute redirection, plutôt que de présumer qu'une URL qui a passé le contrôle une fois continuera de pointer vers un endroit sûr.