Applications, sites et API
Particuliers et entreprisesFalsification de requête côté serveur
Server-side request forgery — SSRF
L’attaquant fait contacter par le serveur une adresse qu’il a choisie.
Je pense être concerné : que faire ?
Comprendre et agir
Découvrez le piège à partir d’un exemple, puis les gestes que vous pouvez faire. Vous pouvez suivre cette lecture sans connaissances en informatique.
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 attaque SSRF pousse un serveur à envoyer une requête vers une destination choisie par l’attaquant. L’application lui sert alors d’intermédiaire. Le risque dépend de ce que le serveur peut joindre, des informations qu’il renvoie et des droits dont il dispose. Les outils qui importent un lien, créent un aperçu ou appellent un webhook doivent contrôler la destination réelle de la connexion, au-delà de 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 doivent contrôler où le serveur se connecte réellement, y compris après une redirection, et limiter ses accès sortants aux 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 ?
Prenez un moment pour répondre et expliquer votre choix, puis ouvrez la correction.
Voir la réponse expliquée
Non. Signalez le résultat et l’adresse que vous aviez fournie, puis arrêtez l’exploration. Le serveur fait la requête avec ses propres accès. Son exploitant doit vérifier quelles destinations il peut contacter.
Analyser un cas technique
Ce cas s’adresse aux personnes qui développent, administrent ou analysent ces systèmes. Si vous découvrez le sujet, commencez par « Comprendre et agir ».
Étude de cas fictive
Le serveur est utilisé pour atteindre une ressource interne
Dans une SSRF, le serveur envoie une requête pour le compte de l’attaquant. Il peut avoir accès à un réseau interne, à une interface d’administration ou aux métadonnées cloud que le navigateur ne peut pas joindre. Pour évaluer le risque, examinez donc les accès du serveur qui fait la requête, en plus de ceux de l’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.
Quelles informations comparer
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.
Ce que ces indices ne permettent pas de conclure
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
L’équipe responsable du système peut utiliser ces contrôles dans un environnement de test autorisé. Vous pouvez lire et comprendre le cas sans effectuer ces manipulations.
- 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 ?
Quelle décision prendriez-vous, et sur quel indice vous appuieriez-vous ? Répondez 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
Les extraits permettent de s’exercer à lire les traces du cas. Si vous disposez des outils et des accès nécessaires, le guide de collecte vous aide aussi à rechercher ces informations.
Lire les extraits commentés (reconstitution fictive)
Ces extraits contiennent des valeurs fictives. Certains champs correspondent à ceux des outils documentés ; d’autres réunissent plusieurs sources pour faciliter l’explication. Vos propres exports pourront donc avoir une autre forme. Lisez d’abord les explications des champs, puis repérez-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
Utilisez les sources disponibles dans vos outils et auxquelles vous êtes autorisé à accéder. Vous pouvez comprendre la fiche sans posséder ces outils. Vérifiez que les journaux étaient activés pendant la période étudiée. Gardez l’export original avec son fuseau horaire et sa provenance dans un espace à accès restreint. Pour l’analyse, travaillez sur une copie dont vous avez retiré les 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
Ces cas réels montrent où ce mécanisme a été observé. Les années indiquent quand les faits ont eu lieu. Chaque notice précise la source qui les relie à un groupe ou à une campagne.
- GroupeHAFNIUM
Exchange : enchaîner plusieurs failles pour entrer
Microsoft décrit des intrusions dans des serveurs Exchange hébergés par les organisations. Une SSRF contourne une étape d’authentification ; une désérialisation non sûre peut ensuite faire exécuter du code avec des droits élevés. Les attaquants peuvent alors accéder aux courriels.
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
Cette sélection ne couvre pas tous les incidents. Plusieurs acteurs peuvent utiliser une même technique. Les exemples fictifs de la fiche ne décrivent les actions d’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 comprendre votre situation et trouver de l’aide : 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
