SSRF : requêtes serveur vers des destinations contrôlables

Une vulnérabilité de type SSRF (Server-Side Request Forgery) apparaît lorsqu'une application web côté serveur effectue un appel réseau HTTP ou TCP vers une destination dont l'adresse (URL, nom d'hôte ou port) est partiellement ou totalement influencée par une entrée utilisateur, sans vérification réseau rigoureuse.

L'impact d'une SSRF réside dans la position de confiance qu'occupe votre serveur : le serveur se situe souvent au sein d'un réseau interne ou d'un VPC, ce qui lui permet d'atteindre des services inaccessibles depuis l'Internet public.

Les cas d'usage typiques à l'origine d'une SSRF

Les fonctionnalités modernes qui requièrent que le serveur télécharge une ressource externe sont particulièrement exposées si les destinations ne sont pas encadrées :

• L'import par URL : Téléchargement d'un avatar, d'un document PDF ou d'une image depuis une adresse saisie par l'utilisateur.
• La génération d'aperçus de liens (Unfurl / OpenGraph) : Récupération des balises meta d'une page web partagée dans un chat ou un article.
• Les webhooks sortants : Notification d'un service client tiers en envoyant un événement HTTP POST vers une URL fournie dans ses paramètres.
• Les proxys d'API ou passerelles de capture d'écran : Services convertissant une page web externe en image ou en document.

Dans chacun de ces scénarios, si l'URL fournie est acceptée aveuglément par la fonction fetch ou une bibliothèque HTTP côté serveur, un visiteur peut détourner le comportement du serveur.

Quels sont les risques concrets ?

Lorsqu'un attaquant parvient à manipuler la destination de la requête serveur, il peut cibler plusieurs actifs stratégiques :

1. Les services d'infrastructure et metadata cloud

Dans les environnements cloud (AWS, Google Cloud, Azure, DigitalOcean), les instances et conteneurs ont souvent accès à un point d'accès de métadonnées interne via une adresse IP link-local non routable (typiquement 169.254.169.254 ou des endpoints de métadonnées de conteneurs). Si la requête serveur atteint cet endpoint, elle peut extraire des jetons d'authentification temporaires et des informations d'infrastructure sensibles.

2. Les interfaces d'administration et services internes

De nombreuses architectures disposent de bases de données, de caches (Redis, Memcached), de panneaux d'administration ou de métriques internes configurés sur le réseau local (localhost, 127.0.0.1 ou des plages privées RFC 1918 telles que 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Ces services ne requièrent parfois aucune authentification supplémentaire, car ils reposent sur l'hypothèse qu'ils ne sont pas joignables depuis l'extérieur. Une SSRF permet de contourner cette séparation.

3. Le scan de ports et cartographie réseau

Même sans réponse de contenu directe, la mesure du temps de réponse ou les messages d'erreur HTTP retournés par le serveur permettent de cartographier l'ensemble des ports et machines actives sur le réseau interne de votre application.

Pourquoi les deny-lists sont fragiles face au risque SSRF

L'erreur la plus fréquente face à une SSRF consiste à s'en remettre exclusivement à une liste d'exclusion (deny-list ou liste noire) ou à une simple expression régulière (regex). Les deny-lists sont contournables et constituent généralement une défense de dernier recours ; une allowlist (liste d'autorisation stricte) est toujours préférable lorsqu'elle est compatible avec le besoin métier.

Les mécanismes de contournement fréquents des deny-lists comprennent :

• Le piège de la résolution DNS (DNS Rebinding) : Un attaquant peut configurer un domaine personnel qui résout initialement vers une adresse IP publique légitime lors du test de validation de votre application, puis bascule vers l'adresse privée 127.0.0.1 quelques millisecondes plus tard lorsque la fonction fetch exécute la vraie requête.
• Les représentations alternatives d'adresses : Une regex filtrant 127.0.0.1 ou localhost peut être contournée par des notations hexadécimales (0x7f000001), décimales (2130706433), IPv6 (::1), ou des domaines de redirection génériques (comme 127.0.0.1.nip.io).
• Les redirections HTTP automatiques : Votre validation initiale accepte une URL externe https://domaine-legitime.com/redirect. Le serveur s'y connecte, mais ce domaine renvoie une redirection HTTP 302 vers http://169.254.169.254/latest/meta-data/. Si le client HTTP suit les redirections par défaut, la protection de surface est contournée.

La stratégie de défense multi-couches

Une protection anti-SSRF rigoureuse nécessite de dissocier la validation syntaxique de la validation réseau effective au moment de la connexion.

Entrée utilisateur (URL)
          │
          ▼
1. Validation du protocole (Autoriser uniquement http/https)
          │
          ▼
2. Liste blanche stricte de domaines autorisés (si le cas d'usage le permet)
          │
          ▼
3. Résolution DNS explicite (Vérification de l'IP résolue AVANT connexion)
          │
          ├── Si IP privée / link-local / loopback ──► REFUS IMMÉDIAT
          │
          ▼
4. Connexion directe sur l'IP validée avec gestion stricte des redirections

1. Préférer une liste d'autorisation stricte (Allowlist)

Si votre fonctionnalité consiste à importer des données depuis des plateformes définies (par exemple uniquement GitHub ou Unsplash), validez le nom d'hôte contre une liste blanche exacte et immuable.

2. Valider l'adresse IP après résolution DNS

Si l'application doit pouvoir contacter n'importe quel site web public (comme un lecteur de flux RSS ou un crawler), vous devez résoudre le nom d'hôte en adresse IP, vous assurer que cette adresse IP n'appartient à aucune plage réservée, privée ou de boucle locale, puis initier la connexion directement sur cette IP validée (en passant le domaine dans l'en-tête Host).

3. Désactiver ou contrôler les redirections HTTP

Configurez votre bibliothèque de requêtes HTTP pour qu'elle ne suive pas aveuglément les redirections externes (redirect: 'manual'), ou réappliquez l'ensemble des contrôles de sécurité sur chaque nouvelle URL de redirection.

Ce que GVO observe dans le code

Lors d'un audit de sécurité, GVO analyse les flux de données serveur :

• Ce que GVO peut observer : GVO repère les points d'entrée serveur (Route Handlers, Server Actions) où une valeur transmise par le client est injectée dans les arguments d'une fonction d'appel réseau (fetch, axios, etc.) sans contrôle ou validation démontrable de la destination.
• Ce que GVO ne peut pas garantir : Une analyse statique observe la présence de gardes et de contrôles dans le code applicatif. Elle ne remplace pas une configuration de sécurité réseau au niveau de l'infrastructure d'hébergement (règles de pare-feu sortant, isolation de sous-réseau VPC).

Pour vérifier les autres surfaces critiques d'une application avant sa mise en ligne, consultez notre Checklist de production pour applications web.