* Você trabalha em uma **empresa de segurança cibernética**? Você quer ver sua **empresa anunciada no HackTricks**? ou você quer ter acesso à **última versão do PEASS 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)
* Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe seus truques de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
Se você está interessado em uma **carreira de hacking** e hackear o inquebrável - **estamos contratando!** (_fluência em polonês escrita e falada é necessária_).
Quando um navegador envia uma solicitação para um servidor web, o servidor web responde com uma resposta contendo tanto os cabeçalhos de resposta HTTP quanto o conteúdo real do site, ou seja, o corpo da resposta. Os cabeçalhos HTTP e a resposta HTML (o conteúdo do site) são separados por uma combinação específica de caracteres especiais, ou seja, um retorno de carro e uma alimentação de linha. Em resumo, eles também são conhecidos como CRLF.
O servidor web usa o CRLF para entender quando um novo cabeçalho HTTP começa e outro termina. O CRLF também pode indicar a um aplicativo da web ou usuário que uma nova linha começa em um arquivo ou em um bloco de texto. Os caracteres CRLF são uma mensagem padrão HTTP/1.1, portanto, são usados por qualquer tipo de servidor web, incluindo Apache, Microsoft IIS e todos os outros.\
Em um ataque de vulnerabilidade de injeção de CRLF, o invasor insere tanto o caractere de retorno de carro quanto o caractere de alimentação de linha na entrada do usuário para enganar o servidor, o aplicativo da web ou o usuário, fazendo-os pensar que um objeto foi encerrado e outro começou. Portanto, as sequências de CRLF não são caracteres maliciosos, no entanto, podem ser usadas com intenções maliciosas, para divisão de resposta HTTP, etc.
Em aplicativos da web, uma injeção de CRLF pode ter impactos graves, dependendo do que o aplicativo faz com itens individuais. Os impactos podem variar desde a divulgação de informações até a execução de código, uma vulnerabilidade de segurança direta do aplicativo da web. Na verdade, um ataque de injeção de CRLF pode ter repercussões muito sérias em um aplicativo da web, mesmo que nunca tenha sido listado no Top 10 da OWASP. Por exemplo, também é possível manipular arquivos de log em um painel de administração, como explicado no exemplo abaixo.
Se um invasor conseguir injetar os caracteres CRLF na solicitação HTTP, ele poderá alterar o fluxo de saída e falsificar as entradas de log. Ele pode alterar a resposta da aplicação web para algo como o exemplo abaixo:
O %0d e %0a são as formas codificadas em URL de CR e LF. Portanto, as entradas de log ficariam assim depois que o atacante inserisse esses caracteres e o aplicativo os exibisse:
Portanto, ao explorar uma vulnerabilidade de injeção CRLF, o atacante pode falsificar entradas no arquivo de log para ocultar suas próprias ações maliciosas. O atacante está literalmente sequestrando a página e modificando a resposta. Por exemplo, imagine um cenário em que o atacante possui a senha de administrador e executa o parâmetro restrictedaction, que só pode ser usado por um administrador.
O problema é que, se o administrador perceber que um IP desconhecido usou o parâmetro restrictedaction, ele notará que algo está errado. No entanto, como agora parece que o comando foi emitido pelo localhost (e, portanto, provavelmente por alguém que tem acesso ao servidor, como um administrador), não parece suspeito.
Toda a parte da consulta que começa com %0d%0a será tratada pelo servidor como um parâmetro. Depois disso, há outro & com o parâmetro restrictedaction, que será analisado pelo servidor como outro parâmetro. Efetivamente, esta seria a mesma consulta que:
Como o cabeçalho de uma resposta HTTP e seu corpo são separados por caracteres CRLF, um invasor pode tentar injetá-los. Uma combinação de CRLFCRLF informará ao navegador que o cabeçalho termina e o corpo começa. Isso significa que ele agora pode escrever dados dentro do corpo da resposta, onde o código HTML é armazenado. Isso pode levar a uma vulnerabilidade de Cross-site Scripting.
O valor do cabeçalho é definido por meio de um parâmetro GET chamado "name". Se não houver codificação de URL em vigor e o valor for refletido diretamente dentro do cabeçalho, pode ser possível para um atacante inserir a combinação mencionada acima de CRLFCRLF para informar ao navegador que o corpo da solicitação começa. Dessa forma, ele é capaz de inserir dados, como uma carga XSS, por exemplo:
Ao explorar uma injeção de CRLF, um invasor também pode inserir cabeçalhos HTTP que podem ser usados para derrotar mecanismos de segurança, como o filtro XSS de um navegador ou a mesma política de origem. Isso permite que o invasor obtenha informações sensíveis, como tokens CSRF. Ele também pode definir cookies que podem ser explorados ao fazer login da vítima na conta do invasor ou ao explorar vulnerabilidades de [cross-site scripting (XSS)](https://www.netsparker.com/blog/web-security/cross-site-scripting-xss/) de outra forma não exploráveis.
Se um invasor conseguir injetar os cabeçalhos HTTP que ativam o CORS (Compartilhamento de Recursos de Origem Cruzada), ele pode usar JavaScript para acessar recursos que são protegidos pela SOP (Política de Mesma Origem), que impede que sites de origens diferentes acessem uns aos outros.
Ao abusar da injeção de CRLF, você pode **criar uma nova solicitação HTTP e injetá-la**.\
Um bom exemplo pode ser feito usando o gadget de desserialização `SoapClient` em PHP. Essa classe é **vulnerável a CRLF** dentro do parâmetro `user_agent`, permitindo **inserir novos cabeçalhos e conteúdo do corpo**. No entanto, você também pode ser capaz de abusar dessa vulnerabilidade para **injetar uma nova solicitação HTTP**:
Em seguida, **especifique uma segunda solicitação**. Aqui você tem um [**ataque clássico** de **injeção de solicitação**](http-request-smuggling/) com **cabeçalhos/corpo extras** adicionados pelo servidor após a injeção.\
Para obter mais informações sobre essa técnica e problemas potenciais, [**verifique a fonte original**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning).
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 invasor pode abusar desse comportamento para **injetar novos comandos memcache**.
Por exemplo, na vulnerabilidade original descoberta, as chaves de cache eram usadas para retornar o IP e a porta a que um usuário deveria se conectar, e os invasores conseguiam **injetar comandos memcache** que **envenenariam** o **cache para enviar os detalhes das vítimas** (incluindo nomes de usuário e senhas) para os servidores do invasor:
Além disso, os pesquisadores também descobriram que poderiam dessincronizar as respostas do memcache para enviar os IPs e portas dos invasores para usuários cujo e-mail o invasor não conhecia:
**Para obter todas as informações, leia o** [**artigo original**](https://www.sonarsource.com/blog/zimbra-mail-stealing-clear-text-credentials-via-memcache-injection/)\*\*\*\*
O impacto das injeções de CRLF varia e inclui todos os impactos do Cross-site Scripting até a divulgação de informações. Também pode desativar certas restrições de segurança, como filtros XSS e a Política da Mesma Origem nos navegadores das vítimas, deixando-as suscetíveis a ataques maliciosos.
A melhor técnica de prevenção é não usar a entrada do usuário diretamente nos cabeçalhos de resposta. Se isso não for possível, você sempre deve usar uma função para codificar os caracteres especiais CRLF. Outra boa prática de segurança de aplicativos da web é atualizar sua linguagem de programação para uma versão que não permita a injeção de CR e LF dentro de funções que definem cabeçalhos HTTP.
Se você está interessado em uma **carreira de hacking** e hackear o inquebrável - **estamos contratando!** (_fluência em polonês escrita e falada é necessária_).
* Você trabalha em uma **empresa de cibersegurança**? Você quer ver sua **empresa anunciada no HackTricks**? Ou você quer ter acesso à **última versão do PEASS 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** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe seus truques de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e para o** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
