SSRF : falsification de requêtes côté serveur

La SSRF (Server-Side Request Forgery) se produit quand une application fait des requêtes HTTP vers une URL contrôlée par l'attaquant. Fonctionnalités concernées : prévisualisation d'URL, import de fichier distant, webhook, proxy, fetch d'image à partir d'une URL fournie par l'utilisateur. Le serveur devient un proxy : il émet des requêtes depuis son propre réseau, ce qui lui donne accès à des ressources inaccessibles depuis l'extérieur.

Impact en environnement cloud

L'impact le plus grave d'une SSRF en environnement cloud est l'accès au service de métadonnées de l'instance. AWS, GCP et Azure exposent un endpoint HTTP sur http://169.254.169.254/ (ou http://metadata.google.internal/) accessible uniquement depuis l'instance. Ce service fournit les credentials IAM temporaires de l'instance, qui donnent accès aux services cloud selon les permissions du rôle associé.

Exemple d'exploitation SSRF vers les métadonnées AWS

# L'attaquant soumet cette URL dans le champ "importer une image" :
http://169.254.169.254/latest/meta-data/iam/security-credentials/

# Le serveur effectue la requête et retourne les credentials IAM temporaires :
{
  "AccessKeyId": "ASIA...",
  "SecretAccessKey": "...",
  "Token": "...",
  "Expiration": "2026-07-09T14:00:00Z"
}

Accès aux services internes

Au-delà du service de métadonnées, une SSRF permet d'accéder à des services internes qui ne sont pas exposés sur internet. Exemples courants : interface d'administration Elasticsearch sur le port 9200, Redis sans authentification sur le port 6379, tableau de bord Kubernetes, interface de gestion du serveur web, services de déploiement interne. L'attaquant peut également scanner le réseau interne en testant différentes adresses IP et ports.

Prévention

La défense principale est la validation stricte des URLs avant d'émettre des requêtes. Approche recommandée : liste blanche des domaines autorisés (si les URLs cibles sont prévisibles), résolution DNS puis validation de l'IP résolue (refuser les plages RFC 1918 : 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, et les adresses link-local : 169.254.0.0/16), désactivation des redirections HTTP (un attaquant peut contourner la validation initiale avec une redirection vers une IP interne).

Validation d'URL avec blocage des IPs internes (Node.js)

const dns = require('dns').promises;
const ipaddr = require('ipaddr.js');

async function isSafeUrl(url) {
  const parsed = new URL(url);
  if (!['http:', 'https:'].includes(parsed.protocol)) return false;

  const { address } = await dns.lookup(parsed.hostname);
  const ip = ipaddr.parse(address);

  // Bloquer les plages privées, loopback et link-local
  const range = ip.range();
  return !['private', 'loopback', 'linkLocal', 'carrierGradeNat'].includes(range);
}

En environnement cloud, activer IMDSv2 (Instance Metadata Service v2) sur AWS : il exige un token de session obtenu via une requête PUT, ce qui empêche les attaques SSRF simples basées sur des requêtes GET.