SSRF — Server-Side Request Forgery — transforma seu próprio servidor no proxy do atacante. Onde quer que sua app busque uma URL que outro fornece, um atacante pode apontá-la para dentro — a serviços que nunca deveriam ser alcançáveis de fora.

Como funciona

Sua app pega uma URL e a busca no lado do servidor — para um preview, importar dados, ou um webhook fornecido pelo usuário. Se você busca qualquer URL que recebe, o atacante fornece uma interna:

    POST /api/import  { "url": "http://169.254.169.254/latest/meta-data/..." }
# → seu servidor busca a metadata do cloud e pode vazar credenciais

Como a requisição sai de dentro da sua rede, os firewalls confiam. O SSRF pode alcançar painéis internos, bancos de dados e — o mais perigoso — o endpoint de metadata (169.254.169.254), que pode entregar credenciais IAM.

Como prevenir SSRF

  1. Allow-list de destinos. Só busque hosts que você permite explicitamente.
  2. Bloqueie IPs privadas e reservadas (127/8, 10/8, 172.16/12, 192.168/16, link-local e 169.254.169.254).
  3. Re-verifique o IP resolvido após resolver o hostname (contra DNS rebinding).
  4. Restrinja schemes (só https/http; bloqueie file://, gopher://).
  5. Não siga redirects não confiáveis e use IMDSv2 na AWS.

O SSRF se esconde em features de conveniência. O Nurbak escaneia sua app por endpoints propensos a SSRF e o resto do checklist de segurança de APIs.

Artigos relacionados