Uma aplicação que busca imagens, chama webhooks ou consulta serviços em nome do utilizador pode ser transformada em ponte para redes internas. O problema afeta APIs, painéis administrativos, processadores de documentos e workloads cloud; a ação prioritária é retirar a decisão de destino do controlo direto do utilizador, aplicar uma lista permitida quando o fluxo for conhecido e bloquear caminhos para serviços de infraestrutura.
O risco começa na URL
SSRF transforma uma função legítima em um proxy para redes que o utilizador não deveria alcançar. A aplicação recebe uma URL ou um destino, resolve o endereço e faz uma segunda requisição com a sua própria conectividade e identidade. O atacante não precisa entrar diretamente na rede privada se conseguir fazer o servidor realizar a chamada por ele.
O padrão aparece em funcionalidades aparentemente banais: importar uma imagem por URL, validar uma integração, buscar um documento remoto, receber um callback ou gerar uma prévia de página. O servidor costuma possuir rotas que não existem no navegador do utilizador. Pode alcançar serviços administrativos, interfaces internas, bases de dados, sistemas de descoberta e endpoints de metadados de uma instância cloud.
O primeiro diagnóstico deve mapear todas as funções que aceitam destinos externos ou seguem referências fornecidas por terceiros. Não limite a revisão aos parâmetros chamados url. Procure campos como callback, webhook, image, source, redirect, importação de ficheiros e conversão de documentos. Bibliotecas de pré-visualização, leitores XML e clientes HTTP internos também entram no escopo.
O risco aumenta quando a resposta da requisição é devolvida ao cliente, quando a aplicação envia credenciais automaticamente ou quando o componente tem acesso amplo à rede. Uma falha de SSRF pode servir para sondar portas, consultar APIs internas ou acionar operações com a identidade do servidor. Mesmo sem retorno do conteúdo, diferenças de tempo, códigos HTTP e mensagens de erro podem revelar se um destino existe.
Escolha uma política de destino
Para fluxos que conhecem os destinos legítimos, a decisão recomendada é uma lista permitida. Em vez de aceitar qualquer domínio e tentar bloquear endereços perigosos, defina os serviços necessários, os esquemas aceitos, as portas previstas e o método permitido. A lista deve ser mantida como configuração revisada, com proprietário e justificativa por integração.
Valide a entrada com o mesmo analisador que será usado para executar a requisição. Não compare apenas a string recebida. Normalize o domínio segundo as regras da biblioteca, resolva o nome e valide os endereços resultantes antes da conexão. A comparação deve impedir ambiguidades de maiúsculas, codificação, credenciais embutidas, fragmentos, portas inesperadas e formas alternativas de representar um endereço.
A orientação da OWASP para prevenção de SSRF separa o caso em que a aplicação chama serviços conhecidos daquele em que precisa acessar destinos arbitrários. Essa distinção evita uma política genérica aplicada a necessidades diferentes. Se a integração é conhecida, permita o mínimo. Se o produto realmente exige destinos livres, trate a saída como um perímetro de alto risco e compense a ausência de uma lista fixa com isolamento de rede, filtragem de protocolos e monitoramento detalhado.
Não permita que o cliente escolha livremente o esquema. Se a função precisa de HTTPS, aceite somente HTTPS. Desative esquemas locais ou alternativos e rejeite explicitamente protocolos que não fazem parte do requisito. O cliente HTTP deve ser configurado para não seguir redirecionamentos automaticamente. Um destino inicialmente aprovado pode redirecionar para uma rede privada e contornar a validação se a biblioteca continuar a navegação sem uma nova verificação.
Combine aplicação e rede
A validação de entrada é necessária, mas não deve ser a única barreira. Execute o componente que faz requisições em uma sub-rede sem acesso administrativo e sem rota desnecessária para bases de dados, painéis de gestão ou outros planos de controle. Permita saída apenas para os serviços exigidos e registre recusas de conexão com contexto suficiente para investigação.
O filtro de rede deve considerar resolução DNS e o endereço efetivamente usado na conexão. Uma regra baseada apenas no nome pode ser enganada por mudanças de resolução, múltiplos endereços ou reconfiguração do destino. Se o nome legítimo precisar apontar para vários endereços, todos devem ser avaliados segundo a política. Reavalie o destino depois de resolver e antes de abrir a conexão, e não confie em uma consulta feita em uma etapa separada.
Defina limites operacionais: tempo máximo de conexão, tempo máximo de resposta, tamanho máximo do corpo, número de redirecionamentos e quantidade de requisições por utilizador. Esses limites reduzem impacto de abuso e impedem que uma função de integração seja convertida em mecanismo de exaustão de recursos. Eles não substituem autorização de destino, mas tornam a falha mais contida.
O cliente também deve remover cabeçalhos e credenciais que não sejam necessários. Nunca encaminhe automaticamente cookies da sessão do utilizador, tokens de serviço, cabeçalhos de administração ou variáveis de autenticação para um destino escolhido pelo cliente. Separe o cliente usado para integrações confiáveis de componentes que processam entradas não confiáveis, quando a arquitetura permitir.
Essa revisão combina com o controle contínuo de infraestrutura como código: regras de saída, rotas e permissões devem ser verificadas no plano de mudança. Também é útil relacionar o fluxo aos logs de nuvem, pois uma barreira que bloqueia sem registrar o contexto deixa a equipa sem material para distinguir ataque, erro de configuração e integração quebrada.
Proteja o serviço cloud
Em instâncias Amazon EC2, não trate o serviço de metadados como um destino comum. A documentação da AWS explica que é possível configurar a instância para aceitar somente chamadas IMDSv2, fazendo com que chamadas IMDSv1 falhem. A mudança reduz uma classe de acessos indiretos, mas não corrige uma aplicação que pode alcançar livremente redes internas.
IMDSv2 exige uma sessão com token antes da leitura de metadados. O token precisa acompanhar as requisições seguintes e, quando o uso de token está configurado como obrigatório, chamadas sem um token válido ou com token expirado recebem erro de autorização. A equipa deve validar essa configuração nas imagens, nos grupos de instâncias e nos ambientes que criam recursos automaticamente.
Faça a alteração com inventário prévio. SDKs antigos, agentes de monitoramento e scripts locais podem depender do comportamento anterior. Atualize os componentes compatíveis, teste a aplicação em uma instância de homologação e acompanhe falhas de acesso ao metadado. A exceção temporária deve ter responsável, prazo e condição de remoção; manter o modo permissivo por conveniência transforma uma medida de contenção em promessa sem data.
Também vale revisar o limite de saltos quando houver containers ou proxies no mesmo host. Um limite mais amplo pode ser necessário para compatibilidade, mas amplia o caminho pelo qual uma requisição pode alcançar o serviço. Trate essa configuração como decisão de arquitetura, não como ajuste automático. O objetivo é garantir que somente processos previstos alcancem metadados e que a identidade da instância não fique disponível para uma aplicação exposta.
Procedimento para esta semana
| Prioridade | Ação | Evidência esperada |
|---|---|---|
| P1 | Inventariar endpoints que recebem URLs, callbacks ou destinos externos. | Mapa de funções, responsáveis, esquemas, domínios e portas. |
| P1 | Aplicar lista permitida e desativar redirecionamentos automáticos. | Testes que rejeitam destinos privados, esquemas indevidos e redirecionamentos não aprovados. |
| P1 | Separar a saída de rede e remover credenciais automáticas do cliente HTTP. | Regras de firewall, identidade mínima e teste de cabeçalhos enviados. |
| P1 | Exigir IMDSv2 nas instâncias que suportam a mudança. | Configuração verificada e relatório de componentes incompatíveis. |
| P2 | Instrumentar resolução, destino final, decisão da política e resultado da conexão. | Eventos pesquisáveis sem tokens, cookies ou dados sensíveis. |
| P2 | Testar DNS, redirecionamentos, IPv6, limites de resposta e falhas de rede. | Casos automatizados no pipeline e evidência de bloqueio. |
Os sinais prioritários são tentativas repetidas contra endereços reservados, mudanças de domínio para um mesmo fluxo, uso de esquemas não previstos, picos de falhas de conexão e requisições para destinos que nunca apareceram no inventário. Correlacione esses eventos com a identidade da aplicação, o utilizador que iniciou a operação e a mudança de configuração que habilitou a integração.
A decisão defensiva não é bloquear toda comunicação externa. É tornar explícito quais componentes podem chamar quais destinos, com qual identidade e sob quais limites. Quando a necessidade de negócio for ampla demais para uma lista permitida, isole o componente, reduza privilégios, limite a rede e assuma que cada resposta externa precisa de tratamento como conteúdo não confiável. O resultado é uma superfície de saída controlável, em vez de um servidor que funciona como proxy para o ambiente inteiro.