Uma falha limitada de injeção CRLF pode ser escalonada em um ataque severo de dessincronização HTTP, envenenando caches de CDN e entregando payloads de XSS para usuários em sites legítimos. O ataque, denominado Desincronização Alimentada por CRLF, começa quando um aplicativo lida incorretamente com caracteres codificados de retorno de carro e linha nova, comumente representados como %0d%0a.
O que mudou agora
Esses caracteres marcam novas linhas em mensagens HTTP. Se um servidor front-end os decodificar antes de encaminhar uma solicitação para um servidor backend, um atacante pode injetar novos cabeçalhos HTTP ou alterar a estrutura da solicitação upstream. Uma configuração arriscada envolve implantações do Nginx que colocam variáveis como $uri em diretivas proxy_pass diretamente. O Nginx pode normalizar e URL-decodificar o caminho antes de encaminhar upstream.
Vetor e exploração
Isso pode converter sequências CRLF codificadas em quebras de linha reais, permitindo injeção de cabeçalho de solicitação. A discrepância resultante na forma como diferentes camadas de infraestrutura interpretam a mesma solicitação pode criar uma condição de falsificação de solicitação HTTP, ou dessincronização. Em um ataque de dessincronização, um proxy front-end e um aplicativo backend discordam sobre onde termina uma solicitação HTTP e começa outra.
Evidências e limites
Os pesquisadores mostraram que o problema pode se tornar especialmente perigoso dentro da infraestrutura de CDN. Em um caso, o envenenamento da fila de resposta pareceu ocorrer na camada de CDN em vez de apenas dentro de um aplicativo alvo. Isso criou o risco de que solicitações e respostas de sites não relacionados hospedados na mesma infraestrutura de CDN pudessem se misturar.
Impacto e alcance
Tais incidentes podem expor cookies de sessão, tokens de autorização e outros dados sensíveis se o isolamento de conexão falhar. Um cenário mais impactante envolveu o envenenamento de uma página armazenada em cache de CDN e transformando o conteúdo armazenado em cache em um mecanismo de entrega de XSS. O recurso envenenado poderia então ser servido a usuários ativos, permitindo que JavaScript controlado pelo atacante fosse executado no contexto do navegador deles.
Medidas de mitigação recomendadas
As organizações devem tratar injeção CRLF e cabeçalho de solicitação como descobertas de alta gravidade, em vez de problemas menores de validação de entrada. Os defensores devem revisar regras de proxy reverso, evitar usar variáveis URI decodificadas em diretivas Nginx proxy_pass e return, e garantir que cada camada da pilha aplique regras de análise HTTP consistentes.
O que os CISOs devem fazer imediatamente
As equipes também devem testar o comportamento de CDN, balanceador de carga, proxy e servidor de origem juntos, porque as falhas mais graves surgem de diferenças de analisador entre essas camadas. Mover tráfego upstream para HTTP/2, onde for prático, isolar conexões backend, rejeitar caracteres de controle codificados cedo e testar regularmente a falsificação de solicitação pode reduzir significativamente a exposição.