flawopen.com/SSRF/SSRF no fetch() do Node.js

O fetch() do Node.js impede SSRF?

Causa raiz: o servidor confia no destino escolhido pelo chamador

O fetch() do Node.js é um cliente HTTP geral, não um mecanismo de política contra SSRF. Ele não decide a quais redes sua aplicação pode se conectar; proteções CORS de navegador não criam essa fronteira no servidor. Analisar a URL também não basta: um host permitido pode resolver para um endereço proibido, e uma resposta pode redirecionar para outro host. Recursos que buscam avatar, webhook, documento ou prévia fornecidos pelo usuário podem criar essa exposição.

Como a requisição cruza a fronteira de confiança

Padrões Node.js vulnerável e mais seguro

// Não busque uma URL arbitrária fornecida pelo chamador.
const response = await fetch(userProvidedUrl);

// O chamador escolhe uma chave, nunca um destino de rede.
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");

Quando usuários precisam enviar URLs

Prefira aceitar um identificador de provedor e montar a requisição a partir de um mapa fixo de destinos. Se URLs públicas arbitrárias forem essenciais, permita apenas esquemas e portas necessários; rejeite user-info, loopback, IPs privados, link-local e outros destinos IPv4/IPv6 proibidos; valide todos os endereços resolvidos e garanta que a conexão use um endereço validado sem nova resolução não verificada. Desative redirects automáticos ou valide cada salto. Aplique regras independentes de saída de rede, incluindo bloqueios a endpoints de metadados como 169.254.169.254 e o endpoint IPv6 habilitado. Limite tempo de conexão, tamanho da resposta e concorrência; não encaminhe credenciais internas ao host buscado.

Checklist de prevenção de SSRF

• ✓Sempre que possível, substitua URLs arbitrárias por um mapa fixo entre uma chave de provedor validada e um destino controlado pela aplicação.
• ✓Exija https: e portas esperadas; rejeite credenciais na URL, hosts inesperados, IPs literais e faixas proibidas.
• ✓Desative redirects com redirect: "error"; se forem necessários, valide cada destino antes de conectar.
• ✓Evite DNS rebinding validando todas as respostas A/AAAA e vinculando a conexão a um endereço validado, sem perder a verificação do nome. Aplique também a retries e proxies.
• ✓Aplique firewall ou proxy de saída para bloquear loopback, redes privadas, link-local e metadados, inclusive IPv6. Não dependa só da validação na aplicação.
• ✓Defina limites de tempo, bytes de resposta e concorrência; não encaminhe cookies, cabeçalhos de autorização nem credenciais de nuvem ao destino.
• ✓Na AWS, exija IMDSv2 e restrinja o acesso aos metadados como defesa em profundidade; isso não substitui validação de URL nem controles de saída.

Perguntas frequentes

Fontes primárias

• OWASP — prevenção de SSRF
• Node.js — API global fetch
• Padrão WHATWG Fetch — modo de redirect
• AWS — opções do serviço de metadados EC2
• CWE-918 — Server-Side Request Forgery