Uma API que aceita URLs, destinos de webhook, importação de imagens ou conexões personalizadas pode ser usada como ponte para redes internas e serviços de nuvem. O problema afeta aplicações que fazem requisições em nome do usuário; a ação prioritária é mapear cada saída de rede, restringir destinos permitidos e bloquear o acesso a serviços internos e metadados antes de confiar apenas na validação do endereço.

Onde está o risco

Server-Side Request Forgery (SSRF) ocorre quando o servidor busca um recurso controlado, direta ou indiretamente, por uma entrada externa. A aplicação pode parecer estar apenas baixando uma imagem, chamando um webhook ou consultando uma integração. Porém, se o destino for livre, o atacante transforma a aplicação em um procurador para alcançar serviços que não deveriam estar expostos.

A orientação da OWASP para prevenção de SSRF destaca que o ataque pode atingir a rede interna, a própria máquina e diferentes protocolos, não apenas uma página HTTP. Esse detalhe muda a revisão de código: procurar somente filtros contra endereços privados não basta quando o cliente HTTP segue redirecionamentos, resolve nomes de forma inesperada ou aceita esquemas além de HTTP e HTTPS.

O impacto depende da identidade atribuída ao processo. Um serviço com acesso amplo à rede, credenciais de aplicação ou permissão para consultar cofres pode transformar uma falha de entrada em exposição de segredos, alteração de recursos ou movimento lateral. Mesmo sem retorno do conteúdo ao usuário, uma requisição pode produzir efeitos observáveis em sistemas internos.

Âncora factual: SSRF transforma uma aplicação em ponte para redes internas. Esse é o ponto de decisão para a equipe: toda funcionalidade que dispara conexões precisa ter um modelo explícito de destinos, protocolos, autenticação e efeitos permitidos.

Escolha o modelo correto

A defesa mais forte começa por separar dois cenários. Se a função precisa chamar somente serviços conhecidos, use uma lista de permissão com nomes de serviço, portas e protocolos definidos pelo negócio. Não aceite uma URL completa quando a aplicação pode receber apenas um identificador de integração. O servidor deve construir o destino a partir de configuração controlada, e não reproduzir uma string fornecida pelo cliente.

Quando a finalidade exige destinos externos variados, a lista de permissão pode não ser suficiente. Nesse caso, combine validação rigorosa, resolução controlada, bloqueio de redes reservadas, proxy de saída e monitoramento. A validação deve ocorrer antes da conexão e ser reavaliada depois da resolução do nome. Também é necessário decidir como lidar com redirecionamentos: seguir qualquer redirecionamento reabre a possibilidade de escapar do controle inicial.

Não use uma expressão regular como única barreira para URLs complexas. Analise o endereço com uma biblioteca confiável, normalize o formato, limite esquemas e portas e compare o destino final com a política. Considere IPv4, IPv6, nomes alternativos, representações ambíguas e mudanças entre resolução DNS e conexão. O controle precisa ser implementado no componente que realmente abre o socket.

Superfície Controle prioritário Teste defensivo
Webhook Destinos aprovados e proxy de saída Rejeitar rede interna e redirecionamento indevido
Importação Esquemas limitados e tamanho máximo Verificar destino após resolução
Integração cloud Identidade mínima e rede segmentada Confirmar que metadados não são acessíveis
Cliente HTTP Timeout, portas e protocolos restritos Registrar bloqueios e falhas de conexão

Proteja a camada cloud

Serviços de metadados merecem tratamento específico porque podem fornecer informações de configuração, identidade temporária ou credenciais ao processo que faz a requisição. O bloqueio deve existir na aplicação, no proxy e na rede. Uma única regra de firewall não substitui as demais: alterações de rota, permissões excessivas ou um novo componente podem reabrir o caminho.

Remova do ambiente da aplicação qualquer permissão que não seja necessária para a função. Separe tarefas de leitura, gravação e administração; use identidades diferentes para serviços com riscos diferentes; restrinja o acesso por recurso; e reduza a duração e o alcance das credenciais. Se a aplicação for comprometida, o atacante deve encontrar uma identidade sem valor suficiente para controlar o restante do ambiente.

O modelo também precisa refletir o princípio de que a rede não é uma prova de confiança. O NIST SP 800-207 sobre arquitetura Zero Trust afirma que ativos e contas não devem receber confiança implícita apenas por sua localização física ou de rede. Para uma API, isso significa exigir autenticação e autorização na chamada ao recurso, mesmo quando o tráfego permanece dentro da nuvem.

