SSRF: o que é Server-Side Request Forgery e como se defender

Server-Side Request Forgery, ou SSRF, é uma das vulnerabilidades mais subestimadas em aplicações modernas, e ao mesmo tempo uma das mais perigosas quando a aplicação roda em nuvem. A ideia central é simples de enunciar e difícil de defender: o atacante consegue fazer com que o seu servidor emita uma requisição de rede para um destino que ele, atacante, escolhe. O servidor age como um intermediário confuso, usando a confiança e a posição de rede privilegiada que ele tem para alcançar recursos que o atacante jamais alcançaria diretamente.

Este texto explica o que é SSRF, por que ela existe, como um atacante a explora na prática, qual é o alvo clássico em ambientes de nuvem e, principalmente, como construir uma defesa em profundidade que realmente segura o ataque. SSRF não se resolve com um único filtro; se resolve com várias camadas que se apoiam umas nas outras.

O que é SSRF e por que ela existe

SSRF nasce sempre que uma aplicação recebe, direta ou indiretamente, uma URL ou um endereço de rede vindo do usuário e faz uma requisição para esse destino sem validar adequadamente para onde está indo. O ponto crucial é a mudança de perspectiva de rede. Quando você faz uma requisição do seu navegador, ela sai da sua máquina, na internet pública, sujeita a todos os firewalls e controles de borda. Quando o servidor faz a requisição por você, ela sai de dentro da infraestrutura, de um ponto que muitas vezes tem acesso a redes internas, a serviços que não estão expostos ao público e a endpoints de administração que confiam em quem está na rede local.

O atacante explora exatamente essa diferença. Ele não consegue acessar http://10.0.0.5/admin do seu navegador, porque esse IP é privado e inalcançável pela internet. Mas se ele conseguir convencer o seu servidor a buscar essa URL, o servidor, que está dentro da rede, alcança o recurso e, dependendo de como a aplicação trata a resposta, devolve o conteúdo para o atacante. A vulnerabilidade transforma o servidor num procurador que executa requisições em nome de quem não deveria ter esse poder.

Onde SSRF costuma aparecer

O padrão que gera SSRF aparece em muitos lugares porque buscar coisas por URL é uma funcionalidade legítima e comum. Um caso frequente é o campo que aceita a URL de uma imagem para importar um avatar ou uma capa: o servidor baixa a imagem daquela URL. Outro é a funcionalidade de webhook, em que o usuário configura um endereço para o qual o sistema envia notificações. Geradores de PDF e serviços de captura de tela que renderizam uma página a partir de uma URL fornecida são um vetor clássico, porque o renderizador segue links, carrega recursos e pode ser induzido a acessar destinos internos.

Integrações que validam ou consomem uma URL informada pelo usuário, importadores que puxam dados de um endereço remoto, proxies e funcionalidades de pré-visualização de link também entram na lista. Sempre que existe a combinação "o usuário me diz para onde ir e eu vou", existe risco de SSRF. Vale lembrar que a URL nem sempre chega de forma óbvia: ela pode estar embutida num documento, num campo escondido de formulário, num cabeçalho, ou ser construída a partir de partes que o usuário controla parcialmente.

O alvo clássico: metadados de nuvem e rede interna

Em ambientes de nuvem, o alvo mais cobiçado de um SSRF é o serviço de metadados da instância. Provedores expõem, para máquinas virtuais e contêineres, um endpoint interno acessível num endereço de link-local, tradicionalmente 169.254.169.254, que devolve informações da instância e, em muitas configurações antigas ou mal ajustadas, credenciais temporárias de acesso à conta de nuvem. Se um atacante consegue um SSRF que alcança esse endpoint e recebe de volta a resposta, ele pode extrair essas credenciais e, a partir daí, agir com os privilégios daquela instância dentro da conta. Um bug de aplicação vira um comprometimento de infraestrutura.

Além dos metadados, o atacante mira toda a rede interna: bancos de dados que só escutam na rede privada, painéis administrativos de serviços auxiliares, filas, caches, APIs internas sem autenticação porque "só a rede interna acessa". O localhost do próprio servidor é outro alvo, porque muitos serviços de administração escutam apenas na interface de loopback confiando que ninguém de fora chega ali. SSRF quebra exatamente essa suposição de que "estar na rede é estar autorizado", uma suposição que o princípio do menor privilégio recomenda abandonar de qualquer forma.

SSRF cega e SSRF com resposta

Vale distinguir duas situações, porque elas mudam o que o atacante consegue e o que você precisa defender. Na SSRF com resposta, o conteúdo da requisição feita pelo servidor volta para o atacante, seja diretamente no corpo da resposta, seja refletido numa mensagem de erro ou num campo qualquer. Essa é a versão mais poderosa, porque permite exfiltrar dados, ler metadados, mapear a rede interna a partir das respostas.

Na SSRF cega, o atacante não vê a resposta, mas ainda assim consegue provar que a requisição aconteceu, por exemplo observando diferenças de tempo de resposta, mensagens de erro distintas, ou fazendo o servidor bater num endereço controlado por ele para confirmar o alcance. Mesmo cega, a vulnerabilidade é perigosa: ela pode ser usada para varrer portas internas, disparar ações em endpoints que executam efeitos colaterais só de serem acessados, e servir de alicerce para ataques encadeados. Nunca trate SSRF cega como inofensiva.

Defesa em profundidade contra SSRF

