Sécurité
SSRF : Server-Side Request Forgery. « Falsification de requête côté serveur », par analogie avec le coursier d'une entreprise qu'on persuade d'aller chercher un colis dans le coffre-fort de la maison.
Principe : Une application qui va chercher une ressource à partir d'une URL fournie par l'utilisateur peut être détournée vers des adresses internes. La requête part du serveur, avec sa position réseau et sa confiance, pas de celles de l'attaquant.
Cible favorite : Dans le nuage, le service de métadonnées d'instance (IMDS) répond sur une adresse locale et peut livrer des identifiants IAM temporaires. Un serveur qui accepte de lire n'importe quelle URL devient ainsi le plus serviable des complices.
Parades : IMDSv2 chez AWS impose un jeton obtenu par une requête PUT préalable, avec une portée réseau limitée, ce qui casse la plupart des chaînes d'exploitation. S'y ajoutent une liste d'autorisation de destinations, le refus des adresses privées après résolution DNS et un filtrage des flux sortants.
Ce qui arrive si on s'en passe
Sans protection contre ce type de détournement, toute fonction qui télécharge une ressource à partir d'une adresse fournie devient une porte vers le réseau interne. Un attaquant peut alors interroger des services d'administration jamais exposés à Internet, cartographier les machines voisines ou lire le service de métadonnées d'une instance en nuage. Ce dernier peut livrer des identifiants temporaires valides, utilisables ensuite depuis n'importe où tant qu'ils n'ont pas expiré. Les journaux montrent seulement le serveur légitime interrogeant ses propres ressources, ce qui retarde la détection.
Explication de la marmotte
Certains sites proposent d'aller chercher une image ou une page à partir d'une adresse qu'on leur donne. Un petit malin peut alors leur fournir l'adresse d'un endroit normalement fermé au public, à l'intérieur même de l'entreprise. Le site, docile, y va à sa place et rapporte ce qu'il trouve. C'est comme demander au facteur d'une banque de rapporter le contenu d'un tiroir du directeur : lui a le droit d'entrer, l'inconnu non. Pour éviter ça, on limite les endroits où le site accepte d'aller.
Où ce terme est utilisé
- SSRF vers IMDS et vol d’identifiants IAM (15 occurrences)
- Comment bloquer les requêtes côté serveur et la désérialisation (5 occurrences)
- Sécuriser les fonctions serverless FaaS (3 occurrences)
- Cloud IaaS, PaaS, SaaS et modèles de déploiement, qui sécurise quoi (2 occurrences)
- Comment lire un rapport OWASP Top 10 (2 occurrences)
- Comment revoir le code de sécurité au-delà du linter (2 occurrences)
- Comment valider le function calling d’un LLM (2 occurrences)
- IPv4, CIDR et plans d’adressage (2 occurrences)
- JWS : signer et sécuriser vos échanges JSON (2 occurrences)
- Monolithe ou microservices : choisir sans se mentir (2 occurrences)