Âncora factual: localização de rede não deve conceder confiança implícita. A aplicação deve provar quem é, o que pretende acessar e por que a ação é permitida. Segmentação reduz o alcance do erro, mas não substitui a decisão baseada em identidade, recurso e contexto.

Faça a entrega segura

A prevenção precisa entrar no ciclo de desenvolvimento. No inventário de endpoints, marque funções que recebem URL, host, IP, callback, arquivo remoto ou destino de integração. Para cada uma, registre o formato aceito, o protocolo, o destino esperado, a identidade usada e o impacto de uma chamada indevida. Esse catálogo fornece uma condição objetiva para revisão e teste.

No código, prefira clientes configurados centralmente. Desative protocolos que não fazem parte do requisito, imponha limites de tempo e tamanho, impeça redirecionamentos automáticos quando eles não forem necessários e trate respostas inesperadas como falha. A camada de rede deve impedir conexões para localhost, redes privadas, endereços reservados e serviços de metadados, com exceções documentadas e revisadas.

No pipeline, inclua análise estática para localizar clientes HTTP alimentados por entrada externa, testes unitários para a política de destinos e testes de integração no ambiente isolado. O caso negativo é tão importante quanto o positivo: a equipe deve provar que uma URL válida para o negócio continua funcionando e que uma tentativa de alcançar um serviço interno é recusada antes da conexão.

Evite corrigir o problema apenas com uma lista de bloqueio. Listas negativas podem falhar diante de resolução DNS, redirecionamentos e mudanças de representação. A lista de permissão é preferível quando o fluxo tem destinos conhecidos; quando não for possível, a combinação de validação, proxy, isolamento, identidade mínima e observabilidade precisa ser tratada como um controle composto.

Detecte e responda

Registre a decisão, não apenas o erro genérico. Para cada requisição de saída, preserve a função que originou a chamada, o identificador da integração, o destino normalizado, o resultado da política, o código de resposta, a identidade do serviço e um identificador de correlação. Não grave tokens, cabeçalhos sensíveis ou conteúdo privado sem necessidade.

A equipe deve alertar para tentativas repetidas contra destinos bloqueados, mudanças súbitas no conjunto de destinos, respostas de serviços que não pertencem ao fluxo e uso de protocolos incomuns. Correlacione esses sinais com alterações recentes no código, criação de credenciais, mudanças de permissões e atividade do plano de controle cloud.

O guia do portal sobre logs de segurança explica por que a coleta deve responder quem autenticou, qual recurso foi atingido e qual decisão ocorreu. A análise de SSRF exige a mesma disciplina: sem identidade, destino e resultado, o alerta não permite distinguir teste autorizado, erro de configuração e tentativa de exploração.

Se houver indício de exploração, preserve os registros antes de alterar o serviço quando isso não aumentar o risco, bloqueie a função ou o destino vulnerável, revogue credenciais que possam ter sido alcançadas e examine chamadas feitas pela identidade da aplicação. O plano de resposta a incidentes do portal recomenda separar contenção técnica, preservação de evidências e decisões de comunicação.

Âncora factual: observabilidade deve registrar destino, identidade e resultado da decisão. Sem essa trilha, a equipe pode bloquear a requisição original e ainda deixar sem investigação as ações realizadas pelo serviço em nome dela.

Priorize a execução

P1: inventarie todas as funções que iniciam conexões; bloqueie destinos internos e serviços de metadados na rede; remova permissões cloud desnecessárias; desative redirecionamentos não requeridos; e crie um alerta para tentativas bloqueadas.

P2: substitua URLs livres por identificadores de integração quando possível; centralize o cliente de saída; adicione testes de resolução e redirecionamento; padronize os registros; atribua proprietário a cada exceção; e execute um exercício de resposta usando uma identidade de baixo privilégio.

O resultado esperado não é apenas uma biblioteca atualizada. É uma cadeia verificável em que a aplicação só alcança destinos necessários, a rede limita o alcance, a identidade não possui poder excessivo e os registros permitem reconstruir a decisão. Essa combinação transforma SSRF de uma hipótese difícil de investigar em um risco controlado por engenharia.

Fontes

  • OWASP — Server-Side Request Forgery Prevention Cheat Sheet.
  • NIST — SP 800-207, Zero Trust Architecture.
  • Ciberseguranca.org — Logs de segurança: guia prático para detectar ataques.
  • Ciberseguranca.org — Resposta a incidentes: plano prático para empresas.