* 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**? Confira 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 do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do 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 suas técnicas 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).
Se você está interessado em **carreira de hacking** e hackear o impossível - **estamos contratando!** (_fluência em polonês escrito e falado é 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 informar 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.\
De [https://www.netsparker.com/blog/web-security/crlf-http-header/#](https://www.netsparker.com/blog/web-security/crlf-http-header/)
Em um ataque de vulnerabilidade de injeção de CRLF, o invasor insere os caracteres de retorno de carro e alimentação de linha na entrada do usuário para enganar o servidor, o aplicativo da web ou o usuário a pensar que um objeto foi encerrado e outro começou. Como tal, as sequências de CRLF não são caracteres maliciosos, no entanto, podem ser usadas para fins maliciosos, 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 graves 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, conforme 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 abaixo:
O %0d e o %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 a aplicação os exibisse:
Portanto, ao explorar uma vulnerabilidade de injeção CRLF, o invasor pode falsificar entradas no arquivo de log para obscurecer suas próprias ações maliciosas. O invasor está literalmente fazendo sequestro de página e modificando a resposta. Por exemplo, imagine um cenário em que o invasor tem a senha de administrador e executou 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, 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 único 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:
Uma vez que o cabeçalho de uma resposta HTTP e seu corpo são separados por caracteres CRLF, um atacante 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 invasor 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 carga útil XSS, por exemplo:
Ao explorar uma injeção CRLF, um invasor também pode inserir cabeçalhos HTTP que podem ser usados para derrotar mecanismos de segurança, como o filtro XSS do navegador ou a política de mesma origem. Isso permite que o invasor obtenha informações confidenciais, como tokens CSRF. Ele também pode definir cookies que podem ser explorados ao fazer login da vítima na conta do invasor ou explorando vulnerabilidades de script entre sites (XSS) de outra forma não exploráveis.
Se um invasor puder injetar os cabeçalhos HTTP que ativam o CORS (Compartilhamento de Recursos de Origem Cruzada), ele pode usar o JavaScript para acessar recursos que são protegidos pela política de mesma origem (SOP), que impede que sites de origens diferentes acessem uns aos outros.
Ao abusar da injeção 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ê pode até 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**](http-request-smuggling/) de **injeção de solicitação HTTP** com **cabeçalhos/corpo extras** adicionados pelo servidor após a injeção.\
Aqui estão duas das muitas opções para exploração entre usuários.
Para obter 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).
Se uma plataforma estiver **usando dados de uma solicitação HTTP sem sanitizá-los** para realizar **solicitações** a um servidor **memcache**, um invasor poderá 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 foram capazes de **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 à divulgação de informações. Também pode desativar certas restrições de segurança, como filtros XSS e a Política de Mesma Origem nos navegadores da vítima, deixando-os suscetíveis a ataques maliciosos.
A melhor técnica de prevenção é não usar a entrada do usuário diretamente dentro dos 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 CR e LF serem injetados dentro de funções que definem cabeçalhos HTTP.
Se você está interessado em **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 segurança cibernética**? Você quer ver sua **empresa anunciada no HackTricks**? ou quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Confira 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 do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do 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 suas técnicas 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).
