Comment fonctionne une SSRF ?
L'attaquant fournit une URL contrôlée dans un paramètre traité par le serveur (import d'image, webhook, génération de PDF). Le serveur effectue la requête avec ses propres privilèges, accédant potentiellement à des services internes, des API privées ou des endpoints de métadonnées cloud.
Scénarios d'exploitation
- Lecture des métadonnées AWS (
169.254.169.254) pour voler des clés IAM. - Scan de ports et services sur le réseau interne.
- Accès à des bases de données ou API internes non exposées au web.
- Rebond vers d'autres vulnérabilités internes (RCE, SQLi).
Comment se protéger de la SSRF ?
- Maintenir une allowlist stricte des domaines/IP autorisés.
- Bloquer l'accès aux adresses privées (RFC 1918) et aux endpoints de métadonnées.
- Désactiver les redirections HTTP dans les requêtes sortantes.
- Utiliser IMDSv2 sur AWS pour protéger les métadonnées.
Exemple concret : vol de clés IAM via IMDSv1 (AWS)
Une PME SaaS héberge un service de génération de PDF sur une instance EC2. Le serveur accepte une URL utilisateur pour intégrer une image d'en-tête dans le PDF. L'attaquant fournit http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-role.
Si l'instance utilise IMDSv1 (accessible sans token), le serveur renvoie directement les clés AWS temporaires (AccessKeyId, SecretAccessKey, Token) du rôle IAM attaché. L'attaquant les utilise depuis sa machine pour lister S3, EC2, RDS et exfiltrer les données.
Score CVSS v3.1 : 9.9 (Critical) — vecteur AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. La correction : migrer en IMDSv2 (token obligatoire) et hop-limit à 1.
Recevoir la checklist OWASP Top 10 (PDF imprimable)
Les 10 risques 2021 traduits en contrôles de remédiation à cocher pour vos équipes dev et sécurité. Indiquez votre email professionnel pour y accéder immédiatement.
FAQ SSRF
Ma PME SaaS est sur AWS/GCP, suis-je concerné par la SSRF ?
Oui, fortement. Toute application qui effectue des requêtes HTTP sortantes à partir de données utilisateur (webhooks, import d'image, preview de lien, OAuth callback) est potentiellement vulnérable. Le risque est amplifié en cloud car l'endpoint de métadonnées expose des clés IAM exploitables immédiatement.
Une allowlist de domaines est-elle suffisante ?
Non, pas seule. Les attaquants utilisent le DNS rebinding : un domaine autorisé résout d'abord vers une IP publique légitime (passe l'allowlist), puis la deuxième résolution DNS pointe vers 169.254.169.254. Il faut aussi résoudre l'IP, bloquer RFC 1918 + 169.254.0.0/16, et interdire les redirections.
Pourquoi SSRF est-elle entrée dans l'OWASP Top 10 2021 (A10) ?
Parce que la migration vers le cloud a massifié la surface : chaque fonction serverless, chaque conteneur, chaque instance EC2 a son endpoint de métadonnées. Les Capital One Data Breach de 2019 (100 M clients) = SSRF + IMDSv1 mal configuré, 80 M$ d'amende CFPB.
Un scanner automatique détecte-t-il les SSRF ?
Partiellement. Les scanners détectent les SSRF évidentes (payload vers un serveur OAST type Burp Collaborator). Mais les SSRF aveugles, les chaînes d'exploitation (SSRF → RCE via Redis), et les contournements WAF nécessitent un pentest manuel. Voir pentest automatisé vs manuel.