Dans une faille SSRF, l’attaquant ne vise pas directement la machine qui l’intéresse : il se sert du site comme intermédiaire. Le serveur web se trouve souvent dans un réseau où il peut joindre des services que personne ne devrait atteindre depuis Internet. Si une fonction du site télécharge une adresse fournie par l’utilisateur sans vérifier la destination, l’attaquant peut lui faire interroger ces services à sa place. L’OWASP a fait de la SSRF une catégorie à part de son Top 10 2021 (A10), et le MITRE la référence sous CWE-918.
Comment fonctionne une attaque SSRF
Les fonctions concernées sont celles qui vont chercher une URL : importer une image depuis une adresse, générer un aperçu de lien, appeler un webhook, vérifier un flux. L’attaquant y glisse une adresse interne au lieu d’une adresse publique :
- l’adresse de métadonnées du cloud
169.254.169.254, utilisée par AWS, Azure et Google Cloud, qui peut révéler des identifiants et des jetons d’accès ; - le serveur lui-même (
localhost,127.0.0.1), par exemple un panneau d’administration ou une base de données qui n’écoute qu’en local ; - le réseau privé (
10.0.0.0/8,192.168.0.0/16…), pour cartographier les machines et les ports ouverts ; - d’autres protocoles que HTTP, comme
file://ougopher://, quand la bibliothèque utilisée les accepte.
La réponse ne revient pas toujours en clair : on parle de SSRF « aveugle » quand l’attaquant ne voit qu’un message d’erreur ou un temps de réponse, ce qui suffit pourtant à savoir si un port est ouvert.
Comment s’en protéger
- Liste d’autorisation : quand les destinations sont connues (une API précise), n’acceptez qu’elles.
- http et https seulement, sur des ports standards.
- Refuser les adresses internes après résolution DNS, et vérifier aussi chaque redirection : un nom de domaine public peut pointer vers une adresse privée.
- Côté hébergement : segmentation réseau et, sur AWS, passage à IMDSv2, que l’OWASP recommande pour limiter le vol de métadonnées.
Pour WordPress : wp_safe_remote_get et les pingbacks
WordPress fournit les bons outils, à condition de les utiliser. wp_safe_remote_get() et ses variantes valident l’URL et chaque URL de redirection avec wp_http_validate_url() : seuls http et https passent, les identifiants dans l’URL sont refusés, les adresses de bouclage et privées sont rejetées, et un port explicite doit être 80, 443 ou 8080. À l’inverse, wp_remote_get() ne fait pas cette validation par défaut : une extension qui l’utilise avec une adresse fournie par un visiteur s’expose. Le filtre http_request_host_is_external permet d’autoriser un hôte interne précis ; l’ouvrir à tout annule la protection.
$reponse = wp_safe_remote_get( esc_url_raw( $url_fournie ), array( 'timeout' => 5 ) );
if ( is_wp_error( $reponse ) ) {
return; // URL refusée ou injoignable
}Le cœur lui-même a connu ce problème : avant WordPress 3.5.1, le pingback de XML-RPC permettait d’envoyer des requêtes vers des serveurs internes et de scanner des ports (CVE-2013-0235). Le pingback utilise désormais wp_safe_remote_get(), mais il reste une fonction qui fait émettre des requêtes par votre serveur à la demande d’un tiers. Si vous ne vous en servez pas, le module Durcissement de WP Masquerade bloque gratuitement les pingbacks et XML-RPC ; notre article sur XML-RPC aide à vérifier qu’aucun service n’en dépend. Pour le reste, la SSRF se corrige dans le code de l’extension concernée, et un pare-feu applicatif peut filtrer les adresses internes les plus évidentes en attendant.