SSRF

01 — DéfinitionQu'est-ce qu'une SSRF ?

La SSRF (Server-Side Request Forgery, falsification de requête côté serveur) est une attaque qui consiste à manipuler un serveur pour qu'il effectue des requêtes HTTP vers des ressources que l'attaquant ne pourrait pas atteindre directement depuis l'extérieur.

Le contexte applicatif

De nombreuses applications web proposent des fonctions qui nécessitent d'aller chercher une ressource à partir d'une URL :

• Import d'image depuis une URL (avatar, couverture, pièce jointe).
• Prévisualisation de lien (comme dans Slack, Discord, messageries).
• Conversion PDF de page web.
• Webhook et API callback.
• Test de connexion (« ping cette URL »).
• Récupération de flux RSS, feed, API tierce.
• Scraping légitime / aggregation.
• Services de capture d'écran d'URL.

Le problème

Si l'URL fournie par l'utilisateur n'est pas correctement validée, l'attaquant peut fournir :

• http://192.168.1.100/admin : accès à un service interne.
• http://169.254.169.254/latest/meta-data/ : métadonnées AWS et credentials IAM.
• file:///etc/passwd : lecture de fichiers locaux.
• http://localhost:8080/ : service admin sur la même machine.
• http://metadata.google.internal/ : équivalent GCP.
• http://10.0.0.5:22 : port scan interne.

Le serveur effectue la requête depuis sa position réseau privilégiée et retourne (ou pas) le résultat à l'attaquant.

Analogie : un complice à l'intérieur

Imaginez que vous voulez entrer dans un bureau sécurisé où vous n'avez pas le droit. Vous ne pouvez pas le faire vous-même, mais vous convainquez un employé légitime d'y aller et de vous rapporter ce qu'il voit. SSRF = même logique avec un serveur au lieu d'un humain.

Ajout tardif à l'OWASP Top 10

La SSRF est entrée dans l'OWASP Top 10 en 2021 (catégorie A10:2021) suite à la multiplication des incidents cloud. Avant cela, elle existait mais était moins considérée comme critique — l'avènement du cloud avec ses métadonnées sensibles a changé la donne.

La SSRF est une vulnérabilité où le serveur devient votre proxy malgré lui : il voit ce que vous ne devriez pas voir, il accède à ce que vous ne devriez pas atteindre. Dans un datacenter fermé, l'impact reste limité. Dans un cloud où chaque VM a des credentials IAM accessibles via HTTP local, l'impact devient total.

02 — FonctionnementComment exploite-t-on une SSRF

Exemple classique : import d'avatar

Une application permet d'importer un avatar depuis une URL :

POST /api/avatar
Content-Type: application/json

{"url": "https://example.com/photo.jpg"}

Le backend fait :

// Pseudo-code vulnérable
function importAvatar(url) {
  const response = fetch(url);  // Aucune validation
  const content = response.body;
  return saveImage(content);
}

L'attaquant remplace l'URL par :

