Randy Code
Sécuriser un analyseur d'URL contre le SSRF
sécuritéSSRFInfraLens

Sécuriser un analyseur d'URL contre le SSRF

Publié le 10 août 2026 · 4 min de lecture · par Randy Rimbault

Tous les articles

InfraLens fait une chose simple en apparence : on lui donne une URL, il va la chercher côté serveur et l'analyse. C'est exactement la définition d'une surface SSRF (Server-Side Request Forgery) — le serveur exécute une requête réseau vers une destination entièrement choisie par le visiteur.

La menace qu'on oublie facilement

Un analyseur d'URL qui se contente d'appeler fetch(url) ira aussi bien chercher https://exemple.com qu'http://localhost, une adresse du réseau interne, ou un endpoint de métadonnées cloud. Le check a l'air neutre — "j'analyse ce que tu me donnes" — mais sans filtrage, c'est une sonde qui permet de faire parler le serveur sur son propre réseau, à la place de l'attaquant.

Le piège du DNS rebinding

Valider une IP une seule fois ne suffit pas. Un domaine peut répondre par une IP publique au moment de la validation, puis pointer vers une IP privée au moment de la connexion réelle — ou proposer plusieurs enregistrements A dont un seul est bloqué. La vraie protection, c'est que la connexion se fasse exactement sur l'IP qui a été validée, sans laisser de fenêtre entre la vérification et la requête.

Ce que j'ai mis en place

La validation d'une cible passe maintenant par un pipeline en plusieurs étapes :

  • normalisation stricte de l'URL (protocole http/https uniquement, pas d'identifiants dans l'URL, ports autorisés) ;
  • résolution DNS suivie d'une classification de l'IP obtenue, qui bloque loopback, plages privées, link-local et endpoints de métadonnées cloud, en IPv4 comme en IPv6, y compris leurs notations alternatives ;
  • une connexion épinglée sur l'IP exactement validée, pour fermer la fenêtre de DNS rebinding entre la résolution et la requête réelle ;
  • un suivi manuel des redirections, avec revalidation complète à chaque saut, plafonné à quelques sauts.

La taille de la réponse est aussi plafonnée pendant le streaming plutôt que bufferisée sans limite, pour éviter qu'une cible malveillante ne serve une réponse volontairement énorme.

Un compromis assumé

Suivre les redirections à la main plutôt que de laisser fetch les gérer automatiquement ajoute de la complexité réelle : il faut reconstruire soi-même la marche à suivre, plafonner le nombre de sauts, revalider chaque étape. C'est plus de code à maintenir. Mais faire confiance à la gestion native des redirections aurait rouvert exactement la faille qu'on vient de fermer — une redirection ne doit jamais pouvoir atteindre une cible que la validation initiale aurait refusée.

Une leçon qui dépasse le sujet SSRF

La partie la plus intéressante n'a pas été d'écrire le filtre, mais de le prouver. Un test dédié vérifie que le blocage se déclenche avant qu'aucun appel réseau ne parte réellement — pas seulement que la réponse finale semble correcte. C'est la différence entre "ça a l'air protégé" et "c'est démontré".

Techniquement, j'ai aussi buté sur un détail Node peu documenté : on ne peut pas passer un dispatcher construit avec le paquet undici standalone au fetch global de Node — les deux s'appuient sur des copies internes distinctes d'undici, incompatibles entre elles. Il faut utiliser le fetch exporté par undici lui-même, dispatcher et appel réseau sur la même instance du début à la fin. Le genre de piège qu'on ne découvre qu'en vérifiant le comportement réel, pas en relisant le code.

Résultat

Vérifié en conditions réelles : une cible légitime continue de s'analyser normalement, tandis qu'une tentative sur une adresse interne est désormais rejetée proprement, avec un message clair, avant même qu'un seul des dix-huit checks ne démarre — plus d'analyse partielle silencieusement trompeuse.

Conclusion

Toute application qui va chercher une URL fournie par un utilisateur doit traiter le SSRF comme une menace principale, dès la conception — pas comme un correctif qu'on ajoute une fois le produit déjà en ligne. C'est un des chantiers de sécurité les plus formateurs que j'ai menés sur InfraLens : la logique est simple à énoncer, mais chaque raccourci qu'on se permet en cours de route rouvre la porte qu'on venait de fermer.