<summary><strong>Aprenda hacking AWS do zero ao herói com</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe seus truques de hacking enviando PRs para os** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.
**Dica de recompensa por bugs**: **inscreva-se** no **Intigriti**, uma plataforma de **bug bounty premium criada por hackers, para hackers**! Junte-se a nós em [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) hoje e comece a ganhar recompensas de até **$100,000**!
Carriage Return (CR) e Line Feed (LF), conhecidos coletivamente como CRLF, são sequências de caracteres especiais usadas no protocolo HTTP para denotar o final 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.
A injeção de CRLF envolve a inserção de caracteres CR e LF na entrada fornecida pelo usuário. Essa ação faz com que o servidor, aplicativo ou usuário interprete a sequência injetada como o final de uma resposta e o início de outra. Embora esses caracteres não sejam inerentemente prejudiciais, seu uso indevido pode levar a divisão de respostas HTTP e outras atividades maliciosas.
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 de log em:
O atacante assim encobre suas atividades maliciosas fazendo parecer que o localhost (uma entidade normalmente 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`
A Divisão de Resposta HTTP é 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, Retorno de Carro (CR) seguido de Alimentação de Linha (LF), coletivamente denominado como CRLF. Se um atacante conseguir inserir uma sequência CRLF em um cabeçalho de resposta, eles podem manipular efetivamente o conteúdo da resposta subsequente. Esse tipo de manipulação pode levar a problemas de segurança graves, especialmente Cross-site Scripting (XSS).
2. A aplicação busca o valor para `UserInput` de um parâmetro de consulta, digamos "user\_input". Em cenários sem 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 da 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, resultando em uma estrutura de resposta não intencional onde o script malicioso é interpretado pelo navegador como parte do corpo da resposta.
De [https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62](https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62)
Você pode enviar o payload **dentro do caminho do URL** para controlar a **resposta** do servidor (exemplo de [aqui](https://hackerone.com/reports/192667)):
A Injeção de Cabeçalho HTTP, frequentemente explorada através da injeção de CRLF (Carriage Return and Line Feed), permite que os atacantes insiram cabeçalhos HTTP. Isso pode minar mecanismos de segurança, como filtros XSS (Cross-Site Scripting) ou a SOP (Same-Origin Policy), potencialmente levando a acesso não autorizado a dados sensíveis, como tokens CSRF, ou à manipulação de sessões de usuário através da inserção de cookies.
Um atacante pode injetar cabeçalhos HTTP para habilitar o 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.
A injeção de 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 no 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:
Para mais informações sobre essa técnica e possíveis problemas [**verifique a fonte original**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning).
Depois, pode ser especificada uma segunda solicitação. Esse cenário geralmente envolve [HTTP request smuggling](http-request-smuggling/), uma técnica onde cabeçalhos extras ou elementos de corpo adicionados pelo servidor pós-injeção podem levar a várias explorações de segurança.
1.**Injeção de Prefixo Malicioso**: Este método envolve envenenar a próxima solicitação do usuário ou um cache da web especificando um prefixo malicioso. Um exemplo disso é:
2.**Criando um Prefixo para Envenenamento da Fila de Respostas**: Esta abordagem envolve criar um prefixo que, quando combinado com lixo final, forma uma segunda solicitação completa. Isso pode acionar o envenenamento da fila de respostas. Um exemplo é:
**Para obter todas as informações, leia o** [**artigo original**](https://www.sonarsource.com/blog/zimbra-mail-stealing-clear-text-credentials-via-memcache-injection/)
Se uma plataforma está **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 original descoberta, chaves de cache eram usadas para retornar o IP e a porta a que um usuário deveria se conectar, e os atacantes foram capazes de **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 dos atacantes:
Além disso, os pesquisadores também descobriram que poderiam dessincronizar as respostas do memcache para enviar os IPs e portas dos atacantes para usuários cujos e-mails o atacante não conhecia:
Para mitigar os riscos de Injeções de CRLF (Carriage Return e Line Feed) ou Cabeçalhos HTTP em aplicações web, as seguintes estratégias são recomendadas:
1.**Evitar Entrada Direta do Usuário nos Cabeçalhos de Resposta:** A abordagem mais segura é abster-se de incorporar 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 de CRLF.
3.**Atualizar a 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 naturalmente impeça a injeção de caracteres CR e LF dentro de funções encarregadas de definir cabeçalhos HTTP.
**Dica de recompensa por bugs**: **inscreva-se** na **Intigriti**, uma plataforma premium de **bug bounty criada por hackers, para hackers**! Junte-se a nós em [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) hoje e comece a ganhar recompensas de até **$100,000**!
<summary><strong>Aprenda hacking na AWS do zero ao herói com</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe seus truques de hacking enviando PRs para os repositórios do** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
