Testar WAF com IA: mantenha execução e veredito fora da sugestão do modelo

A Cloudflare usou modelos de IA em um ambiente controlado para gerar variações de ataques que seu WAF já bloqueava.[12] O experimento cobriu 45 cenários e 1.107 tentativas, produziu 49 achados após triagem humana e levou a três alterações nas regras gerenciadas.[12] A contribuição mais aproveitável não é a geração de payloads: é a separação entre sugestão, execução e comprovação.

O que muda para quem desenvolve

Os modelos trabalharam em caixa-preta, sem acesso ao código, às regras ou aos sinais internos do WAF.[12] Um harness em Python executava requisições, preservava estado, impunha limites e coletava resultados; chamadas de modelo sugeriam mutações e analisavam respostas.[12] O controle de execução permanecia fora do modelo.[12]

Essa divisão oferece um desenho mais auditável. Minha recomendação é permitir criatividade na hipótese, mas exigir regras fixas para alvo, orçamento, identidade e armazenamento das evidências. O componente que sugere a próxima tentativa não deveria poder alterar essas restrições.

Um caso de SSRF ilustra a diferença entre sinal e prova: uma representação alternativa de endereço gerou redirecionamento em vez do bloqueio esperado, mas isso, isoladamente, não comprovava que o ataque alcançara o destino.[12] Uma resposta diferente merece investigação. Não merece automaticamente o rótulo de exploração bem-sucedida.

Como aplicar

Em uma aplicação de teste que você tenha autorização para avaliar, defina previamente uma propriedade de segurança e como ela será observada. Por exemplo: uma requisição não deve produzir acesso a um destino controlado fora da política estabelecida.

Depois, proponha um fluxo com funções separadas:

• O modelo sugere uma variação dentro de um formato permitido.
• O executor valida alvo, método, orçamento e escopo antes de enviar.
• O coletor registra entrada, resposta e observações do destino de teste.
• Um validador examina se houve o efeito proibido e se o caso permanece no escopo.
• Um revisor decide se o achado é reproduzível e útil para correção.

Esse roteiro é uma proposta de experimento, não um teste já realizado. Use destinos descartáveis, limites conservadores e interrupção previsível. Não use uma mudança de status HTTP como única evidência de impacto.

Se houver correção, repita o caso e execute também tráfego legítimo representativo. A meta é fechar a falha sem transformar o bloqueio indiscriminado em uma falsa melhoria de segurança.

Cuidados e limites

Na triagem descrita, os revisores verificavam alcance do alvo, caráter malicioso, ausência real de bloqueio, responsabilidade do WAF e possibilidade de reprodução segura.[12] Dos 49 achados relevantes, 48 envolviam injeção de comando ou SSRF.[12] Não trate esse recorte como distribuição geral de falhas em todos os WAFs.

As mudanças incluíram as detecções SSRF - Obfuscated Host e SSRF - Restricted Protocol, além de uma melhoria em SSRF - Cloud.[12] Isso descreve a ação da Cloudflare, não uma garantia de proteção integral da aplicação. Para seu produto, o requisito é produzir evidência verificável dentro do escopo, antes de recomendar qualquer alteração.

Fonte

[12] Fonte: InfoQ. Data/hora no feed: 07/10/2026 às 04:21:00.