Não existe um único interruptor que resolva SSRF. A defesa correta é uma pilha de controles, cada um cobrindo a falha do anterior. O erro mais comum é tentar resolver com uma blocklist, uma lista de endereços proibidos, o que quase sempre falha porque o atacante tem infinitas formas de escrever o mesmo destino.

Prefira allowlist a blocklist

A regra de ouro é validar por allowlist: defina explicitamente os destinos que a funcionalidade tem direito de acessar e recuse tudo o mais. Se a sua aplicação só precisa buscar imagens de um punhado de domínios conhecidos, permita apenas esses domínios. Blocklists de faixas privadas parecem suficientes, mas são contornáveis com truques de codificação da URL, notações alternativas de IP, nomes de domínio que resolvem para endereços internos, encurtadores e redirecionamentos. Comece do "nada é permitido" e abra o mínimo necessário.

Resolva o DNS e valide o IP resolvido

Validar a string da URL não basta, porque um domínio aparentemente externo pode resolver para um IP interno, um truque conhecido como DNS rebinding quando o valor muda entre a checagem e o uso. A defesa robusta resolve o nome, valida o endereço IP resultante contra as faixas privadas, de loopback, de link-local e de metadados, e só então faz a requisição, idealmente conectando ao IP já validado para eliminar a janela entre checar e usar. Rejeite qualquer resolução que caia em 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16 e nos equivalentes em IPv6.

Bloqueie redirecionamentos e esquemas perigosos

Um atacante pode fornecer uma URL externa perfeitamente válida que, ao ser acessada, responde com um redirecionamento para um destino interno. Se o seu cliente HTTP segue redirecionamentos automaticamente, ele obedece. Desabilite o seguimento automático de redirecionamento ou revalide o destino a cada salto. Restrinja também os esquemas aceitos apenas a http e https; esquemas como file://, gopher://, ftp:// e dict:// abrem portas para ler arquivos locais e falar protocolos internos, e não têm razão de existir numa funcionalidade de busca de URL pública.

Isole a rede de saída e endureça a nuvem

As camadas anteriores são de aplicação; a próxima é de rede. Restrinja o tráfego de saída do serviço com um firewall de egress ou um proxy de saída que só permite os destinos legítimos. Assim, mesmo que a validação de aplicação falhe, a requisição maliciosa não sai. No ambiente de nuvem, exija a versão do serviço de metadados que requer autenticação por token com um passo prévio, o que neutraliza o SSRF simples contra o endpoint de metadados, e reduza ao máximo os privilégios da role atribuída à instância, seguindo os mesmos princípios que valem para qualquer superfície descrita no OWASP Top 10. Quanto menos poder a instância comprometida tiver, menor o estrago de um SSRF bem-sucedido.

Trate a resposta com cuidado

Por fim, limite o que a sua aplicação faz com a resposta da requisição. Não devolva o corpo bruto para o cliente sem necessidade, não exponha cabeçalhos internos, não reflita mensagens de erro que revelem a topologia da rede. Limite o tamanho do download e imponha timeouts, para não transformar o SSRF numa ferramenta de negação de serviço ou de leitura de respostas gigantes. Cada informação que você evita devolver é uma capacidade que você tira das mãos do atacante.

Um exemplo mental do encadeamento

Vale amarrar tudo num exemplo mental, sem código, para ver como as camadas se apoiam. Imagine uma funcionalidade que gera a pré-visualização de um link que o usuário cola: o servidor busca a página, extrai o título e a imagem, e devolve um cartão bonito. Um atacante cola, em vez de um link normal, um endereço que aponta para o serviço de metadados da nuvem. Se a aplicação não valida o destino, o servidor busca aquele endereço interno, e o título ou a imagem do cartão passam a conter credenciais da instância, exfiltradas na cara do atacante. Se a validação de destino existe mas confia apenas na string, o atacante usa um domínio próprio que resolve para o endereço interno, ou responde com um redirecionamento para ele. Se o cliente HTTP segue redirecionamentos sem revalidar, cai no mesmo buraco.

Agora observe como cada camada de defesa quebra um elo dessa corrente. A allowlist de destinos recusa o endereço interno logo de cara, porque ele não está entre os poucos domínios permitidos para pré-visualização. A resolução e validação do IP pega o truque do domínio que aponta para dentro, porque o endereço resolvido cai numa faixa proibida. O bloqueio de redirecionamento neutraliza a resposta que tenta desviar para o interno. O firewall de saída impede a requisição de sequer deixar o servidor caso tudo o mais falhe. E o endpoint de metadados endurecido, que exige um passo prévio autenticado, torna inútil o SSRF simples contra ele. Nenhuma camada precisa ser perfeita, porque a que falha é coberta pela seguinte, e é essa redundância deliberada que transforma um alvo fácil num alvo que resiste. Projetar assim, assumindo que cada controle individual pode falhar, é o que distingue uma defesa madura de uma checagem única e otimista.

Conclusão

SSRF é uma vulnerabilidade de posição: ela não explora um bug de memória nem uma injeção de código, mas o fato de o servidor estar num lugar de rede privilegiado e aceitar instruções sobre para onde ir. Por isso a defesa também é posicional e em camadas: validar destinos por allowlist, resolver e checar o IP real, barrar redirecionamentos e esquemas perigosos, restringir a rede de saída e endurecer os metadados de nuvem. Nenhuma dessas medidas sozinha é suficiente, mas juntas elas transformam um servidor confuso e obediente num servidor cético, que só vai aonde tem permissão explícita de ir. Trate qualquer funcionalidade que busca URLs como território hostil e projete-a assumindo que alguém vai tentar apontá-la para dentro.