SSRF : quand le serveur travaille pour l'attaquant
La SSRF (Server-Side Request Forgery) amène un serveur à émettre des requêtes choisies par l'attaquant, parfois jusqu'au cœur du réseau interne. Une faille sous-estimée, qu'une protection trop simple ne suffit pas à arrêter.
Qu'est-ce qu'une vulnérabilité SSRF ?
Beaucoup d'applications récupèrent une ressource à partir d'une URL fournie par l'utilisateur (import d'une image depuis un lien, prévisualisation, appel à un service tiers…). Si cette URL n'est pas rigoureusement contrôlée, l'attaquant peut la détourner pour faire émettre au serveur des requêtes de son choix.
L'enjeu : le serveur dispose souvent d'un accès privilégié à des ressources inaccessibles depuis l'extérieur : réseau interne, services d'administration, métadonnées d'hébergement cloud. La SSRF transforme alors le serveur en relais pour explorer et atteindre ces ressources. C'est un grand classique des tests d'intrusion applicatifs.
Ce qu'un attaquant peut viser
Cartographier le réseau interne
En faisant pointer le serveur vers des adresses internes, l'attaquant élargit sa connaissance de votre surface d'attaque et découvre les machines et services normalement invisibles depuis l'extérieur.
Atteindre le serveur lui-même
En ciblant l'hôte local, il peut accéder à des interfaces d'administration ou à des services internes supposés protégés.
Voler des secrets cloud
Sur certaines infrastructures, les services de métadonnées internes peuvent exposer des identifiants temporaires si le serveur est manipulé pour les interroger.
Contourner les filtres
Encodages alternatifs, domaines pointant vers une IP interne, redirections : de nombreuses techniques contournent les filtres trop simples. Des outils automatisent même l'exploitation.
Pourquoi une protection « simple » ne suffit pas
Filtrer naïvement les valeurs « localhost » ou « 127.0.0.1 » donne une fausse impression de sécurité. Les contournements sont nombreux : un domaine qui résout vers une adresse interne, une notation IP alternative, une redirection… Une SSRF non traitée peut servir de tremplin vers une intrusion plus profonde, d'où l'intérêt de la traiter sérieusement, dans le cadre d'une sécurité applicative rigoureuse.
Le bon réflexe : contrôler la destination, pas seulement l'entrée
Se protéger d'une SSRF ne consiste pas à « interdire quelques mots-clés ». Il s'agit de valider la destination réelle de la requête : limiter les protocoles autorisés, n'accepter que des destinations explicitement approuvées (liste blanche), bloquer l'accès aux plages d'adresses internes et aux services de métadonnées, et maîtriser les redirections. Ces contrôles se valident par un test d'intrusion ciblé.
Se protéger, étape par étape
Restreindre par liste blanche
N'autoriser que des destinations et des domaines explicitement approuvés, plutôt que de tenter de bloquer ce qui est « interdit ».
Limiter les protocoles
Autoriser uniquement les protocoles nécessaires (souvent HTTPS) et rejeter les schémas détournables.
Bloquer les adresses internes
Interdire l'accès aux plages d'adresses privées et aux services de métadonnées de l'hébergement, après résolution réelle de l'adresse.
Maîtriser les redirections
Contrôler ou désactiver le suivi automatique des redirections, qui sert souvent à contourner les filtres d'entrée.
Cloisonner le serveur
Segmenter le réseau et appliquer le moindre privilège pour limiter ce qu'une SSRF réussie permettrait réellement d'atteindre.
Pourquoi se faire accompagner par BCIT ?
Une évaluation réaliste
Nous éprouvons les contournements réels pour mesurer l'exposition effective de vos applications à la SSRF.
Des mesures proportionnées
Des recommandations claires, du correctif applicatif au cloisonnement réseau, priorisées par impact.
Une approche d'ensemble
De la sécurité applicative aux audits de sécurité, nous couvrons toute la chaîne.
Pas encore prêt à échanger ? Découvrez notre diagnostic cybersécurité →
Votre serveur ne doit travailler que pour vous
Prenons 15 minutes pour évaluer l'exposition de vos applications à la SSRF et définir les protections réellement efficaces.
SSRF : quand le serveur travaille pour l'attaquant
La SSRF (Server-Side Request Forgery) amène un serveur à émettre des requêtes choisies par l'attaquant, parfois jusqu'au cœur du réseau interne. Une faille sous-estimée, qu'une protection trop simple ne suffit pas à arrêter.
Qu'est-ce qu'une vulnérabilité SSRF ?
Beaucoup d'applications récupèrent une ressource à partir d'une URL fournie par l'utilisateur (import d'une image depuis un lien, prévisualisation, appel à un service tiers…). Si cette URL n'est pas rigoureusement contrôlée, l'attaquant peut la détourner pour faire émettre au serveur des requêtes de son choix.
L'enjeu : le serveur dispose souvent d'un accès privilégié à des ressources inaccessibles depuis l'extérieur : réseau interne, services d'administration, métadonnées d'hébergement cloud. La SSRF transforme alors le serveur en relais pour explorer et atteindre ces ressources. C'est un grand classique des tests d'intrusion applicatifs.
Ce qu'un attaquant peut viser
Cartographier le réseau interne
En faisant pointer le serveur vers des adresses internes, l'attaquant élargit sa connaissance de votre surface d'attaque et découvre les machines et services normalement invisibles depuis l'extérieur.
Atteindre le serveur lui-même
En ciblant l'hôte local, il peut accéder à des interfaces d'administration ou à des services internes supposés protégés.
Voler des secrets cloud
Sur certaines infrastructures, les services de métadonnées internes peuvent exposer des identifiants temporaires si le serveur est manipulé pour les interroger.
Contourner les filtres
Encodages alternatifs, domaines pointant vers une IP interne, redirections : de nombreuses techniques contournent les filtres trop simples. Des outils automatisent même l'exploitation.
Pourquoi une protection « simple » ne suffit pas
Filtrer naïvement les valeurs « localhost » ou « 127.0.0.1 » donne une fausse impression de sécurité. Les contournements sont nombreux : un domaine qui résout vers une adresse interne, une notation IP alternative, une redirection… Une SSRF non traitée peut servir de tremplin vers une intrusion plus profonde, d'où l'intérêt de la traiter sérieusement, dans le cadre d'une sécurité applicative rigoureuse.
Le bon réflexe : contrôler la destination, pas seulement l'entrée
Se protéger d'une SSRF ne consiste pas à « interdire quelques mots-clés ». Il s'agit de valider la destination réelle de la requête : limiter les protocoles autorisés, n'accepter que des destinations explicitement approuvées (liste blanche), bloquer l'accès aux plages d'adresses internes et aux services de métadonnées, et maîtriser les redirections. Ces contrôles se valident par un test d'intrusion ciblé.
Se protéger, étape par étape
Restreindre par liste blanche
N'autoriser que des destinations et des domaines explicitement approuvés, plutôt que de tenter de bloquer ce qui est « interdit ».
Limiter les protocoles
Autoriser uniquement les protocoles nécessaires (souvent HTTPS) et rejeter les schémas détournables.
Bloquer les adresses internes
Interdire l'accès aux plages d'adresses privées et aux services de métadonnées de l'hébergement, après résolution réelle de l'adresse.
Maîtriser les redirections
Contrôler ou désactiver le suivi automatique des redirections, qui sert souvent à contourner les filtres d'entrée.
Cloisonner le serveur
Segmenter le réseau et appliquer le moindre privilège pour limiter ce qu'une SSRF réussie permettrait réellement d'atteindre.
Pourquoi se faire accompagner par BCIT ?
Une évaluation réaliste
Nous éprouvons les contournements réels pour mesurer l'exposition effective de vos applications à la SSRF.
Des mesures proportionnées
Des recommandations claires, du correctif applicatif au cloisonnement réseau, priorisées par impact.
Une approche d'ensemble
De la sécurité applicative aux audits de sécurité, nous couvrons toute la chaîne.
Pas encore prêt à échanger ? Découvrez notre diagnostic cybersécurité →
Votre serveur ne doit travailler que pour vous
Prenons 15 minutes pour évaluer l'exposition de vos applications à la SSRF et définir les protections réellement efficaces.