SSRF : définition, risques et prévention
La SSRF (Server-Side Request Forgery) est une vulnérabilité où un attaquant force le serveur à effectuer des requêtes HTTP vers des ressources internes ou externes non prévues. Entrée au Top 10 OWASP en 2021, elle est particulièrement dangereuse en environnement cloud (AWS, GCP, Azure) où elle peut exposer des métadonnées d’instance et des identifiants.
Pentest web & API, audit IA, Toulouse, méthodologie OWASP/PTES
Comment fonctionne une SSRF ?
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.
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 (100M clients) = SSRF + IMDSv1 mal configuré, 80M$ 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.
Besoin d'un pentest ?
Chez Laucked, nous testons vos applications web, API et intégrations sensibles avec une méthodologie OWASP/PTES. Diagnostic de surface gratuit, rapport sous 48-72h.
Demander un diagnostic gratuit