diff --git a/src/pentesting-web/crlf-0d-0a.md b/src/pentesting-web/crlf-0d-0a.md
index 5af59b559..752878fc1 100644
--- a/src/pentesting-web/crlf-0d-0a.md
+++ b/src/pentesting-web/crlf-0d-0a.md
@@ -6,11 +6,11 @@
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.
-### CRLF Injection Vulnerability
+### 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 respostas HTTP e outras atividades maliciosas.
+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.
-### Example: CRLF Injection in a Log File
+### Exemplo: Injeção CRLF em um Arquivo de Log
[Example from here](https://www.invicti.com/blog/web-security/crlf-http-header/)
@@ -18,7 +18,7 @@ Considere um arquivo de log em um painel de administração que segue o formato:
```
123.123.123.123 - 08:15 - /index.php?page=home
```
-Um atacante pode explorar uma injeção 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:
+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
```
@@ -35,7 +35,7 @@ O atacante, assim, encobre suas atividades maliciosas fazendo parecer que o loca
#### 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 por Line Feed (LF), coletivamente denominado 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).
+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
@@ -76,11 +76,11 @@ https://github.com/EdOverflow/bugbounty-cheatsheet/blob/master/cheatsheets/crlf.
### Injeção de Cabeçalho HTTP
-A Injeção de Cabeçalho HTTP, frequentemente explorada através da injeção CRLF (Carriage Return and Line Feed), permite que atacantes insiram cabeçalhos HTTP. Isso pode comprometer mecanismos de segurança, como filtros XSS (Cross-Site Scripting) ou a SOP (Same-Origin Policy), potencialmente levando 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.
+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 pela SOP. Essa violação permite que scripts de origens maliciosas interajam com recursos de uma origem diferente, potencialmente acessando dados protegidos.
+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
@@ -117,7 +117,7 @@ Você pode injetar cabeçalhos essenciais para garantir que o **back-end mantenh
```
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](http-request-smuggling/), uma técnica onde cabeçalhos extras ou elementos de corpo adicionados pelo servidor após a injeção podem levar a várias explorações de segurança.
+Depois, uma segunda solicitação pode ser especificada. Este cenário geralmente envolve [HTTP request smuggling](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:**
@@ -137,15 +137,15 @@ Memcache é um **armazenamento de chave-valor que usa um protocolo de texto clar
../network-services-pentesting/11211-memcache/
{{#endref}}
-**Para informações completas, leia o**[ **relato original**](https://www.sonarsource.com/blog/zimbra-mail-stealing-clear-text-credentials-via-memcache-injection/)
+**Para informações completas, leia o**[ **artigo original**](https://www.sonarsource.com/blog/zimbra-mail-stealing-clear-text-credentials-via-memcache-injection/)
-Se uma plataforma estiver **pegando 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**.
+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 poderiam 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:
+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:
@@ -181,20 +181,57 @@ Para mitigar os riscos de injeções CRLF (Carriage Return e Line Feed) ou HTTP
• %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.
+
+| Ano | Componente | CVE / Aviso | Causa raiz | Destaque do PoC |
+|-----|------------|-------------|------------|------------------|
+| 2024 | RestSharp (≥110.0.0 <110.2.0) | **CVE-2024-45302** | O helper `AddHeader()` não sanitizava CR/LF, permitindo a construção de múltiplos cabeçalhos de requisição quando o RestSharp é usado como um cliente HTTP dentro de serviços de back-end. Sistemas downstream poderiam ser forçados a SSRF ou request smuggling. | `client.AddHeader("X-Foo","bar%0d%0aHost:evil")` |
+| 2024 | Refit (≤ 7.2.101) | **CVE-2024-51501** | Atributos de cabeçalho em métodos de interface foram copiados verbatim na requisição. Ao embutir `%0d%0a`, atacantes poderiam adicionar cabeçalhos arbitrários ou até mesmo uma segunda requisição quando o Refit era usado por trabalhos de servidor. | `[Headers("X: a%0d%0aContent-Length:0%0d%0a%0d%0aGET /admin HTTP/1.1")]` |
+| 2023 | Apache APISIX Dashboard | **GHSA-4h3j-f5x9-r6x3** | O parâmetro `redirect` fornecido pelo usuário foi ecoado em um cabeçalho `Location:` sem codificação, permitindo redirecionamento aberto + envenenamento de cache. | `/login?redirect=%0d%0aContent-Type:text/html%0d%0a%0d%0a` |
+
+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
-- [https://github.com/Raghavd3v/CRLFsuite](https://github.com/Raghavd3v/CRLFsuite)
-- [https://github.com/dwisiswant0/crlfuzz](https://github.com/dwisiswant0/crlfuzz)
+* [CRLFsuite](https://github.com/Raghavd3v/CRLFsuite) – scanner ativo rápido escrito em Go.
+* [crlfuzz](https://github.com/dwisiswant0/crlfuzz) – fuzzer baseado em lista de palavras que suporta payloads de nova linha Unicode.
+* [crlfix](https://github.com/glebarez/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
-- [https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/crlf.txt](https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/crlf.txt)
+- [carlospolop/Auto_Wordlists – crlf.txt](https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/crlf.txt)
## Referências
-- [**https://www.invicti.com/blog/web-security/crlf-http-header/**](https://www.invicti.com/blog/web-security/crlf-http-header/)
-- [**https://www.acunetix.com/websitesecurity/crlf-injection/**](https://www.acunetix.com/websitesecurity/crlf-injection/)
-- [**https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning)
-- [**https://www.netsparker.com/blog/web-security/crlf-http-header/**](https://www.netsparker.com/blog/web-security/crlf-http-header/)
+- [https://www.invicti.com/blog/web-security/crlf-http-header/](https://www.invicti.com/blog/web-security/crlf-http-header/)
+- [https://www.acunetix.com/websitesecurity/crlf-injection/](https://www.acunetix.com/websitesecurity/crlf-injection/)
+- [https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning)
+- [https://www.netsparker.com/blog/web-security/crlf-http-header/](https://www.netsparker.com/blog/web-security/crlf-http-header/)
+- [https://nvd.nist.gov/vuln/detail/CVE-2024-45302](https://nvd.nist.gov/vuln/detail/CVE-2024-45302)
+- [https://security.praetorian.com/blog/2023-unicode-newlines-bypass/](https://security.praetorian.com/blog/2023-unicode-newlines-bypass/)
{{#include ../banners/hacktricks-training.md}}
.png)
.png)