Um ataque SSRF transforma um servidor no seu proxy. Você fornece uma URL à aplicação, a aplicação a busca por você, e de repente você alcança sistemas internos que o firewall foi construído para esconder. O Server-Side Request Forgery é um dos bugs web mais impactantes da era da nuvem, porque uma única funcionalidade vulnerável do tipo "busque esta URL" pode expor toda uma rede interna. A forma mais rápida de entender é quebrar um você mesmo, então abra o lab SSRF Validator da HackerDNA e acompanhe durante a leitura.
O SSRF é uma entrada de destaque no OWASP Top 10. Ele conquistou seu próprio lugar na lista de 2021 e, na revisão de 2025, foi incorporado ao Broken Access Control porque a causa raiz é a mesma: o servidor faz uma requisição que nunca deveria ter sido autorizado a fazer. Este guia cobre o que é o SSRF, como o ataque funciona passo a passo, os payloads que importam, e como neutralizá-lo no seu próprio código.
TL;DR: um ataque SSRF abusa de uma funcionalidade do lado do servidor que busca uma URL, enganando o servidor para requisitar um endereço escolhido pelo atacante. Aponte-a para http://169.254.169.254 em um host de nuvem e você pode roubar as credenciais da instância; aponte-a para http://localhost:6379 e você alcança serviços internos que nenhum usuário externo deveria tocar. A correção não é apenas validação de entrada, é uma allowlist estrita de destinos mais o bloqueio de faixas de IP internas e dos endpoints de metadados da nuvem. Pratique o ataque completo em um lab antes de tentar se defender dele.
O que é SSRF?
O Server-Side Request Forgery (SSRF) é uma vulnerabilidade web em que um atacante faz um servidor enviar requisições HTTP para um destino que ele controla. Em vez de a máquina do atacante alcançar um alvo, o servidor vulnerável faz isso, usando sua própria posição de rede, endereço IP e relações de confiança.
O perigo vem de onde o servidor está. Servidores de aplicação normalmente vivem dentro de uma rede, atrás do firewall, ao lado de bancos de dados, APIs internas, painéis de administração e serviços de metadados da nuvem. Esses sistemas confiam no tráfego do servidor de aplicação porque ele está "dentro". O SSRF entrega a um estranho essa posição interna.
O padrão vulnerável é qualquer funcionalidade que recebe uma URL ou hostname de uma entrada do usuário e a busca: enviadores de webhook, geradores de prévia de URL, renderizadores de PDF ou imagem que carregam recursos remotos, uploaders de "importar de URL" e desdobradores de links open-graph. Cada um é uma requisição que o servidor faz em seu nome, e se você controla o alvo, você controla para onde o servidor aponta sua própria conexão de confiança.
Onde o SSRF aparece
- Buscadores de URL - campos "insira uma URL de imagem" ou "importar de link" que puxam conteúdo remoto do lado do servidor.
- Webhooks - integrações que fazem POST para uma URL de callback fornecida pelo usuário são SSRF por design se o destino não for restrito.
- Processadores de documentos e imagens - conversores de HTML para PDF que seguem as fontes
<img>e<iframe>são uma superfície clássica de SSRF cego. - Ferramentas de análise e prévia - desdobradores de links que buscam uma página para montar um cartão de prévia buscarão páginas internas com a mesma disposição.
Como funciona um ataque SSRF
Um ataque SSRF tem três peças móveis: uma funcionalidade que busca uma URL, uma entrada que você controla, e um destino que o desenvolvedor nunca pretendeu que você alcançasse. O fluxo é curto.
- Encontre a busca. Localize um parâmetro que faz o servidor requisitar uma URL. Pode ser óbvio (
?url=https://example.com/logo.png) ou escondido dentro de JSON, de uma config de webhook, ou de um documento XML. - Redirecione-a para dentro. Substitua a URL externa por um alvo interno:
http://localhost/admin,http://127.0.0.1:8080, ou uma faixa privada comohttp://10.0.0.5. - Leia a resposta, ou infira-a. Se o servidor devolve o conteúdo buscado, isso é SSRF in-band e você vê o resultado diretamente. Se não, você recorre a diferenças de tempo e de erro para confirmar que a requisição aconteceu. Isso é SSRF cego.
Considere uma funcionalidade de prévia que chama GET /api/preview?url=https://site.com. O servidor busca qualquer URL que você passar. Envie url=http://169.254.169.254/latest/meta-data/ e, em uma instância AWS desprotegida, o servidor retorna seus próprios metadados de nuvem. Esse é o ataque inteiro: você nunca tocou a rede interna, o servidor foi lá dentro e entregou o resultado.
Na prática, a primeira coisa que vale testar é uma URL que você controla, como um endpoint de registro de requisições. Se o servidor alvo se conecta a ela, você provou que a busca acontece do lado do servidor e que o SSRF é real antes de gastar tempo em alvos internos. Isso também revela o IP de saída do servidor, um contexto útil para o resto do teste.
SSRF in-band vs SSRF cego
O SSRF se divide em duas famílias conforme você consegue ou não ver a resposta. A distinção decide toda a sua abordagem de teste.
SSRF in-band
O SSRF in-band retorna o conteúdo buscado diretamente na resposta HTTP. Você envia url=http://localhost/admin e a página de administração volta na resposta. Esse é o caso barulhento e fácil: você lê respostas internas tão claramente como se tivesse navegado até elas. O roubo de metadados de nuvem e o acesso a painéis de administração internos normalmente acontecem via SSRF in-band.
SSRF cego
O SSRF cego faz o servidor enviar a requisição, mas a resposta nunca volta para você. O servidor busca sua URL e descarta o corpo, então você não pode ler páginas internas diretamente. Ainda é perigoso. Você o confirma com uma interação out-of-band (aponte o servidor para um domínio que você monitora e observe a resolução DNS ou o acesso HTTP), depois o explora por efeitos colaterais: disparar ações internas, escanear portas por tempo, ou alcançar serviços que agem sobre uma requisição sem precisar retornar um corpo.
Opinião forte: não descarte por hábito um SSRF cego como baixa severidade. Um SSRF cego contra um endpoint de metadados de nuvem que aceita uma requisição e executa uma ação, ou contra um serviço interno com um handler GET perigoso, pode ser tão grave quanto a versão in-band. A falta de resposta visível limita sua conveniência, não o impacto.
Payloads SSRF e exemplos de ataque
O valor de um SSRF depende inteiramente do que o servidor consegue alcançar e você não. Estes são os alvos que transformam um bug de "busca uma URL" em um incidente de verdade.
Endpoints de metadados da nuvem
O alvo SSRF de maior valor em um host de nuvem é o serviço de metadados da instância. Na AWS, Azure e Google Cloud ele vive no endereço link-local 169.254.169.254 e, em configurações mais antigas, serve credenciais temporárias a qualquer coisa que as peça a partir da própria instância.
# AWS IMDSv1 - extrair as credenciais do papel da instância
http://169.254.169.254/latest/meta-data/iam/security-credentials/
# Google Cloud - exige um cabeçalho, que um SSRF em um proxy pode adicionar
http://metadata.google.internal/computeMetadata/v1/Em uma instância que ainda permite IMDSv1, essas credenciais deixam um atacante agir como o papel de nuvem do servidor. Essa única requisição é a razão pela qual o SSRF é tratado como uma descoberta de severidade crítica em infraestrutura de nuvem, e por que a AWS impôs o IMDSv2 (que exige um token de sessão) como padrão.
Serviços internos e escaneamento de portas
Aponte a busca para o loopback e faixas privadas para alcançar serviços que nunca esperavam tráfego externo:
# Interfaces de administração internas
http://127.0.0.1:8080/admin
http://localhost/server-status
# Armazenamentos de dados internos sem autenticação
http://127.0.0.1:6379 # Redis
http://127.0.0.1:9200 # ElasticsearchVariando a porta e medindo o tempo de resposta ou o tipo de erro, você pode mapear quais portas internas estão abertas, usando o servidor vulnerável como um scanner que ele não escolheu ser.
Contornos de filtro
A maioria das defesas de SSRF são blocklists ingênuas que procuram as strings 127.0.0.1 ou localhost. Elas caem diante de truques triviais de codificação, que é exatamente por que blocklists são a abordagem errada:
http://127.1 # forma curta de 127.0.0.1
http://2130706433 # 127.0.0.1 como inteiro decimal
http://[::1] # loopback IPv6
http://0177.0.0.1 # notação octal
http://localhost.attacker.com # registro DNS que resolve para 127.0.0.1Os esquemas file://, gopher:// e dict:// ampliam ainda mais o ataque, deixando o SSRF ler arquivos locais ou forjar pacotes brutos para serviços internos quando a biblioteca de busca os suporta.
SSRF vs CSRF: não são a mesma coisa
O SSRF forja uma requisição a partir do servidor; o CSRF forja uma requisição a partir do navegador da vítima. Os nomes parecem iguais e os acrônimos confundem as pessoas em entrevistas, mas os dois ataques miram extremidades opostas da conexão.
- SSRF (Server-Side Request Forgery) - o atacante abusa do servidor para alcançar sistemas internos. O servidor é o vice confuso fazendo requisições em nome do atacante.
- CSRF (Cross-Site Request Forgery) - o atacante abusa do navegador de um usuário logado para executar ações em um site onde o usuário está autenticado. O navegador da vítima é o vice confuso.
O SSRF dá alcance dentro de uma rede; o CSRF dá ações sob a sessão de outra pessoa. Para a análise completa do forjamento de requisições do lado do cliente e de seu primo o cross-site scripting, veja nosso guia sobre XSS vs CSRF.
Como prevenir o SSRF
Como prevenir o SSRF? Imponha uma allowlist estrita de destinos permitidos, bloqueie requisições para faixas de IP internas e para o endpoint de metadados da nuvem, e resolva e valide o hostname antes de a requisição ser feita. Somente filtrar a entrada não funciona, porque codificação e truques de DNS derrotam qualquer blocklist.
Combine estes controles em camadas, já que nenhum sozinho é suficiente:
- Allowlist, não blocklist. Permita apenas os domínios ou IPs específicos de que a funcionalidade legitimamente precisa. Todo o resto é negado por padrão. Esse é o único controle que realmente se sustenta.
- Bloqueie faixas internas. Rejeite requisições para
127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16, e a faixa link-local169.254.0.0/16que cobre os metadados da nuvem. - Resolva antes de buscar. Resolva o hostname para um IP, verifique esse IP contra suas regras, e então requisite esse IP exato. Isso fecha a brecha de DNS rebinding onde um nome passa na validação mas resolve para algo interno na hora da busca.
- Imponha o IMDSv2. Na AWS, exija metadados de instância baseados em token de sessão para que um simples GET de SSRF não consiga levantar credenciais. É uma mitigação gratuita e de alto impacto.
- Desative esquemas perigosos. Permita apenas
httpehttps. Rejeitefile://,gopher://,dict://e afins de imediato.
Ao testar aplicações reais, a mitigação que mais falha é a etapa "resolva antes de buscar". As equipes adicionam uma allowlist e um bloqueio de faixas privadas, depois validam a string do hostname mas buscam a URL de novo, deixando um registro DNS trocar entre a verificação e a requisição. Valide o IP resolvido, e busque esse IP, não o nome.
O SSRF no OWASP Top 10
O SSRF tem uma história incomum no OWASP Top 10. A edição de 2021 o promoveu ao seu próprio lugar dedicado, A10, em grande parte pela força da pesquisa comunitária que o apontou como uma preocupação crescente para aplicações modernas conectadas à nuvem.
Na revisão de 2025, o SSRF perdeu sua entrada autônoma e passou para dentro do Broken Access Control. Foi uma reclassificação, não um rebaixamento: os dados mostraram que o SSRF se encaixa naturalmente como uma falha de controle de acesso, já que é fundamentalmente o servidor fazendo uma requisição que não deveria ter sido autorizado a fazer. A ficha da OWASP e a entrada correspondente CWE-918 continuam sendo as definições de referência.
Para o quadro completo de onde o SSRF se situa entre os dez riscos e do que mudou entre as listas de 2021 e 2025, nosso guia do OWASP Top 10 mapeia cada categoria com um exemplo trabalhado. O SSRF também aparece constantemente em testes de API, onde um parâmetro de busca do lado do servidor é uma descoberta comum, que você pode treinar no lab API Breaker.
Considerações legais e éticas
Lembrete crítico: sempre obtenha autorização escrita explícita antes de testar qualquer sistema quanto a SSRF. Fazer um servidor buscar URLs internas em um alvo que você não possui é acesso não autorizado sob o Computer Fraud and Abuse Act (EUA), o Computer Misuse Act (Reino Unido) e leis equivalentes na maioria dos países.
- Teste SSRF apenas em sistemas que você possui, em labs dedicados, ou dentro do escopo definido de um engajamento autorizado.
- Credenciais de metadados da nuvem são segredos ativos. Se você as recuperar durante um teste autorizado, trate-as como descobertas sensíveis, não as use além da prova de impacto, e reporte-as imediatamente.
- A confirmação de um SSRF cego deve usar um endpoint colaborador que você controla, nunca a infraestrutura de terceiros.
- Pratique em alvos propositalmente vulneráveis, não em aplicações aleatórias da internet. Os labs abaixo existem exatamente para isso.
Perguntas frequentes
O que é um ataque SSRF em termos simples?
Um ataque SSRF engana um servidor para fazer uma requisição web a um destino escolhido pelo atacante. Como o servidor fica dentro da rede, o atacante consegue alcançar sistemas internos, serviços de metadados da nuvem e painéis de administração que um usuário externo normal nunca conseguiria acessar diretamente.
Qual a diferença entre SSRF e CSRF?
O SSRF forja uma requisição a partir do servidor, deixando um atacante alcançar sistemas internos. O CSRF forja uma requisição a partir do navegador de uma vítima logada, deixando um atacante executar ações sob a sessão desse usuário. O SSRF mira o lado do servidor; o CSRF mira o lado do cliente.
Por que o IP 169.254.169.254 é importante no SSRF?
Esse endereço link-local é o endpoint de metadados de instância na nuvem na AWS, Azure e Google Cloud. Em instâncias que ainda permitem o antigo IMDSv1, uma requisição SSRF para ele pode retornar credenciais temporárias do papel de nuvem do servidor, transformando um bug de busca de URL em acesso completo à conta de nuvem.
Como se previne o SSRF?
Use uma allowlist estrita de destinos permitidos em vez de uma blocklist, rejeite requisições para faixas de IP internas e link-local, resolva o hostname e valide o IP resolvido antes de buscá-lo, permita apenas os esquemas http e https, e imponha o IMDSv2 na AWS para que os metadados não possam ser levantados por uma simples requisição.
O que é SSRF cego?
SSRF cego é quando o servidor faz a requisição controlada pelo atacante mas não retorna o corpo da resposta. Você o confirma com uma interação out-of-band, como um callback DNS ou HTTP para um domínio que você monitora, e então o explora por efeitos colaterais como disparar ações internas ou escanear portas com base no tempo.
Parte da série OWASP Top 10
Artigos relacionados:
- Tutorial de Injeção SQL
- XSS vs CSRF
- Guia de Teste de Segurança Web OWASP
- O ataque SSRF explicado
- Teste de Intrusão de Aplicações Web
Seus próximos passos
O SSRF fica claro no momento em que você explora um você mesmo: aponte um servidor para o seu próprio endpoint de metadados, veja as credenciais voltarem, e a razão pela qual esse bug é classificado como crítico deixa de ser abstrata. Ler sobre o truque do 169.254.169.254 é uma coisa, burlar um filtro real para alcançá-lo é outra. Comece com o plano gratuito da HackerDNA, sem cartão de crédito, e quebre seu primeiro servidor no lab SSRF Validator. Quando quiser o SSRF no contexto de toda a superfície de ataque, o curso Web Attacks o percorre ao lado da injeção SQL, do XSS e do resto do OWASP Top 10 em labs guiados no navegador. Entenda como o servidor pode ser virado contra a própria rede, e então vá construir a allowlist que o barra.
