A Microsoft publicou a biblioteca AntiSSRF, componente de código aberto sob licença MIT que valida URLs e bloqueia pedidos para endereços internos, prevenindo ataques de Server-Side Request Forgery em aplicações .NET e Node.js. A ferramenta foi desenhada como componente drop-in, que se encaixa no código existente com esforço mínimo de adoção.

Pontos-chave

  • Biblioteca open-source da Microsoft, licenciada sob MIT e mantida no GitHub.
  • Protege aplicações .NET (via NuGet) e Node.js (via npm, pacote @microsoft/antissrf).
  • Age como agente que valida todos os pedidos HTTP antes de deixá-los sair.
  • Bloqueia ligações a IPs internos, privados e sensíveis, mesmo após redirecionamentos.
  • Companhão de testes — Dusseldorf — gera payloads dinâmicos para validar defesas.

Como funciona a proteção

O AntiSSRF assume uma premissa dura: qualquer entrada externa é não confiável. URLs fornecidas por utilizadores, dados de webhooks, identificadores de recursos que são concatenados em pedidos — tudo passa pela validação. A biblioteca expõe um agente HTTP que intercepta cada pedido de saída, resolve o nome de host para endereço IP e recusa ligações a redes privadas, locais ou sensíveis.

O bloqueio cobre faixas tradicionais como 127.0.0.0/8 e 10.0.0.0/8, mas também redes de metadados de nuvem, como o 169.254.169.254 da AWS e equivalentes no Azure e GCP. Esta última classe é frequentemente explorada em fugas reais, que já atingiram produtos como o Exchange Server com PoC público. A abordagem do AntiSSRF visa fechar esse vetor no código.

Por que o SSRF preocupa

Server-Side Request Forgery transforma o próprio servidor da vítima em ponte para recursos internos. Um atacante envia um URL manipulado, o servidor faz o pedido, e o conteúdo sensível — credenciais em endpoints de metadados, painéis de administração, serviços internos — volta para o atacante. As consequências podem ir até execução remota de código, roubo de tokens de autenticação e disruption de serviços críticos. O custo médio de um incidente grave deste tipo ultrapassa frequentemente sete dígitos, entre resposta técnica, notificações regulatórias e perda de reputação.

A OWASP lista SSRF entre as vulnerabilidades web mais críticas. A CWE-918 documenta o padrão, e ferramentas de varredura como o Burp Suite têm módulos dedicados à sua exploração. A diferença é que a maioria das defesas depende do programador escrever validação manual, com intervalos IP a esquecer ou regras a falhar em edge cases de DNS rebinding. Técnicas como DNS rebinding, IPv6-mapped IPv4 e representações decimais de endereços contornam frequentemente listas negras mal construídas.

Adoção em .NET e Node.js

No ecossistema .NET, a instalação passa pelo pacote NuGet Microsoft.Security.AntiSSRF, compatível com .NET Framework e .NET Core. Em Node.js, o pacote @microsoft/antissrf pode ser importado como middleware ou como wrapper em volta do cliente HTTP. A documentação oficial inclui um guia de quick start para cada plataforma, com exemplos de substituição direta do HttpClient em C# e do fetch nativo em Node.js 18 e superiores.

A biblioteca expõe políticas configuráveis — AntiSSRFPolicy — que permitem afinar listas de permitidos, comportamento perante redirecionamentos e regimes de registo. Esta flexibilidade acomoda serviços legados que precisam de chamar endpoints internos legítimos, sem desligar a proteção global. A política pode, por exemplo, permitir ligações a um serviço interno específico, mantendo o bloqueio de todas as outras faixas privadas. O registo integrado facilita auditoria posterior, registando cada pedido rejeitado com o motivo técnico.

Como a Microsoft testa

A Microsoft acompanha o AntiSSRF com Dusseldorf, ferramenta open-source que gera payloads dinâmicos de SSRF e valida se as defesas reagem corretamente. Esta bateria de testes faz parte do fluxo interno de qualidade antes de qualquer release. O código é “exaustivamente testado”, segundo a descrição oficial — uma linguagem invulgar na documentação de bibliotecas da empresa. A Microsoft convida também contribuições externas, com guia de contribuição, política de segurança e código de conduta publicados no repositório.

Esse rigor responde a uma crítica recorrente ao ecossistema Microsoft, sobretudo depois de episódios como a falha SharePoint explorada ativamente em 2026, em que a empresa foi acusada de subestimar a gravidade. Com a AntiSSRF, a Microsoft aposta em código defensivo que pode ser auditado por qualquer equipa. A licença MIT permite uso comercial, modificação e redistribuição sem restrições relevantes, abrindo porta a adoção em produtos proprietários.

O que fazer agora

Equipes de desenvolvimento devem mapear todos os pontos do código onde pedidos HTTP são construídos a partir de entrada externa — formulários, parâmetros de query, webhooks, configurações editáveis. Em cada um desses pontos, substituir o cliente HTTP nativo pelo agente AntiSSRF elimina a maior parte dos vetores clássicos. Combine a adoção com Dusseldorf em ambiente de testes, para confirmar que payloads conhecidos são rejeitados. Mantenha a biblioteca atualizada, já que a Microsoft publica correções sempre que surgem novas técnicas de evasão documentadas pela comunidade. O repositório oficial está em github.com/microsoft/AntiSSRF, com documentação completa e exemplos de políticas personalizadas para diversos cenários de produção.

A prevenção de SSRF insere-se numa estratégia mais ampla de segurança. Combinada com análise estática de código e monitorização de CVEs activos, a biblioteca AntiSSRF completa uma estratégia de defesa em profundidade.