Pular para o conteúdo
>_ITDITDPlataforma de Segurança Web

Glossário

O que é SSRF (Server-Side Request Forgery)

SSRF faz um servidor enviar requisições para destinos internos que ele não deveria alcançar (IPs internos, metadados de nuvem) — o ponto de entrada do vazamento da Capital One. Como funciona, onde se esconde, as armadilhas de validação que as pessoas ignoram e como se defender.

Publicado 2026-06-07 Atualizado 2026-06-07 4 min de leitura

"Cole uma URL e nós buscaremos o conteúdo dela" — uma conveniência do dia a dia que, no pior caso, vira a porta para as credenciais da sua nuvem. Isso é SSRF. Veja como funciona e como se defender, do zero.

O que realmente está acontecendo

O acesso normal é "usuário → site externo". O SSRF transforma o servidor em um proxy que atinge o interior. Servidores conseguem alcançar redes internas e endpoints de credenciais de nuvem que são invisíveis de fora — então um invasor os espia indiretamente.

invasor
──"busque esta URL interna"──▶
seu servidor (recurso de busca de URL)
└─ requisição feita por proxy ─▶
rede interna / painéis de admin
169.254.169.254 (credenciais de nuvem)
O invasor usa seu servidor como 'trampolim' para alcançar o interior que normalmente está fora de alcance.

Na nuvem, esse endpoint interno (o serviço de metadados) pode entregar credenciais temporárias. Se o SSRF o alcança, as chaves são roubadas e o ataque encadeia para a exfiltração massiva de armazenamento — que é exatamente o que aconteceu no vazamento da Capital One (2019): SSRF → metadados → credenciais IAM → S3.

Onde se esconde

Qualquer recurso em que "um servidor busca uma URL fornecida pelo usuário" é um candidato.

RecursoImplementação típica
Pré-visualização de OG / linko servidor busca uma URL colada para montar uma miniatura
Entrega de webhooko servidor faz POST para um destino especificado pelo usuário
Importação de imagem / arquivo"buscar uma imagem de uma URL"
Diagnóstico de siteo servidor acessa o site informado para inspecioná-lo

Armadilhas de validação que as pessoas ignoram

"Bloquear IPs internos" não é suficiente. Você precisa fechar também estas brechas.

O bloqueio ingênuo vaza

  • Seguir redirecionamentos: um domínio permitido faz 302 para um endereço interno.
  • DNS rebinding: IP externo no momento da validação, IP interno no momento da busca.
  • Truques de codificação de IP: formas decimais/octais/curtas disfarçam um endereço interno.
  • Esquemas estranhos: file://, gopher:// e outros esquemas inesperados.

Como se defender se você construir o recurso

O SSRF é prevenido "no como você constrói o recurso". Estas são as regras que este site impõe aos seus próprios recursos de diagnóstico.

1

Use uma allowlist para destinos

Restrinja o esquema (http/https) e o host a um conjunto permitido apenas. "Permitir só estes" é mais robusto do que "bloquear os internos".

2

Bloqueie alvos internos

Negue a alcançabilidade a 127.0.0.1 / 10.x / 192.168.x / 169.254.169.254 (metadados).

3

Apenas domínios que o usuário possui (para diagnósticos)

Restrinja a domínios que o usuário provou possuir. Não deixe que ele mire em sites de terceiros.

4

Feche as brechas e proteja os metadados

Valide o destino final do redirecionamento, considere o DNS rebinding e exija metadados baseados em token (por exemplo, IMDSv2) na nuvem.

Este site se apoia em "não guardar segredos", "diagnosticar apenas o que tem posse comprovada" e "minimizar o raio de impacto" (→ Sobre este site).

Leia a seguir

FAQ

QQue tipo de recurso tende a ter SSRF?
A

Recursos em que 'um servidor busca uma URL fornecida pelo usuário': geração de pré-visualização de OG/link, entrega de webhook, importação de imagem, diagnóstico de site. Quanto mais conveniente o recurso, mais cuidado ele exige.

QPor que o SSRF é especialmente perigoso na nuvem?
A

VMs de nuvem têm um 'endpoint de metadados' acessível apenas internamente que pode entregar credenciais temporárias. Se o SSRF o alcança, essas chaves são roubadas e o ataque encadeia para a exfiltração massiva de armazenamento (o caminho do vazamento da Capital One).

QComo me defendo contra SSRF?
A

Valide os destinos estritamente com uma allowlist e bloqueie a alcançabilidade a IPs internos (127.0.0.1, 10.x, metadados em 169.254.169.254). Para diagnósticos, restrinja a domínios que o usuário provou possuir, e feche as brechas de seguir redirecionamentos e de DNS rebinding.