O que ainda passa pelo WAF: técnicas de bypass e como mitigar

A crença de que ter um WAF equivale a ter um perímetro de segurança é uma das mais caras que um time técnico pode sustentar. WAFs operam sobre representações de requisições — recebem bytes, interpretam segundo regras, decidem se o padrão corresponde a um ataque conhecido. O problema é que entre a interpretação do WAF e a interpretação da aplicação existe uma lacuna. Atacantes que conhecem essa lacuna a exploram com técnicas que existem há mais de uma década e continuam eficazes porque dependem de ambiguidades nos protocolos HTTP, não de falhas específicas do produto.

Como o double-encoding contorna a inspeção de payload

O URL encoding é um mecanismo legítimo do HTTP: ' (aspas simples) pode ser representado como %27. A maioria dos WAFs decodifica esse encoding antes de aplicar as regras — comportamento correto, já que a aplicação também vai decodificar.

O problema aparece com double-encoding. A string %2527 decodifica em dois passos: primeiro para %27, depois para '. Um WAF que faz apenas uma rodada de decodificação vê %27 e considera isso representação inofensiva de aspas simples. A aplicação, ao processar a requisição, faz sua própria decodificação e chega ao ' que o atacante queria introduzir. O payload chegou intacto.

Variações incluem encoding de espaços como %09 (tab em vez de espaço, equivalente em muitos contextos SQL) e mistura de encodings maiúsculos e minúsculos que alguns motores de regex não normalizam.

O Cloudflare aplica normalização de requisições antes de executar as regras — canonicalização que desfaz múltiplas camadas de encoding. Isso mitiga a maioria das técnicas de double-encoding, mas a eficácia depende da completude da normalização aplicada a cada campo inspecionado.

HTTP request smuggling: quando WAF e origem discordam

O HTTP/1.1 permite duas formas de indicar o tamanho do corpo de uma requisição: Content-Length, que especifica bytes exatos, e Transfer-Encoding: chunked, que envia o corpo em partes. Quando os dois headers estão presentes com valores conflitantes, o comportamento não é definido pelo protocolo — é definido pela implementação de cada servidor.

Um WAF que prioriza Content-Length e um servidor de origem que prioriza Transfer-Encoding vão discordar sobre onde termina uma requisição. Um atacante que controla esse conflito faz o WAF ver uma requisição inofensiva enquanto o servidor vê duas: a primeira legítima, a segunda com conteúdo malicioso que nunca passou pela inspeção. O HTTP request smuggling afetou múltiplos WAFs comerciais ao longo dos anos, exigindo correções específicas em cada um.

O Cloudflare normaliza as requisições antes de encaminhá-las ao origin. Para que o ataque funcione em uma arquitetura com Cloudflare, o servidor de origem precisaria estar recebendo conexões diretas — o que nos leva à mitigação mais importante e menos aplicada.

O que o Cloudflare genuinamente não pode proteger

Lógica de negócio é o caso mais claro. O WAF não tem contexto da sua aplicação: não sabe que uma transferência de R$ 50.000 em sequência rápida é suspeita, que o endpoint /api/export só deveria ser acessado com role admin, ou que discount_percentage não deveria aceitar valores negativos. Ataques de IDOR, manipulação de parâmetros de preço e abuso de fluxos de autenticação chegam como requisições válidas do ponto de vista do WAF, porque são. Essa proteção pertence à aplicação.

Zero-days são o segundo caso. Quando uma CVE crítica é publicada, o Cloudflare precisa de tempo para desenvolver uma assinatura. Esse intervalo pode ser de horas ou dias, e durante ele a aplicação está exposta mesmo com managed rulesets ativos. Regras de WAF não substituem patches de aplicação.

O bypass mais simples: acessar a origem diretamente

Todo o modelo de proteção do Cloudflare WAF depende de uma condição: o tráfego precisa passar pelo proxy para ser inspecionado. Registros DNS em modo DNS-only — a nuvem cinza no painel — não passam pelo proxy. Se o subdomínio que serve a aplicação está em DNS-only, o WAF simplesmente não existe para aquele tráfego.

A segunda condição é o IP de origem. Se um atacante descobre o IP real do servidor, pode conectar diretamente na porta 443 com o header Host correto e ignorar o edge por completo. Esse IP pode ter sido exposto via DNS histórico indexado pelo SecurityTrails antes da migração, transparency logs de certificados TLS emitidos diretamente para o IP, ou headers de e-mail enviados pelo servidor.

A mitigação é configurar o servidor de origem para aceitar conexões somente dos IP ranges do Cloudflare, publicados em https://www.cloudflare.com/ips/. Um security group ou regra de firewall que aceita apenas esses ranges elimina o contato direto com a origem. Para quem quer eliminar completamente portas abertas para a internet, o Cloudflare Tunnel estabelece uma conexão de saída do servidor para o edge sem expor nenhum IP.

O modelo de ameaça que precisa ser comunicado

WAF é eficaz contra uma categoria específica de atacantes: aqueles que usam ferramentas automatizadas de scan, não adaptam payloads, e buscam alvos fáceis em escala. Contra scanners de vulnerabilidade, scripts de exploit genérico e bots que testam injeção SQL e XSS em cada parâmetro que encontram, um WAF bem configurado bloqueia a grande maioria das tentativas sem esforço manual.

Contra um atacante dedicado que estuda a aplicação, mapeia os endpoints, e adapta os payloads especificamente para aquela stack — a proteção é diferente. As técnicas de bypass existem, algumas funcionam dependendo do estado da normalização e da especificidade das regras, e a origem ainda pode ser acessada diretamente se o IP vazar. O WAF compra tempo, reduz superfície de ataque automatizado, e adiciona uma camada de visibilidade sobre o que está sendo tentado — mas não substitui autenticação forte, validação de input na aplicação, patching de dependências, e controle de acesso granular no nível de negócio.