SSRF: Como identificar e validar com segurança

Fontes de SSRF

Nesta fase, definimos quais evidências são necessárias para responder à questão de investigação. Para o teste SSRF, os pontos básicos são Função e sessão, Ponto de extremidade e método, Requisição/Resposta e Identificador de objeto. Para cada fonte, registamos o proprietário, o período de retenção, o fuso horário, o atraso na ingestão e os campos potencialmente ausentes.

A qualidade da recolha não é medida apenas pela “chegada” do registo. Deve-se verificar a completude, latência, análise (parsing), eventos duplicados e sincronização do tempo. Um teste Canary ou um evento de laboratório conhecido permite verificar se a ação apareceu na fonte, passou pelo Pipeline e pode ser pesquisada nos campos corretos.

Mapeamento de entradas de URL

O tópico 'Mapeamento de entradas de URL' é uma parte central do trabalho em testes SSRF. É recomendável dividi-lo em três perguntas: Qual é a entrada? Que decisão se quer tomar? E que evidência é suficiente para justificá-la? Essas perguntas evitam o uso automático de ferramentas sem entender o objetivo.

Na prática, registe o recurso de busca de URL, a lista de permissões (allowlist), os redirecionamentos, as defesas de DNS rebinding, o metadata endpoint, compare com o comportamento esperado e defina pelo menos um Pivot. O resultado deve ser verificável por outro analista, incluindo limitações e próximos passos.

Validação contra servidor de laboratório

Para entender a diferença no contexto do teste SSRF, é importante comparar objetivos e não apenas ferramentas. Uma opção oferece amplitude ou velocidade, e outra oferece validação profunda ou contexto. A escolha certa depende da pergunta: É necessária descoberta, investigação, prova de impacto, contenção ou relatório?

Uma tabela de comparação profissional deve incluir pelo menos: tipo de entrada, nível de certeza, custo operacional, impacto potencial, limitações e continuação necessária. Em caso de dúvida, use a abordagem menos invasiva e adicione uma fonte complementar em vez de tirar uma conclusão muito ampla.

Blind SSRF e Logging

Nesta fase, definimos quais evidências são necessárias para responder à questão de investigação. Para o teste SSRF, os pontos básicos são Função e sessão, Ponto de extremidade e método, Requisição/Resposta e Identificador de objeto. Para cada fonte, registamos o proprietário, o período de retenção, o fuso horário, o atraso na ingestão e os campos potencialmente ausentes.

A qualidade da recolha não é medida apenas pela “chegada” do registo. Deve-se verificar a completude, latência, análise (parsing), eventos duplicados e sincronização do tempo. Um teste Canary ou um evento de laboratório conhecido permite verificar se a ação apareceu na fonte, passou pelo Pipeline e pode ser pesquisada nos campos corretos.

Remediação e Reteste

Um teste profissional para SSRF começa com condições de sucesso e condições de falha. Define-se um Caso positivo, um Caso negativo, um Caso de limite e uma atividade legítima semelhante. Desta forma, é possível identificar tanto Falsos Negativos quanto Falsos Positivos.

Num ambiente autorizado, utiliza-se uma ação mínima que prova a alegação sem causar danos. Guarda-se a Entrada, a Saída, o tempo e a versão, e após a correção, realiza-se um Reteste no mesmo cenário e verifica-se também a Regressão em funções próximas.

Focos de Teste Exclusivos

Neste tópico, é recomendável construir um mapa de evidências focado de antemão. Os principais focos de teste são: URL fetch feature, allowlist, redirects, DNS rebinding defenses, metadata endpoint, egress controls. A lista não é um Checklist automático; cada item é escolhido porque pode ligar uma entidade, ação e tempo, ou explicar um comportamento legítimo.

• URL fetch feature: Defina qual é o valor esperado, o que seria considerado excecional e qual fonte adicional validaria a descoberta.
• allowlist: Defina qual é o valor esperado, o que seria considerado excecional e qual fonte adicional validaria a descoberta.
• redirects: Defina qual é o valor esperado, o que seria considerado excecional e qual fonte adicional validaria a descoberta.
• DNS rebinding defenses: Defina qual é o valor esperado, o que seria considerado excecional e qual fonte adicional validaria a descoberta.
• metadata endpoint: Defina qual é o valor esperado, o que seria considerado excecional e qual fonte adicional validaria a descoberta.
• egress controls: Defina qual é o valor esperado, o que seria considerado excecional e qual fonte adicional validaria a descoberta.

Quando um dos focos não está disponível, deve-se documentar a lacuna e escolher uma alternativa. Por exemplo, se o Process identifier não for estável, pode-se usar tempo, Host, User e Parent; se o Payload estiver encriptado, usam-se Metadata, volume, frequência e o contexto TLS/DNS.

Processo de Trabalho Recomendado

1. Defina o Escopo e uma questão de trabalho sobre o tema do teste SSRF.
2. Anote as fontes de dados e as evidências necessárias: URL fetch feature, allowlist, redirects, DNS rebinding defenses.
3. Crie uma Baseline curta de comportamento correto ou resultado esperado.
4. Execute o teste mínimo em um ambiente de laboratório e salve o tempo, a entrada e a saída.
5. Construa uma Linha do Tempo ou tabela de comparação e separe o fato da interpretação.
6. Execute um Pivot para uma fonte adicional para confirmar ou refutar a explicação inicial.
7. Resuma a decisão, limitações, ação recomendada e critério de Reteste.

Cenário Prático

O cenário escolhido é o teste contra um Callback local em um laboratório. O objetivo do exercício não é provar uma capacidade de ataque, mas praticar a recolha, comparação e documentação de forma segura. Antes de iniciar o trabalho, são definidos dados simulados, uma janela de tempo e um resultado esperado.

Ao final do exercício, deve-se apresentar um produto que outro analista ou testador possa revisar: uma imagem ou Export da evidência, uma linha do tempo curta, uma hipótese inicial, uma evidência de validação, uma limitação e uma recomendação. Quando não há evidência suficiente, a conclusão correta é que o cenário não foi comprovado.

Lista de Verificação Prática

• ✓Verifique e documente: Função e sessão.
• ✓Verifique e documente: Ponto de extremidade e método.
• ✓Verifique e documente: Requisição/Resposta.
• ✓Verifique e documente: Identificador de objeto.
• ✓Verifique e documente: Efeito no lado do servidor.
• ✓Verifique e documente: Controle esperado e remediação.
• ✓Indique o Fuso horário, versão da ferramenta e hora da recolha.
• ✓Guarde os dados brutos antes de filtrar ou alterar.
• ✓Escreva o que a descoberta prova e o que ainda é desconhecido.
• ✓Defina o proprietário e a ação de acompanhamento com uma data.

Erros Comuns

• Verificar apenas o Status code.
• Confiar apenas na alteração do Client-side.
• Usar um Payload perigoso.
• Não testar diferentes Funções.
• Ignorar a lógica de negócios.
• Relatar sem Requisições/Respostas limpas.

Resumo e CTA

SSRF: Como identificar e validar com segurança é um tópico que conecta conhecimento técnico à disciplina de trabalho. Comece com uma pergunta, colete apenas evidências relevantes, mantenha o contexto e o tempo, e escolha uma ação que possa ser justificada e retestada.

No curso Cybersecurity & AI da HPI, estes princípios são praticados usando sistemas, registos e laboratórios. O próximo passo natural é consultar os artigos relacionados, realizar o exercício de laboratório e guardar o produto como parte de um portfólio profissional.

Perguntas frequentes