O que é SSRF
SSRF é a sigla de Server-Side Request Forgery. Em português: uma falha onde o próprio servidor da aplicação é enganado pra fazer uma requisição HTTP pra um endereço que o atacante escolhe, em vez de um endereço que o sistema esperava.
Isso normalmente aparece em funcionalidades bem comuns e aparentemente inofensivas: importar uma imagem a partir de uma URL, gerar um PDF a partir de um link, validar um webhook, buscar metadado de um link compartilhado. Qualquer lugar onde o sistema recebe uma URL do usuário e faz uma requisição a partir dela é candidato a SSRF.
Por que isso é ainda mais grave na nuvem
Toda infraestrutura de nuvem moderna (AWS, GCP, Azure) expõe um endereço interno de metadado, algo como 169.254.169.254, acessível só de dentro da própria rede da máquina. Esse endereço entrega informação sobre a instância, incluindo, em configurações mal feitas, credenciais temporárias de acesso à conta de nuvem.
Se o servidor da aplicação aceita fazer requisição pra qualquer URL que o usuário mandar, e não bloqueia esse endereço interno, um atacante pode pedir pro próprio servidor perguntar por essa credencial, e usar a resposta pra ganhar acesso a recursos da nuvem que vão muito além da aplicação em si.
O caso
Numa plataforma enterprise, num programa público de bug bounty, uma funcionalidade que aceitava URL fornecida pelo usuário (parte de um recurso de importação de conteúdo externo) não validava se essa URL apontava pra um endereço interno da rede da nuvem. Isso permitiu o acesso ao serviço de metadados da instância, expondo informação interna que nunca deveria estar acessível a partir de uma funcionalidade voltada pro usuário final.
A falha foi reportada, corrigida, e classificada como crítica: não pelo dano direto na hora do teste, mas pelo potencial de escalar pra acesso mais amplo dentro do ambiente de nuvem da empresa.
Como isso se previne
- Nunca confiar diretamente numa URL fornecida pelo usuário para fazer requisição no lado do servidor sem validação.
- Bloquear por padrão qualquer requisição de saída pra faixas de IP interno e endereço de metadado de nuvem.
- Usar lista de permissão (allowlist) de domínios esperados em vez de tentar bloquear cada domínio perigoso individualmente.
- Restringir a permissão da própria instância na nuvem ao mínimo necessário, pra que, mesmo se o metadado vazar, o dano fique limitado.
Esse é exatamente o tipo de falha que scanner automatizado costuma deixar passar, porque a funcionalidade em si parece normal. Foi achada testando manualmente, com a mesma metodologia de quem caça vulnerabilidade em programa de bug bounty.
Sua aplicação tem alguma funcionalidade que aceita URL do usuário?
Solicitar Pentest em Aplicações Web