SSRF é um problema de identidade na nuvem, não apenas um filtro de URL

Em resumo: Uma falsificação de solicitação no servidor pode transformar uma busca aparentemente inofensiva em acesso a serviços internos e credenciais de nuvem. Defesas robustas restringem destinos, redirecionamentos, resolução DNS e identidade da carga de trabalho em conjunto.

O recurso vulnerável geralmente parece inofensivo

Os aplicativos buscam conteúdo remoto para visualizações de links, webhooks, importações de documentos, processamento de imagens e verificações de segurança. O perigo começa quando um invasor controla qualquer parte do destino e o servidor consegue alcançar redes que o invasor não consegue. O aplicativo se torna um proxy que transporta a confiança do servidor para o espaço interno.

Bloquear uma pequena lista de strings não é suficiente. Representações IP alternativas, formulários IPv6, redirecionamentos, sintaxe de informações do usuário e religação DNS podem transformar uma URL aparentemente pública em uma solicitação de endereço de loopback, serviço privado ou endpoint de metadados em nuvem após a validação já ter passado.

Valide todas as decisões de rede

• Permita apenas esquemas e portas necessários e rejeite credenciais, fragmentos, sintaxe de host ambígua e formulários de endereço não canônicos.
• Resolva o nome do host, classifique cada endereço retornado e rejeite loopback, privado, link local, multicast e intervalos reservados para IPv4 e IPv6.
• Revalide cada destino de redirecionamento e fixe a conexão no endereço validado para impedir que o DNS mude entre a verificação e a solicitação.
• Aplique limites de tamanho de resposta, tipo de conteúdo, tempo limite e redirecionamento para que uma busca permitida não se torne um caminho de esgotamento de recursos.

Os controles de rede devem servir de proteção às verificações da aplicação

A validação do aplicativo evoluirá e poderá regredir, portanto, o tempo de execução precisa de um limite de saída independente. Um serviço de busca dedicado com uma lista de permissões estreita, caminho de rede isolado e nenhum acesso aos planos de controle de produção reduz drasticamente o alcance de um erro de analisador.

As proteções de metadados na nuvem também são importantes. Exija protocolos de metadados orientados à sessão quando houver suporte, bloqueie rotas de metadados na camada de rede e forneça à carga de trabalho de busca a menor identidade possível. Se uma solicitação atingir um endpoint de credencial interna, deverá haver pouco ou nada útil para roubar.

Teste classes de evasão, não apenas uma carga útil

Uma única solicitação para um endereço de metadados conhecido é apenas um teste rápido. Uma suíte completa de SSRF cobre truques de codificação, endereços decimais e hexadecimais, notação IPv6 mista, cadeias de redirecionamento, alterações de DNS, divergências entre analisadores e nomes de host internos. Ela também verifica se as falhas não vazam tempos de resposta nem fragmentos do corpo.

A abordagem orientada por evidências do KENSAI registra a classificação do destino e o endereço realmente conectado. Isso transforma um bloqueio aparente em prova verificável de que a solicitação nunca ultrapassou o limite de rede pretendido.

Conclusão

Trate a busca remota como acesso privilegiado à rede. Valide e fixe destinos, verifique novamente os redirecionamentos, restrinja a saída e minimize a identidade da carga de trabalho para que um erro de análise não possa se tornar um comprometimento da nuvem.