Aula prática sobre requisições HTTP, campos controlados pelo usuário e o momento em que uma aplicação passa a fazer chamadas para destinos que você escolheu.
HTTP
Ler método, endpoint, headers, corpo e resposta.
DevTools/Burp
Reenviar requisições mantendo o contexto.
SSRF
Usar uma entrada para influenciar uma chamada feita pelo servidor.
SSRF não começa no payload. Começa na leitura da requisição.
Procure campos que parecem apontar para fora da aplicação: URL, host, callback, webhook, image, next, redirect, stockApi, avatar, feed, import, preview. Se o backend usa esse valor para buscar algum recurso, existe uma pergunta que precisa ser respondida: quem faz a requisição, o navegador ou o servidor?
Quando é o servidor, o alcance muda. O request sai da aplicação, com rede, IP, permissões e confiança da aplicação. Esse é o ponto central da aula.
HTTP é o protocolo da aplicação web. Para testar SSRF, você não precisa decorar tudo do protocolo. Precisa saber onde a aplicação recebe dados e o que ela faz com eles.
Um padrão comum é o backend receber uma URL e usar essa URL para buscar outro recurso. No exemplo da aula, a aplicação recebe um campo parecido com stockApi e consulta um serviço de estoque.
formato que interessa na prática_ □ ×
POST /product/stock HTTP/1.1
Host: shop.example
Content-Type: application/x-www-form-urlencoded
Cookie: session=...
stockApi=https://stock.example/check?id=7
A pergunta não é só “esse parâmetro existe?”. A pergunta é: esse valor vira uma requisição feita pelo servidor?
2. Leia a requisição antes de mexer
C:\>devtools_ □ ×
Mantenha o contexto, mude um campo
Capture
Abra Network e encontre a requisição que muda algo.
Duplique
Use resend, replay, Burp Repeater ou a opção equivalente.
O erro mais comum é trocar várias coisas ao mesmo tempo. Aí você não sabe qual mudança causou o comportamento novo.
Para testar SSRF, preserve headers, cookies e método. Troque apenas a URL controlada. Primeiro use um destino simples. Depois teste loopback, rede interna, redirecionamento ou OAST, dependendo do laboratório.
troca mínima_ □ ×
# Original
stockApi=https://stock.example/check?id=7
# Teste controlado
stockApi=http://127.0.0.1/
# Teste de painel interno
stockApi=http://localhost/admin
3. Client-side não é fronteira de segurança
C:\>client-side_ □ ×
A interface limita; o servidor decide
Readonly
O HTML pode bloquear edição na tela.
Hidden
Campos escondidos continuam sendo enviados.
Select
O navegador mostra opções, mas a requisição aceita texto.
Em Command Injection, o dado atravessa a aplicação e vira comando inesperado. Em SSRF, o dado atravessa a aplicação e vira destino inesperado.
A aplicação vulnerável passa a funcionar como um cliente HTTP controlado pela entrada. Você não “entra” diretamente na rede interna. Você faz o servidor perguntar por você.
O navegador do atacante vem de fora. A aplicação está dentro da infraestrutura. Isso muda o que pode ser alcançado.
É por isso que SSRF é perigoso mesmo quando a resposta parece pequena. Um status diferente, uma demora ou um erro de conexão já podem indicar que a aplicação tentou alcançar um destino interno.
6. Basic SSRF e Blind SSRF
C:\>tipos_ □ ×
Às vezes a resposta volta. Às vezes não.
Basic SSRF
A resposta do destino aparece no retorno da aplicação.
Blind SSRF
A aplicação faz a chamada, mas o conteúdo não volta para você.
No Basic SSRF, o teste é mais direto: você altera a URL e observa HTML, JSON, status ou conteúdo retornado.
No Blind SSRF, a aplicação não mostra a resposta. Você confirma por efeito indireto: DNS lookup, HTTP callback, tempo de resposta, erro ou mudança de comportamento. Em Burp, isso normalmente entra no fluxo com Collaborator/OAST.
7. Sinais, impacto e defesa
C:\>defesa_ □ ×
Filtrar string não resolve sozinho
Sinais
URL/host no input, backend buscando recurso, erro de conexão, tempo variável.
Impacto
Dados internos, ações administrativas, credenciais e falsificação de origem.
Defesa
Allowlist real, validação após DNS, controle de redirects e restrição de saída.
Defesa boa não é só bloquear localhost com regex. URL tem variações, DNS muda, redirects existem e o parser da aplicação pode interpretar diferente do filtro.
O caminho defensivo é reduzir o que o servidor pode acessar, validar destino resolvido, revalidar redirecionamentos e usar allowlist de destinos esperados.