O Server-Side Request Forgery (SSRF) é uma vulnerabilidade de segurança web que permite a um invasor induzir o servidor de uma aplicação a fazer requisições HTTP arbitrárias para domínios ou IPs escolhidos pelo hacker. Em vez de o ataque partir da máquina do criminoso, ele manipula o servidor alvo para que este ataque a si mesmo, burle firewalls, acesse sistemas internos protegidos ou vaze dados sensíveis de serviços em nuvem.
Principais Aprendizados
- O SSRF transforma o servidor da vítima em uma "marionete" para atacar redes internas que, de outra forma, não estariam acessíveis pela internet.
- É uma das falhas mais críticas da atualidade, impulsionada pela adoção em massa de serviços em nuvem (como AWS, Azure e GCP) e suas APIs de metadados.
- A mitigação eficaz exige a validação rigorosa de URLs (allowlisting), segmentação de rede e o bloqueio de esquemas de requisição não utilizados (como file:// ou gopher://).
O que é SSRF (Server-Side Request Forgery)?
Para entender o SSRF, precisamos olhar para como as aplicações modernas funcionam. É muito comum que um site precise buscar dados em outros servidores. Por exemplo, uma aplicação pode pedir que você forneça a URL de uma imagem para usá-la como foto de perfil, ou um sistema pode buscar taxas de câmbio em uma API externa.
A falha ocorre quando a aplicação web busca esse recurso remoto sem validar ou sanitizar adequadamente a URL fornecida pelo usuário. O invasor pode alterar a URL para apontar para um servidor interno da empresa. Como essa vulnerabilidade se tornou frequente e devastadora, ela ganhou um destaque especial na lista do OWASP Top 10, o principal documento mundial de conscientização sobre segurança web.
Por que o SSRF é tão perigoso? (O Bypass de Firewall)
Normalmente, as empresas protegem seus bancos de dados e painéis administrativos colocando-os em uma rede interna, atrás de firewalls rigorosos. Um hacker na internet não consegue acessar o IP `192.168.0.10` diretamente. No entanto, o servidor web público da empresa tem permissão para acessar essa rede interna.
Ao explorar o SSRF, o atacante usa o servidor web como um "cavalo de Troia". O firewall vê a requisição vindo do próprio servidor web confiável e a permite. Durante um pentest interno, os especialistas avaliam exatamente o tamanho do estrago que um invasor pode causar após conseguir esse tipo de acesso inicial.
Segundo a OWASP Foundation, a incidência e a gravidade do SSRF estão aumentando rapidamente devido à complexidade das arquiteturas modernas e à proliferação de microsserviços que se comunicam constantemente entre si.
O perigo em ambientes de Nuvem (Cloud Metadata)
O SSRF atingiu um novo nível de criticidade com a computação em nuvem. Provedores como AWS, Google Cloud e Azure possuem serviços de metadados de instância (IMDS). Na AWS, por exemplo, qualquer servidor (EC2) pode consultar o IP mágico `169.254.169.254` para obter informações sobre si mesmo, incluindo credenciais temporárias de alto privilégio.
Se um invasor encontra um SSRF em uma aplicação hospedada na AWS, ele pode forçar o servidor a acessar `http://169.254.169.254/latest/meta-data/iam/security-credentials/` e roubar as chaves de acesso à nuvem. A documentação técnica da PortSwigger Web Security Academy detalha exaustivamente como essa técnica foi responsável por megavazamentos de dados corporativos na última década.
Tipos de SSRF: Básico vs. Blind
Existem basicamente duas formas de o SSRF se manifestar, e entender a diferença é vital para proteger aplicações web modernas:
- SSRF Básico (In-band): O invasor envia a requisição forjada e a resposta do servidor interno é devolvida diretamente na tela da aplicação web. O atacante consegue ler arquivos ou ver o painel de sistemas internos.
- Blind SSRF: O ataque ocorre no backend, mas o invasor não vê o resultado na tela. A aplicação apenas confirma que a requisição foi feita (ou demora mais para responder). O invasor usa isso para varrer IPs internos (port scanning) ou enviar comandos cegos para serviços vulneráveis na rede (como o Redis).
Como blindar seu servidor contra o SSRF
A defesa contra o SSRF exige uma abordagem em camadas. O objetivo é reduzir drasticamente a superfície de ataque da aplicação. Aqui estão as melhores práticas de mitigação:
- Use Allowlisting (Lista de Permissões): Nunca confie na entrada do usuário. Em vez de tentar bloquear URLs ruins (blocklist), crie uma lista estrita apenas dos domínios ou IPs que a aplicação tem permissão legítima para acessar.
- Desative Esquemas Não Utilizados: Se a sua aplicação só precisa buscar recursos via `http://` ou `https://`, desative o suporte a esquemas perigosos no nível do código, como `file://` (que lê arquivos locais do servidor), `gopher://` ou `dict://`.
- Segmentação de Rede (Zero Trust): O servidor web não deve ter acesso irrestrito à rede interna. Configure firewalls internos para que o servidor web só possa se comunicar com os bancos de dados ou APIs estritamente necessários.
- Proteção de Metadados da Nuvem: Se usar AWS, migre para o IMDSv2, que exige um token de sessão específico para acessar os metadados, inviabilizando a maioria dos ataques SSRF simples.
Perguntas Frequentes
Qual a diferença entre SSRF e CSRF?
Embora os nomes sejam parecidos, os alvos são diferentes. No SSRF, o atacante manipula o servidor para fazer requisições não autorizadas. Já para entender o que é CSRF (Cross-Site Request Forgery), é preciso saber que ele manipula o navegador do usuário, forçando a vítima a executar ações indesejadas em um site onde ela já está logada.
Um Firewall de Aplicação Web (WAF) bloqueia ataques SSRF?
Um WAF pode ajudar a bloquear tentativas óbvias de SSRF, como requisições apontando para `localhost`, `127.0.0.1` ou o IP de metadados da AWS. No entanto, invasores frequentemente usam técnicas avançadas de ofuscação de IP e redirecionamentos DNS para burlar o WAF. A defesa real deve ser implementada no código da aplicação (allowlisting).
Como hackers descobrem vulnerabilidades SSRF?
Eles interagem com funcionalidades que processam URLs, importam arquivos, geram PDFs a partir de HTML ou buscam dados externos. Os invasores inserem URLs controladas por eles (como um servidor Burp Collaborator) nas entradas da aplicação. Se o servidor do invasor receber um ping (requisição HTTP ou DNS) da aplicação alvo, o SSRF está confirmado.
0 Comentários