{"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}

Le serveur récupère obligeamment les credentials IAM et les renvoie dans la réponse à l'attaquant.

Les protocoles alternatifs

Au-delà de HTTP, certains clients HTTP ou bibliothèques supportent d'autres schémas :

• file:// : lire un fichier local (file:///etc/passwd, file:///proc/self/environ).
• gopher:// : protocole texte utilisable pour forger des requêtes vers des services non-HTTP (SMTP, Redis, MySQL). Très puissant pour passer de SSRF à RCE.
• dict:// : protocole dictionnaire, utile pour envoyer des requêtes arbitraires.
• ftp:// : ancien FTP.
• ldap:// : accès LDAP.
• jar:// : en Java, peut lire des archives.

Les bibliothèques comme libcurl supportent des dizaines de protocoles par défaut — chacun est une surface d'attaque.

Contournement de validation

Les validations naïves côté serveur sont souvent contournables :

Représentations alternatives d'IP

• 127.0.0.1 → 2130706433 (décimal), 0x7F000001 (hex), 017700000001 (octal), [::1] (IPv6).
• 127.0.0.1 → 127.1 (forme abrégée), 127.0.1.
• localhost, 0.0.0.0, noms DNS qui résolvent en interne.

DNS rebinding

Le domaine attacker.com résout d'abord en IP publique (pour passer la validation), puis en 127.0.0.1 juste avant la requête réelle. Protection : résoudre le DNS une fois puis utiliser l'IP directement pour la validation ET la requête.

Redirections HTTP

Le serveur reçoit https://attacker.com/redirect qui redirige en 302 vers http://169.254.169.254/. Si le client HTTP suit automatiquement les redirections, la destination finale contourne la validation initiale.

Encodages URL

• URL-encoding : %31%32%37%2e%30%2e%30%2e%31 = 127.0.0.1.
• Double-encoding : %2531%2532%2537%252e....
• Encodages Unicode exotiques.

Ouverture de ports alternatifs

Scanner les ports internes en comparant les temps de réponse ou les erreurs : http://10.0.0.5:22 échoue rapidement si port fermé, timeout long si filtré, erreur HTTP différente si port ouvert mais pas HTTP.

Chaîner avec d'autres vulnérabilités

• SSRF + XXE : un parseur XML vulnérable peut être forcé de faire des SSRF via les entités externes.
• SSRF + désérialisation : certaines bibliothèques de sérialisation font des requêtes lors de la désérialisation.
• SSRF + RCE via Redis/Memcached : gopher:// permet d'envoyer des commandes à des services internes non protégés.
• SSRF + injection de commandes : certaines SSRF mènent à l'exécution de code en exploitant des endpoints internes.

03 — TypesVariantes d'exploitation

SSRF classique (réponse visible)

L'attaquant voit directement le contenu récupéré par le serveur. C'est la forme la plus exploitable : lecture de documents internes, pages d'administration, métadonnées cloud retournées telles quelles dans la réponse.

Blind SSRF

Le serveur effectue la requête mais ne retourne pas le contenu à l'attaquant. Plus difficile mais encore dangereux. Techniques de détection :

• Timing attack : mesurer les différences de temps de réponse pour déduire l'existence de services internes (port scan via SSRF aveugle).
• Codes d'erreur HTTP : 200 vs 404 vs 503 révèlent des informations.
• Callbacks DNS : forcer le serveur à résoudre unique-id.attacker.com, vérifier sur le DNS de l'attaquant si la requête arrive.
• Callbacks HTTP : Burp Collaborator, interact.sh génèrent des URLs uniques, détectent les callbacks.
• Erreurs applicatives : des erreurs différentes selon ce qui est atteint.

SSRF vers des services non-HTTP

Via des protocoles alternatifs :

• Redis non authentifié : envoi de commandes via gopher://, potentiellement RCE.
• Memcached, Elasticsearch non sécurisés.
• Bases de données internes.
• Services SMTP internes (envoi de mails usurpés).

SSRF multi-tours

L'attaquant enchaîne plusieurs requêtes : pivot de serveur en serveur, escalade progressive dans le réseau interne.

Out-of-band exfiltration

Exfiltration de données via des canaux inhabituels : DNS queries avec données encodées en sous-domaines (limité à 63 caractères mais chaînable), headers HTTP vers un serveur contrôlé.

04 — CloudLe cas Capital One et les métadonnées

Les endpoints de métadonnées cloud

Chaque cloud provider expose un endpoint HTTP accessible uniquement depuis les instances qu'il héberge, contenant les métadonnées de l'instance et, surtout, les credentials IAM temporaires.

• AWS : http://169.254.169.254/ (IMDS).
• GCP : http://metadata.google.internal/ ou http://169.254.169.254/.
• Azure : http://169.254.169.254/metadata/instance?api-version=2021-02-01 (requiert header spécifique).
• Alibaba Cloud : http://100.100.100.200/.
• DigitalOcean, Oracle, IBM : chacun ses endpoints.

AWS IMDS — le cas emblématique

L'Instance Metadata Service (IMDS) d'AWS à l'adresse 169.254.169.254 retourne par défaut des informations sensibles :

• /latest/meta-data/ : infos sur l'instance (type, région, etc.).
• /latest/meta-data/iam/security-credentials/ROLE_NAME : credentials IAM temporaires (AccessKeyId, SecretAccessKey, Token).
• /latest/user-data/ : user-data de l'instance (scripts de démarrage qui contiennent parfois des secrets).

Un attaquant qui obtient ces credentials peut : lister les buckets S3, accéder aux bases RDS, démarrer ou terminer des instances EC2, exfiltrer des données. L'ampleur dépend des permissions IAM de l'instance — d'où l'importance du principe du moindre privilège.

Capital One — juillet 2019

Incident de référence pour la SSRF cloud.

• Attaquant : Paige Thompson, ancienne employée d'AWS.
• Cible : application web Capital One hébergée sur AWS.
• Vulnérabilité : SSRF dans l'application + firewall applicatif (WAF) mal configuré permettant l'accès au metadata endpoint.
• Chaîne d'attaque : SSRF → récupération des credentials IAM de l'instance EC2 → utilisation des credentials pour accéder à un bucket S3 → exfiltration de 106 millions de dossiers clients (USA + Canada).
• Données compromises : noms, adresses, scores de crédit, dates de naissance, numéros de sécurité sociale (140 000), numéros de comptes bancaires canadiens (80 000).
• Conséquences : 80 millions USD d'amende du régulateur bancaire US (OCC), class action réglée à 190 millions USD, démission de la responsable sécurité, poursuite criminelle de Thompson (condamnée en 2022).
• Impact structurel : accélération du développement d'IMDSv2 par AWS.

IMDSv2 — la réponse d'AWS

AWS a introduit IMDSv2 en 2019 pour contrer les SSRF :

• Accès en 2 étapes : obtenir un token (PUT request avec TTL), puis utiliser le token dans les requêtes suivantes.
• Requêtes SSRF simples ne peuvent pas faire de PUT — elles génèrent des GET, donc elles échouent à obtenir le token.
• Depuis 2022 : IMDSv2 requis par défaut sur les nouvelles instances EC2.
• Migration progressive des instances existantes — encore beaucoup de workloads en IMDSv1 dans le parc actuel.

Protections équivalentes

• GCP : requiert le header Metadata-Flavor: Google. Bloqué si SSRF ne peut pas forger ce header.
• Azure : requiert le header Metadata: true.
• Ces protections rendent l'exploitation SSRF plus difficile mais pas impossible si le client HTTP permet de contrôler les headers.

05 — IncidentsAutres cas célèbres

MinIO CVE-2023-28432 (mars 2023)

MinIO, stockage S3-compatible open source largement utilisé, avait une SSRF dans ses endpoints cluster. Permettait la récupération de secrets de configuration. Patch rapide, mais beaucoup d'installations sont restées vulnérables faute de mise à jour.

Bug bounty Shopify (2018)

Chercheur bug bounty découvre une chaîne SSRF → AWS metadata → credentials IAM Shopify. Bounty de 25 000 USD payé. Correction rapide. Démonstration publique précoce de la criticité SSRF cloud.

Microsoft Exchange ProxyShell (août 2021)

Parmi les vulnérabilités exploitées dans la chaîne ProxyShell (CVE-2021-34473, CVE-2021-34523, CVE-2021-31207), certains aspects relevaient de la SSRF pour pivoter dans l'infrastructure Exchange. Exploitation massive : des dizaines de milliers de serveurs Exchange compromis.

GitLab SSRF via URL preview

GitLab a eu plusieurs CVE de SSRF au fil des années, souvent liées aux fonctions de prévisualisation d'URLs ou de webhooks. Chacune corrigée rapidement mais illustre la difficulté de sécuriser complètement ces fonctionnalités.

Facebook bug bounties

Plusieurs SSRF rapportées et récompensées par Facebook au fil des années, souvent dans les fonctions de crawling, de prévisualisation de liens, d'imports. Bounties typiques de 5 000 à 40 000 USD selon impact.

Ten Eleven Ventures / Exabeam

SSRF dans le produit Exabeam (SIEM) découverte en 2023, permettant à un attaquant authentifié d'atteindre des ressources internes. Patch par l'éditeur.

Statistiques bug bounty

D'après les plateformes HackerOne et Bugcrowd, la SSRF reste parmi les top 10 vulnérabilités les plus rémunérées en 2025-2026 :

• SSRF simple : 1 000 - 5 000 USD typique.
• SSRF menant aux metadata cloud : 10 000 - 50 000 USD.
• SSRF avec escalade vers RCE : jusqu'à 100 000+ USD.

06 — ProtectionDéfense en profondeur

07 — FAQQuestions fréquentes

Quelle différence entre SSRF et CSRF ?

Deux attaques très différentes malgré les noms voisins. CSRF (Cross-Site Request Forgery, côté client) : forcer le navigateur d'une victime à envoyer une requête authentifiée vers un site sur lequel elle est connectée. SSRF (Server-Side, côté serveur) : forcer le serveur à envoyer une requête vers une ressource interne. CSRF exploite la session de l'utilisateur, SSRF exploite la position réseau du serveur. Les deux sont des attaques par « forgery » (falsification) mais dans des contextes opposés — l'une vise le navigateur, l'autre le serveur.

Un WAF protège-t-il contre les SSRF ?

Partiellement. Les WAF modernes (CloudFlare, AWS WAF, Akamai, ModSecurity) ont des règles dédiées détectant : les accès à 169.254.169.254, 127.0.0.1, IPs privées. Les protocoles alternatifs (file://, gopher://). Les patterns suspects. Mais les WAF sont contournables : DNS rebinding, représentations alternatives d'IP, encodages exotiques, chaînes de redirections. Ne jamais compter uniquement sur un WAF : c'est une couche défensive utile mais pas suffisante. La correction doit être applicative (validation stricte, allowlist, séparation réseau).

Pourquoi la SSRF est-elle arrivée si tard dans l'OWASP Top 10 ?

La SSRF est connue depuis les années 2000 comme classe de vulnérabilité, mais elle n'a été formellement intégrée à l'OWASP Top 10 qu'en 2021 (catégorie A10). Raisons de cette entrée tardive : la SSRF était historiquement considérée comme moins critique (accès à des ressources internes sans forcément privilèges élevés). L'avènement du cloud avec les endpoints de métadonnées a transformé l'impact — une SSRF devient l'équivalent d'une RCE quand elle permet de voler les credentials IAM. Capital One 2019 et les incidents similaires ont rendu évidente la criticité. L'OWASP Top 10 se met à jour tous ~4 ans, suivant les données de vulnérabilités et incidents réels.

SSRF peut-elle mener à une RCE ?

Oui, dans plusieurs scénarios. Via services internes non protégés : Redis sans authentification exposé en interne, accessible via gopher:// en SSRF, permet d'envoyer des commandes Redis qui peuvent écrire un fichier avec contenu arbitraire puis déclencher une RCE. Via credentials cloud : SSRF → AWS metadata → credentials IAM avec permissions → création d'une nouvelle instance ou exécution de code via Systems Manager / Lambda. Via services vulnérables internes : un Jenkins interne non patché, une console de management exposée, un endpoint admin legacy peuvent avoir leurs propres RCE atteignables via la SSRF. Via protocoles dangereux : file:// pour lire des clés SSH privées, puis usage externe. L'escalade SSRF → RCE est la chaîne la plus valorisée en bug bounty (impact maximal).

Les frameworks modernes protègent-ils nativement ?

Partiellement. Certains frameworks et bibliothèques incluent des protections par défaut. Node.js fetch (Node 18+) : suit les redirections par défaut. Python requests : ne suit les redirections que si allow_redirects=True. Go net/http : contrôle fin des redirections via CheckRedirect. Java URLConnection : pas de protection native. Mais aucun framework ne valide les IPs internes par défaut — c'est à l'application de l'implémenter. Bibliothèques dédiées : safe-fetch, ssrf-req-filter en Node, safeurl-python, requests-safe en Python. À utiliser systématiquement pour les fonctions exposées à input utilisateur.

Un serverless/Lambda peut-il être vulnérable à la SSRF ?

Oui, pleinement. Les fonctions serverless ont aussi leurs métadonnées cloud et peuvent être vulnérables : AWS Lambda : les credentials du rôle d'exécution sont disponibles via variables d'environnement et via SDK, pas via 169.254 metadata (modèle différent d'EC2). Mais d'autres endpoints internes cloud peuvent être atteints. Google Cloud Functions : similaire. Azure Functions : Managed Identity accessible via endpoint local. Les fonctions serverless réduisent la surface d'attaque (pas de VM complète) mais introduisent leurs propres enjeux SSRF. Les protections classiques s'appliquent : allowlist, validation d'URL, moindre privilège.