Un correctif SSRF sérieux a deux étages. L'application n'accepte que des destinations prévues. Le réseau empêche le serveur de joindre ce qu'il n'a pas à joindre, au cas où l'application se trompe.

Étage applicatif

Code complet pour Node 22, sans dépendance. net.BlockList fait partie de la bibliothèque standard et sait comparer une adresse IPv6 mappée aux règles IPv4.

const dns = require('node:dns/promises');
const net = require('node:net');

const AUTORISES = new Set(['images.famino.test', 'cdn.fournisseur.test']);

const internes = new net.BlockList();
internes.addSubnet('0.0.0.0', 8, 'ipv4');
internes.addSubnet('10.0.0.0', 8, 'ipv4');
internes.addSubnet('127.0.0.0', 8, 'ipv4');
internes.addSubnet('169.254.0.0', 16, 'ipv4');
internes.addSubnet('172.16.0.0', 12, 'ipv4');
internes.addSubnet('192.168.0.0', 16, 'ipv4');
internes.addAddress('::1', 'ipv6');
internes.addSubnet('fc00::', 7, 'ipv6');
internes.addSubnet('fe80::', 10, 'ipv6');

async function destinationSure(brut) {
  const u = new URL(brut);
  if (u.protocol !== 'https:') throw new Error('schema refuse');
  if (!AUTORISES.has(u.hostname)) throw new Error('hote refuse');
  const adresses = await dns.lookup(u.hostname, { all: true });
  for (const a of adresses) {
    if (internes.check(a.address, a.family === 6 ? 'ipv6' : 'ipv4')) {
      throw new Error('adresse interne');
    }
  }
  return u;
}

app.get('/bo/api/apercu', async (req, res) => {
  let u;
  try { u = await destinationSure(String(req.query.url || '')); }
  catch { return res.status(400).json({ erreur: 'URL non autorisee' }); }

  const reponse = await fetch(u, { redirect: 'error', signal: AbortSignal.timeout(3000) });
  const type = reponse.headers.get('content-type') || '';
  if (!/^image\/(png|jpeg|webp)$/.test(type)) return res.status(415).end();
  res.set('Content-Type', type).send(Buffer.from(await reponse.arrayBuffer()));
});

Ce que chaque ligne ferme : HTTPS seul écarte file:, gopher: et consorts ; la liste d'autorisation règle l'essentiel du problème à elle seule ; la vérification après résolution couvre le cas où un domaine autorisé serait détourné vers l'interne ; redirect: 'error' fait échouer la requête à la première redirection ; le contrôle du type de contenu évite de relayer autre chose qu'une image.

Reste un trou qu'il faut connaître : entre dns.lookup et fetch, le nom est résolu deux fois. Avec une liste d'autorisation stricte, l'attaquant ne contrôle pas le DNS des domaines permis, donc le risque est faible. Si le métier impose d'accepter n'importe quelle URL (aperçu de lien, webhook client), la vérification applicative ne suffit plus et il faut passer au second étage.

Étage réseau

Faire sortir ces requêtes par un proxy dédié qui refuse les destinations internes. Smokescreen, publié par Stripe, est conçu pour ça. À défaut, une règle de pare-feu sur le serveur qui interdit au compte du service web de joindre les métadonnées :

iptables -A OUTPUT -m owner --uid-owner www-data -d 169.254.169.254 -j REJECT

Comment la trouver (vérifier le correctif)

Un correctif non testé n'est pas un correctif. Sur l'environnement de recette, rejoue les cas de la tâche 4 et contrôle les codes de retour :

$ curl -s -o /dev/null -w "%{http_code}\n" "https://bo.famino.test/bo/api/apercu?url=http://127.0.0.1:8080/admin"
400
$ curl -s -o /dev/null -w "%{http_code}\n" "https://bo.famino.test/bo/api/apercu?url=https://images.famino.test/catalogue/12.png"
200

Tu dois observer 400 pour toute destination hors liste et 200 pour l'usage légitime. Vérifie aussi la règle réseau avec iptables -L OUTPUT -v -n : le compteur de paquets de la ligne REJECT doit augmenter quand tu testes depuis le compte www-data.