SSRF : faire parler votre serveur à votre place

Le principe

Beaucoup de fonctionnalités demandent au SERVEUR d’aller chercher une ressource à une URL donnée par le visiteur : télécharger un avatar depuis un lien, générer un aperçu de page, valider un webhook entrant.

SSRF (Server-Side Request Forgery) survient quand un attaquant remplace cette URL par une adresse qu’il ne pourrait jamais atteindre lui-même directement, mais que le SERVEUR, lui, peut parfaitement atteindre — typiquement le réseau interne de l’entreprise qui l’héberge.

Un exemple concret

Un champ « URL de votre logo » qui télécharge l’image côté serveur. Au lieu d’une vraie image, l’attaquant fournit l’adresse du service de métadonnées interne propre aux plateformes cloud (AWS, GCP, Azure) — une adresse strictement invisible et inatteignable depuis l’extérieur du réseau.

Le serveur, qui EST autorisé à atteindre cette adresse depuis l’intérieur, s’y connecte à la place de l’attaquant et lui restitue potentiellement des identifiants d’accès cloud complets dans sa propre réponse.

Pourquoi c’est grave

Une SSRF exploitée donne accès au réseau interne depuis l’extérieur, en utilisant le serveur comme relais de confiance : bases de données internes normalement inaccessibles, panneaux d’administration réservés au réseau local, et sur le cloud, des identifiants qui permettent parfois de prendre le contrôle de l’infrastructure entière.

OWASP l’a ajoutée en 2021 comme catégorie à part entière du Top 10 (A10:2021), reconnaissant son importance grandissante avec la généralisation des architectures cloud.

Comment s’en protéger

Ne jamais faire confiance à une URL fournie par le visiteur pour une requête sortante déclenchée côté serveur. Utiliser une liste blanche stricte de domaines et de schémas autorisés plutôt qu’une liste noire, toujours contournable d’une façon ou d’une autre.

Bloquer explicitement les plages d’adresses privées et l’adresse de métadonnées cloud au niveau réseau, pas seulement au niveau applicatif. Désactiver les redirections automatiques lors de la requête sortante, ou les revalider intégralement à chaque saut.

Comment SauronSec la détecte

Plusieurs signaux combinés : présence de signatures de métadonnées cloud dans la réponse (masquées avant tout affichage, jamais exposées telles quelles dans le rapport final), erreurs réseau typiques d’une tentative de connexion interne, délai de réponse anormal vers une adresse non routable qui trahit une connexion bloquée en cours de tentative.

Pour les cas totalement invisibles dans la réponse, un canal hors-bande (un rappel DNS ou HTTP vers un collecteur neutre et contrôlé) confirme que le serveur a bien émis la requête demandée, sans jamais dépendre d’un signal visible dans la réponse elle-même.