O protocolo HTTP/1.1, utilizado desde o final dos anos 90, carrega uma falha estrutural grave: a separação frágil entre requisições. Essa fragilidade abre portas para ataques conhecidos como HTTP Request Smuggling (contrabando de requisições), capazes de comprometer credenciais de usuários e assumir o controle de sites inteiros.
Apesar de seis anos de tentativas de mitigação, a ameaça continua viva — e pior, muitas vezes mascarada por soluções que apenas escondem o problema. Grandes players como Akamai, Cloudflare e Netlify já foram impactados por vulnerabilidades críticas explorando exatamente essa fraqueza.
O que torna o HTTP/1.1 tão perigoso?
O HTTP/1.1 permite múltiplas formas de indicar o tamanho de uma mensagem (Content-Length, Transfer-Encoding, implícito zero, etc.). Essa flexibilidade, aliada ao fato de que proxies reversos frequentemente compartilham conexões entre diferentes usuários, cria cenários ideais para ataques de desincronização.Basta uma discrepância mínima na interpretação de cabeçalhos entre servidores para que um invasor insira requisições maliciosas no fluxo de outro usuário.
O resultado? Controle total de sessões, sequestro de páginas e até injeção de código em massa.
Por que as “correções” não resolvem?
Hoje, muitos servidores e CDNs dizem suportar HTTP/2, mas na prática convertem as requisições para HTTP/1.1 internamente. Isso anula a principal vantagem de segurança do HTTP/2 — um protocolo binário sem ambiguidades de comprimento de mensagem — e ainda adiciona novas formas de exploração.
Mitigações comuns, como regras de WAF baseadas em regex, até bloqueiam ataques conhecidos, mas não impedem variações novas ou criadas sob medida. A falsa sensação de segurança é o “endgame” perfeito para atacantes: tudo parece protegido, até que um ajuste sutil no ataque volte a funcionar.
Casos reais: quando milhões de sites ficaram vulneráveis
Um exemplo marcante foi a descoberta de um desincronismo interno na infraestrutura da Cloudflare, que expôs mais de 24 milhões de sites. A falha permitia redirecionar visitantes para páginas maliciosas, com potencial de comprometer bancos, lojas e serviços críticos.Outro caso, envolvendo a Akamai, resultou em 74 relatórios de vulnerabilidade e mais de US$ 220 mil em recompensas pagas.
Esses incidentes mostram que, com HTTP/1.1, vulnerabilidades podem surgir até “por acidente”, explorando interações inesperadas entre camadas de cache, proxies e servidores de backend.
Novas técnicas de ataque
Pesquisas recentes revelaram novas classes de exploração, como:
-
0.CL desync – ataques antes considerados “impossíveis” agora exploram respostas antecipadas do servidor para quebrar o impasse típico dessa técnica.
-
Expect-based desync – manipulação do cabeçalho Expect: 100-continue para causar comportamentos anômalos, vazamento de informações sensíveis e injeção de conteúdo.
-
Double desync – combinação de ataques para transformar falhas sutis em vetores de injeção massiva.
O uso criativo dessas técnicas já gerou mais de US$ 350 mil em recompensas em poucos meses, reforçando que essa não é uma ameaça teórica.
Por que migrar para HTTP/2 (ou superior) é crucial?
Embora HTTP/2 também tenha vulnerabilidades, a estrutura binária elimina a ambiguidade que torna o HTTP/1.1 tão explorável.Usar HTTP/2 “upstream” — ou seja, entre o proxy e o backend — reduz drasticamente a superfície de ataque. Isso exige que fornecedores e administradores:
-
Habilitem suporte completo a HTTP/2 nos servidores de origem.
-
Configurem proxies e balanceadores para manter HTTP/2 até o destino final.
-
Evitem rebaixamentos internos para HTTP/1.1.
Enquanto isso não acontece, é essencial aplicar medidas temporárias no HTTP/1.1:ativar validações rígidas, evitar servidores obscuros, desabilitar reutilização de conexões upstream e testar regularmente com ferramentas como o HTTP Request Smuggler.
Por que o HTTP/1.1 precisa “morrer”?
O problema não está em implementações mal feitas isoladas, mas no próprio design do protocolo. Pequenos bugs em HTTP/1.1 frequentemente têm impacto catastrófico, e a história mostra que mitigações pontuais não impedem novas variantes.
Se queremos uma web mais segura, precisamos abandonar o HTTP/1.1 como padrão entre sistemas críticos e adotar protocolos modernos que não carreguem essa falha estrutural.
Enquanto isso, cabe à comunidade de segurança continuar explorando, reportando e pressionando pela migração — porque, no ritmo atual, a próxima onda de ataques de desincronização não é uma questão de “se”, mas de “quando”.
O artigo "HTTP/1.1 must die: the desync endgame" foi escrito por James Kettle no site Port Swigger
Disponível em: https://portswigger.net/research/http1-must-die
