Applications, sites et API
Particuliers et entreprisesFalsification de requête côté serveur
Server-side request forgery — SSRF
Un serveur est amené à contacter une destination choisie par l’attaquant.
Je pense être concerné : que faire ?
Comprendre et agir
À la fin de cette lecture, vous pourrez expliquer le piège et choisir une première réaction adaptée à votre rôle. Aucun prérequis informatique n’est nécessaire.
Une situation concrète
Un site propose d’importer une image depuis une adresse web. Au lieu d’une image publique, un attaquant lui indique une destination interne. Le serveur peut alors contacter un service que le visiteur ne pourrait pas atteindre directement.
Comment cela fonctionne
Une SSRF détourne les requêtes envoyées par un serveur. L’application devient un intermédiaire involontaire vers une autre ressource. Le risque dépend des destinations accessibles, des informations renvoyées et des droits du serveur. Un outil qui importe des liens, produit des aperçus ou appelle des webhooks doit donc contrôler où il se connecte, pas seulement l’apparence de l’adresse.
- Une adresse est fournie
Import, aperçu ou notification.
- Le serveur la visite
Avec son propre accès au réseau.
- Une ressource privée est atteinte
Données ou services internes.
Ce que vous pouvez faire
Vos premiers réflexes
Cette faille se corrige chez l’exploitant du service. Si un import vous renvoie des données internes inattendues, signalez le résultat sans essayer d’autres adresses.
Si vous êtes responsable du service ou de l’organisation
Développeurs et administrateurs : contrôlez les destinations réellement jointes par le serveur, y compris après redirection, et limitez ses sorties vers les réseaux privés.
Une adresse qui commence par HTTPS n’est pas automatiquement une destination sûre pour un serveur.
À vous de décider
L’import d’une image renvoie des informations internes au service. Est-ce à vous d’essayer d’autres adresses pour comprendre ?
Choisissez votre réponse et expliquez pourquoi avant de lire la correction.
Voir la réponse expliquée
Non. Signalez le résultat et l’adresse initialement fournie, sans poursuivre l’exploration. C’est le serveur qui effectue la recherche avec ses propres accès ; son exploitant doit contrôler les destinations qu’il peut joindre.
Analyser un cas technique
Pour les personnes qui développent, administrent ou analysent les systèmes concernés. Commencez par « Comprendre et agir » si ces notions sont nouvelles pour vous.
Étude de cas fictive
Le serveur est utilisé pour atteindre une ressource interne
Dans une SSRF, l’attaquant fait effectuer une requête par le serveur. Le serveur peut atteindre des adresses auxquelles le navigateur n’a pas accès : réseau interne, interface d’administration ou service de métadonnées cloud. Le risque dépend donc des accès du serveur qui effectue la requête, pas seulement de ceux du compte utilisateur.
Le cas présenté commence par une URL publique qui redirige vers une adresse privée. Vérifier uniquement la première URL laisse passer cette seconde destination. Il faut examiner chaque redirection et l’adresse réellement jointe. Une résolution DNS peut changer entre le contrôle et la connexion ; une validation faite trop tôt ne garantit pas la destination finale.
Quand le besoin métier le permet, proposer une référence de ressource ou un fournisseur connu est plus facile à contrôler qu’une URL libre. Si les URL libres sont nécessaires, les restrictions doivent couvrir le schéma, les destinations, les redirections et les sorties réseau du service.
Les journaux HTTP de l’application ne montrent pas toujours la requête effectuée en arrière-plan. Pour mesurer l’accès, rapprocher le travail déclenché, les résolutions DNS et les connexions sortantes. Une tentative bloquée par le pare-feu n’a pas le même résultat qu’une réponse interne retournée à l’utilisateur.
Le déroulement en schéma
Faites défiler le diagramme pour suivre les échanges ; les noms des acteurs restent en haut. Sur petit écran, faites aussi défiler de gauche à droite.
- Action
Référence ou URL d’image
Utilisateur vers Importateur
Trace job=j14
- Action
GET initial
Importateur vers Serveur externe
Trace hop=0
- Réponse
302 vers une adresse privée
Serveur externe vers Importateur
Trace Location
- Action
Connexion secondaire non autorisée
Importateur vers Service privé
Trace connected_ip
- Réponse
Réponse stockée comme aperçu
Service privé vers Importateur
Trace bytes=42012
- Refus / blocage
Après correction : sortie réseau refusée
Importateur vers Service privé
Trace Règle réseau
Comment repérer cette attaque
Indices à rechercher
- Le serveur contacte des adresses internes sans besoin métier.
- Des imports de liens entraînent des erreurs ou délais inhabituels.
- Des accès aux métadonnées cloud suivent une requête utilisateur.
Rechercher les connexions du service vers des réseaux ou services qui ne font pas partie de sa fonction, y compris après une redirection.
Éléments à croiser
Partir du job de téléchargement et suivre toutes les redirections. Rapprocher l’adresse effectivement jointe des flux du serveur ; tenir compte du proxy de sortie et de la traduction d’adresses.
Limites de l’interprétation
Une URL initiale publique ne garantit pas une destination finale publique. Inversement, voir un paquet bloqué ne prouve pas que le serveur a lu une réponse interne.
Comment réagir
Restreindre les sorties réseau du service d’import et conserver les références des tâches concernées. Retrouver les réponses qui ont été stockées ou renvoyées à l’utilisateur. Vérifier si des secrets ont été accessibles, puis les renouveler et rechercher leur utilisation. Retirer les fichiers exposés après avoir préservé les éléments utiles à l’enquête.
Vérifier la correction
Ces contrôles s’adressent à l’équipe responsable du système. Les simulations se préparent dans un environnement de test autorisé ; la lecture du cas ne nécessite aucune manipulation.
- Une URL publique redirigeant vers une destination interne interdite doit être refusée.
- La restriction réseau doit s’appliquer au service qui télécharge réellement la ressource, y compris aux tâches différées.
- Les fournisseurs et ressources autorisés doivent rester accessibles.
À vous de raisonner
L’URL initiale est publique, mais elle redirige vers une adresse privée. Quelle étape du contrôle manque si le téléchargement réussit ?
Formulez votre décision et l’élément qui la justifie avant d’ouvrir la correction.
Comparer avec le raisonnement expliqué
Le contrôle doit couvrir chaque redirection et la destination réellement jointe. Une validation de l’URL de départ ne suffit pas. Vérifiez également les restrictions réseau du composant qui télécharge, y compris s’il travaille dans une tâche différée.
Consulter les détails techniques
Pour aller plus loin après l’étude du cas : les extraits servent à s’exercer à la lecture des traces ; le guide de collecte aide les personnes qui disposent des outils et des accès nécessaires.
Lire les extraits commentés — reconstitution fictive
Ces extraits utilisent des valeurs fictives. Certains reprennent des champs documentés ; d’autres regroupent plusieurs sources dans un format pédagogique. Ce ne sont pas des exports bruts à retrouver tels quels dans vos outils. Commencez par les champs expliqués, puis retrouvez-les dans les extraits.
resolved_ip- Adresse obtenue par résolution dans la reconstitution ; elle doit être enregistrée à chaque étape, pas déduite d’une résolution effectuée après l’incident.
bytes- Quantité reçue dans le cas fictif, pas preuve du contenu exact ni de sa remise à l’attaquant.
Du lien public à une destination privée
JournalJournal fictif d’un import, avec chaque redirection et la destination réellement contactée.
job=j14 actor=u8 requested_url=https://images.example.test/logo
job=j14 hop=0 status=302 location=http://10.20.0.8/admin/export
job=j14 hop=1 resolved_ip=10.20.0.8 port=80 network_zone=management
job=j14 hop=1 connect=allowed response_status=200 bytes=42012
job=j14 output=stored bucket=previews object=j14.binPréparer une collecte dans votre environnement
Choisissez les sources qui correspondent à vos outils et à votre périmètre d’intervention. Cette liste n’est pas un équipement requis pour comprendre la fiche. Vérifiez que les journaux nécessaires étaient activés pendant la période étudiée. Conservez l’export original, son fuseau horaire et sa provenance dans un espace à accès restreint ; travaillez sur une copie expurgée des secrets.
Service concerné — audit et historique à vérifier
- Où les trouver
- Dans l’outil d’administration ou les journaux du service concerné. Demander à son mainteneur où sont enregistrées les décisions d’autorisation et les opérations métier.
- Quoi relever
- Dans le service qui télécharge une URL, rechercher le job, l’URL initiale, chaque redirection, les adresses résolues et la décision de connexion. Prévoir ces champs si le client HTTP ne les expose pas.
- Accès et prérequis
- Il n’existe ni fichier ni vocabulaire universels. Les champs proposés ici doivent être instrumentés s’ils manquent ; ne pas enregistrer mots de passe, jetons ou contenu privé intégral.
Sonde réseau Zeek — conn.log
- Où les trouver
- Sur une sonde déjà placée sur le trajet du trafic, ou dans le collecteur de ses journaux conn.log. Identifier le point d’observation, notamment avant ou après traduction d’adresses.
- Quoi relever
- Chercher une connexion sortant du serveur applicatif vers l’adresse et le port internes visés. Les adresses source et destination et les volumes confirment un échange réseau, sans montrer forcément la ressource demandée.
- Accès et prérequis
- La sonde doit avoir vu le trafic. uid, adresses, ports, orig_bytes et resp_bytes décrivent les échanges observés ; les octets réseau ne sont pas le contenu d’un document ni son destinataire humain.
Dans l’histoire des cyberattaques
Groupes et campagnes documentés
Des faits réels pour situer ce mécanisme. Les années sont celles des faits ; chaque notice précise qui établit le lien avec le groupe ou la campagne.
- GroupeHAFNIUM
Exchange : enchaîner plusieurs failles pour entrer
Microsoft décrit des intrusions dans des serveurs Exchange installés chez les organisations. Une SSRF permet de contourner une étape d’authentification ; une désérialisation non sûre peut ensuite permettre l’exécution de code avec des droits élevés. Des courriels deviennent accessibles aux attaquants.
Ce qu’établit la source. Microsoft attribue avec une confiance élevée les premières attaques ciblées à HAFNIUM. L’éditeur signale ensuite l’exploitation de ces mêmes failles par d’autres acteurs.
Consulter le rapport HAFNIUM targeting Exchange Servers with 0-day exploitsMicrosoft · Publié le
Sélection de cas documentés, non exhaustive. Une technique peut être utilisée par de nombreux acteurs. Les cas fictifs de la fiche ne sont attribués à aucun de ces groupes.
Si vous pensez être concerné
Si vous utilisez le service
Cette faille se corrige chez l’exploitant du service. Si un import vous renvoie des données internes inattendues, signalez le résultat sans essayer d’autres adresses.
Pour l’équipe qui exploite le service
- Suspendez le chemin de requête vulnérable ou restreignez ses sorties.
- Examinez les destinations réellement contactées.
- Révoquez les secrets si des services internes ou métadonnées ont pu en fournir.
Pour qualifier votre situation et être orienté : obtenir une assistance sur 17Cyber. Dans une organisation, prévenez aussi le responsable ou prestataire chargé de la sécurité.
Sources et repères pour approfondir
- OWASP — SSRF Prevention — cheatsheetseries.owasp.org
- AWS — IMDSv2 — docs.aws.amazon.com
