FlawOpen

flawopen.com/SSRF/Metadados de nuvem e SSRF

Como o SSRF pode alcançar metadados de nuvem e quando as credenciais ficam em risco?

Página de referência
Explicação simples

Imagine o serviço de metadados como um balcão interno trancado dentro de uma máquina na nuvem. O SSRF pode transformar sua aplicação em um mensageiro até esse balcão, mas o que ela consegue obter depende das regras de requisição do provedor, das configurações da instância e do caminho de rede da aplicação. Alcançar o endpoint não significa que credenciais foram expostas.

Por que o endpoint de metadados pode ser perigoso

AWS EC2, Azure e Google Compute Engine documentam serviços de metadados de instância acessíveis em ambientes de VM compatíveis. 169.254.169.254 é um endereço link-local comum, mas os formatos e controles variam. Os metadados podem incluir detalhes sensíveis; a AWS pode fornecer credenciais temporárias de função quando o perfil da instância e o caminho da requisição permitem. O risco de SSRF surge se alguém puder influenciar uma requisição do servidor que alcance esse serviço. Acesso ao endpoint, por si só, não prova que credenciais podem ser obtidas: cabeçalhos ou tokens obrigatórios, método HTTP, proxy, posição na rede e configuração da instância afetam o resultado.

Como a cadeia de impacto se forma

O impacto depende de uma cadeia de condições: uma entrada influencia uma requisição do servidor; ela alcança o serviço de metadados; o serviço aceita a requisição conforme os controles do provedor; e os dados retornados concedem acesso útil. O alcance final depende das permissões da identidade da carga de trabalho. Interrompa a cadeia com destinos fixos, controles rígidos de saída, proteções de metadados do provedor e identidades com permissões mínimas.

Perguntas frequentes

Todos os provedores de nuvem usam o mesmo endereço ou exigem o mesmo controle?

Não. Endereços, cabeçalhos, métodos, requisitos de token e dados disponíveis variam. A AWS IMDSv2 exige um token de sessão para obter metadados quando HttpTokens está definido como required; o Azure exige o cabeçalho Metadata: true; e o Google documenta o cabeçalho Metadata-Flavor: Google. Esses controles podem mitigar alguns caminhos de SSRF, mas não substituem a prevenção de destinos controlados pelo usuário nem o bloqueio de saída desnecessária. Confira a documentação do provedor para a configuração exata de VM e contêiner.

Fontes e análises relacionadas

Veja também Falsificação de requisição do lado do servidor (SSRF, CWE-918): como funciona e como evitar em todas as linguagens — flawopen.com Bots de PR com IA: prevenção de SSRF — flawopen.com SSRF no fetch() do Node.js: como buscar URLs com segurança