SSRF (Server-Side Request Forgery, ou falsificação de requisição no lado do servidor) é uma das vulnerabilidades mais perigosas da era da nuvem: em vez de atacar o navegador do usuário, o adversário engana a própria aplicação para que ela faça requisições de rede em nome dele. Como o servidor costuma estar dentro da rede confiável, o atacante ganha um pé de apoio para alcançar serviços internos, painéis administrativos e, sobretudo, os endpoints de metadados da nuvem que guardam credenciais. Reconhecida como categoria própria no OWASP Top 10 de 2021, sob o código A10:2021, a SSRF deixou de ser um caso de nicho para se tornar preocupação central de qualquer arquitetura moderna.
O que é SSRF (A10:2021)
Uma aplicação vulnerável a SSRF aceita, direta ou indiretamente, uma URL ou endereço de destino fornecido pelo usuário e realiza uma requisição de rede para esse destino sem validá-lo adequadamente. O nome descreve com precisão o mecanismo: assim como no CSRF o atacante falsifica requisições vindas do navegador da vítima, no SSRF ele falsifica requisições vindas do servidor. A diferença é decisiva, porque o servidor normalmente opera em uma posição de rede muito mais privilegiada do que qualquer cliente externo.
O OWASP incluiu a SSRF como categoria autônoma no Top 10 de 2021 justamente porque a sua incidência cresceu com a adoção de microsserviços, APIs que consomem outras APIs, integrações com webhooks e funções que buscam recursos remotos. Formalmente, a fraqueza é catalogada como CWE-918: Server-Side Request Forgery (SSRF). Ela raramente aparece sozinha: quase sempre é combinada com configuração de nuvem permissiva e ausência de segmentação de rede, o que amplifica o impacto de forma dramática.
Como funciona na prática
Considere um recurso comum: uma funcionalidade que gera a miniatura de uma imagem a partir de uma URL informada pelo usuário. O front-end envia algo como POST /thumbnail { "url": "https://exemplo.com/foto.png" } e o back-end baixa a imagem para processá-la. Se o servidor buscar qualquer URL sem restrição, o atacante substitui o valor por um destino interno:
POST /thumbnail HTTP/1.1
Content-Type: application/json
{ "url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/" }Do ponto de vista do servidor, é apenas mais uma requisição de saída. Mas o destino 169.254.169.254 é o endereço de metadados da instância na nuvem, e a resposta pode conter credenciais temporárias. Padrões que abrem a porta para SSRF incluem: importação de dados por URL, geração de PDF a partir de HTML remoto, verificação de webhooks, proxies de imagem, integrações de pagamento que chamam endpoints de callback e qualquer parser que resolva referências externas (XML com entidades, por exemplo).
Vale notar que a exploração nem sempre usa o esquema http. Dependendo da biblioteca cliente, o atacante pode abusar de file:// para ler arquivos locais, gopher:// para forjar tráfego a serviços que falam protocolos de texto (como Redis ou SMTP) e dict:// para sondar portas. Redirecionamentos HTTP também são um vetor: a URL inicial parece inofensiva, mas devolve um 302 apontando para o endereço interno.
Os atacantes também exploram a forma como cada linguagem interpreta URLs para burlar filtros ingênuos. Endereços podem ser escritos em notação decimal ou hexadecimal (http://2852039166/ equivale a http://169.254.169.254/), com codificação de caracteres, com credenciais embutidas no formato usuario@host ou explorando divergências entre o parser que valida e o parser que efetivamente conecta. Essas técnicas de contorno explicam por que abordagens baseadas em expressões regulares e listas de bloqueio quase sempre falham diante de um adversário determinado — e por que a validação robusta precisa operar sobre o IP já resolvido, não sobre o texto da URL.
Alvos preferenciais do atacante
Metadados da nuvem e roubo de credenciais IAM
O alvo número um é o serviço de metadados da instância (IMDS). Em todas as grandes nuvens ele responde no endereço link-local 169.254.169.254. Na AWS, o caminho /latest/meta-data/iam/security-credentials/<role> devolve chaves de acesso temporárias associadas ao perfil IAM da instância. No GCP, o mesmo endereço serve tokens OAuth via /computeMetadata/v1/ (protegido por um cabeçalho Metadata-Flavor: Google). No Azure, o endpoint /metadata/identity/oauth2/token entrega tokens da identidade gerenciada. Uma vez de posse dessas credenciais, o atacante deixa de estar limitado à aplicação: ele assume a identidade da carga de trabalho na nuvem e passa a agir com os privilégios daquele perfil. É por isso que a SSRF anda de mãos dadas com o princípio do menor privilégio, detalhado em IAM em cloud.
Serviços internos e movimentação lateral
Além dos metadados, o atacante usa o servidor como trampolim para alcançar recursos que não deveriam ser acessíveis de fora: bancos de dados, caches como Redis e Memcached, filas de mensagens, consoles administrativos de orquestradores (Kubernetes, Docker), painéis de CI/CD e APIs internas sem autenticação porque presumiam estar em rede fechada. Muitos desses serviços confiam implicitamente em qualquer conexão que venha de dentro da rede.
Varredura de portas e mapeamento
Mesmo sem obter dados diretamente, a SSRF permite varredura de portas: variando o host e a porta na URL e observando o tempo de resposta ou a mensagem de erro, o atacante mapeia quais serviços internos existem e onde. É reconhecimento de infraestrutura executado pela própria aplicação da vítima. A partir desse mapa, o adversário prioriza os alvos mais valiosos e encadeia a SSRF com outras falhas — uma API interna sem autenticação, um cache exposto ou um console administrativo — transformando um ponto de entrada aparentemente inofensivo em comprometimento profundo do ambiente.
SSRF cego
Nem sempre a resposta da requisição interna volta para o atacante. No SSRF cego, a aplicação faz a requisição mas não devolve o corpo da resposta ao cliente. Isso reduz, mas não elimina, o risco. O atacante recorre a canais laterais: mede diferenças de tempo de resposta para inferir se uma porta está aberta, provoca erros distintos para diferentes destinos, ou usa um servidor de coleta externo (técnica out-of-band) para confirmar que a requisição chegou — por exemplo, apontando a URL para um domínio sob seu controle e observando o log de DNS ou HTTP. Mesmo cego, o SSRF é suficiente para varrer a rede interna e, em alguns casos, para executar ações com efeito colateral (disparar um endpoint que reinicia um serviço, por exemplo).
Impacto: o caso Capital One
O exemplo mais citado de SSRF é a violação da Capital One, em 2019. Um firewall de aplicação web mal configurado permitiu que uma atacante induzisse o servidor a consultar o endpoint de metadados da AWS (169.254.169.254) e obtivesse as credenciais temporárias do perfil IAM associado à instância. Com essas credenciais, foi possível listar e ler buckets S3, resultando na exposição de dados de aproximadamente 100 milhões de clientes nos Estados Unidos e cerca de 6 milhões no Canadá. O episódio ilustra a cadeia de ampliação típica: uma SSRF isolada, somada a um perfil IAM excessivamente permissivo e à versão antiga do serviço de metadados, converteu-se em um dos maiores vazamentos do setor financeiro. A lição não é apenas corrigir a SSRF, mas quebrar cada elo da cadeia.
Defesas em profundidade
Nenhuma medida isolada resolve SSRF; a proteção eficaz combina controles na aplicação, na nuvem e na rede. A tabela abaixo relaciona o vetor ou alvo à mitigação recomendada.
| Vetor / Alvo | Mitigação recomendada |
|---|---|
| URL arbitrária fornecida pelo usuário | Allowlist estrita de domínios e esquemas permitidos; rejeitar tudo o que não estiver na lista |
| Acesso a IPs internos e link-local (169.254.0.0/16, 127.0.0.0/8, 10/8, 172.16/12, 192.168/16, ::1) | Bloquear faixas privadas, loopback e link-local após resolver o DNS, antes de conectar |
| Metadados da nuvem na AWS | Forçar IMDSv2 (token obrigatório via PUT) e reduzir o hop limit; considerar desativar o IMDS onde não for usado |
| DNS rebinding (TOCTOU entre validação e conexão) | Resolver o hostname uma única vez, validar o IP resolvido e conectar exatamente a esse IP |
| Esquemas perigosos (file, gopher, dict, ftp) | Permitir apenas http/https; desabilitar esquemas e protocolos não essenciais na biblioteca cliente |
| Redirecionamentos para destinos internos | Desabilitar o follow automático de redirects ou revalidar cada salto contra a allowlist |
| Serviços internos que confiam na origem de rede | Segmentação de rede e microssegmentação; exigir autenticação mesmo em tráfego leste-oeste |
| SSRF cego e exfiltração out-of-band | Egress firewall restringindo destinos de saída; monitorar e alertar tráfego para 169.254.169.254 |
Validação na aplicação
A defesa primária é uma allowlist de destinos: em vez de tentar enumerar tudo o que é perigoso (abordagem de denylist, frágil por natureza), permita apenas os poucos domínios e esquemas legítimos que a funcionalidade realmente precisa. Sempre que a lógica de negócio permitir, prefira substituir a URL livre por um identificador que o back-end mapeia internamente para o destino real. Ao validar uma URL, resolva o hostname e verifique se o IP resultante não pertence a faixas privadas, de loopback ou link-local; e conecte-se ao IP já validado, não ao hostname, para fechar a janela de DNS rebinding (em que o mesmo nome resolve para um IP público na validação e para um IP interno na conexão).
Endurecimento da nuvem
Na AWS, migre para o IMDSv2, que exige um token obtido por requisição PUT antes de qualquer leitura de metadados — o que quebra a maioria das SSRF baseadas em simples GET. Reduza o hop limit da resposta para dificultar o acesso a partir de contêineres, e desative o IMDS por completo onde a carga de trabalho não precisar dele. Combine isso com perfis IAM de menor privilégio: se a role da instância só puder ler um bucket específico, o roubo de credenciais rende muito menos. No GCP e no Azure, aplique o equivalente restringindo escopos e permissões das identidades gerenciadas.
Rede e monitoramento
A segmentação de rede limita até onde uma requisição forjada consegue chegar. Um egress firewall que restringe explicitamente os destinos de saída da aplicação é um dos controles mais eficazes contra SSRF cego e exfiltração out-of-band. Um WAF ajuda a barrar padrões conhecidos de exploração, mas deve ser tratado como camada complementar — jamais como única linha de defesa, precisamente porque um WAF mal configurado esteve na origem do caso Capital One. Por fim, monitore e alerte qualquer tentativa de tráfego para 169.254.169.254: em produção legítima, esse acesso partindo da aplicação é quase sempre um sinal de comprometimento.
Referências
- OWASP — Server-Side Request Forgery Prevention Cheat Sheet
- OWASP Top 10 — A10:2021 Server-Side Request Forgery (SSRF)
- MITRE — CWE-918: Server-Side Request Forgery (SSRF)
- Análise pública da violação da Capital One (2019) e o papel do IMDS/IMDSv2
Conclusão
Para empresas que operam na nuvem — de uma startup com um punhado de colaboradores a uma organização com mais de 100 mil — a SSRF é um risco que atravessa desenvolvimento, arquitetura e operação. Não basta corrigir um endpoint: é preciso combinar validação rigorosa de entrada, endurecimento do serviço de metadados, IAM de menor privilégio e segmentação de rede para que uma falha isolada não vire um vazamento de milhões de registros. A Decripte ajuda o seu time a mapear onde a SSRF pode existir na sua stack e a implementar essas camadas de defesa de forma prática. Comece grátis pelo nosso Intelligence Center ou conheça os nossos planos para levar a maturidade de segurança da sua empresa ao próximo nível.