flawopen.com/SSRF/SSRF avec fetch() dans Node.js

fetch() de Node.js empêche-t-il les SSRF ?

Cause : le serveur fait confiance à la destination fournie

Le fetch() de Node.js est un client HTTP général, pas une politique anti-SSRF. Il ne choisit pas les réseaux accessibles ; CORS du navigateur n’établit pas de frontière côté serveur. Analyser l’URL ne suffit pas : un hôte autorisé peut résoudre vers une adresse interdite, et une réponse peut rediriger vers un autre hôte. Les fonctions qui récupèrent avatar, webhook, document ou aperçu fourni par l’utilisateur peuvent exposer le serveur.

Comment la requête franchit la frontière de confiance

Exemples Node.js vulnérable et plus sûr

// Ne récupérez pas une URL arbitraire fournie par l’appelant.
const response = await fetch(userProvidedUrl);

// L’appelant choisit une clé, jamais une destination réseau.
const destinations = new Map([
  ["status", new URL("https://status.example/")],
  ["docs", new URL("https://docs.example/")],
]);

const target = destinations.get(providerId);
if (!target) throw new Error("Unknown provider");

const response = await fetch(target, {
  redirect: "error",
  signal: AbortSignal.timeout(3000),
});
if (!response.ok) throw new Error("Upstream request failed");

Si l’utilisateur doit fournir une URL

Préférez un identifiant fournisseur associé à une destination fixe. Si des URL publiques arbitraires sont indispensables, n’autorisez que les schémas et ports requis ; rejetez user-info, loopback, adresses privées, link-local et autres destinations IPv4/IPv6 interdites ; validez toutes les adresses résolues et forcez la connexion à utiliser une adresse validée sans seconde résolution non contrôlée. Désactivez les redirections automatiques ou validez chaque étape. Appliquez des règles de sortie réseau indépendantes, y compris le blocage des métadonnées telles que 169.254.169.254 et l’adresse IPv6 activée. Limitez durée, taille de réponse et concurrence ; ne transmettez pas d’identifiants internes à la destination.

Liste de prévention SSRF

• ✓Remplacez si possible toute URL libre par une association fixe entre une clé fournisseur validée et une destination définie par l’application.
• ✓Imposez https: et les ports attendus ; rejetez identifiants d’URL, hôtes inattendus, IP littérales et plages interdites.
• ✓Désactivez les redirections avec redirect: "error" ; si elles sont nécessaires, validez chaque destination avant connexion.
• ✓Prévenez le DNS rebinding en validant toutes les réponses A/AAAA et en liant la connexion à une adresse validée tout en conservant la vérification du nom. Couvrez aussi reprises et proxies.
• ✓Utilisez un pare-feu ou proxy de sortie qui bloque loopback, réseaux privés, link-local et métadonnées, IPv6 compris. Les contrôles applicatifs seuls ne suffisent pas.
• ✓Fixez limites de durée, d’octets et de concurrence ; ne transmettez ni cookies, ni en-têtes d’autorisation, ni identifiants cloud.
• ✓Sur AWS, imposez IMDSv2 et restreignez l’accès aux métadonnées en défense supplémentaire ; cela ne remplace ni validation d’URL ni filtrage réseau.

Questions fréquentes

Sources primaires

• OWASP — prévention SSRF
• Node.js — API globale fetch
• Standard WHATWG Fetch — mode de redirection
• AWS — options du service de métadonnées EC2
• CWE-918 — Server-Side Request Forgery