* Você trabalha em uma **empresa de cibersegurança**? Quer ver sua **empresa anunciada no HackTricks**? ou quer ter acesso à **versão mais recente 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 de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* Adquira o [**material 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** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
Se você está interessado em **carreira de hacking** e em hackear o inquebrável - **estamos contratando!** (_polonês fluente escrito e falado necessário_).
Quando um navegador envia uma solicitação a um servidor web, o servidor responde com uma resposta contendo tanto os cabeçalhos de resposta HTTP quanto o conteúdo 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, nomeadamente um retorno de carro e uma alimentação de linha. 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 uma aplicação 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 atacante insere os caracteres de retorno de carro e alimentação de linha na entrada do usuário para enganar o servidor, a aplicação web ou o usuário, fazendo-os pensar que um objeto terminou e outro começou. Assim, as sequências de CRLF não são caracteres maliciosos, no entanto, podem ser usados com intenções maliciosas, para divisão de resposta HTTP, etc.
Em aplicações web, uma injeção de CRLF pode ter impactos graves, dependendo do que a aplicação faz com itens individuais. Os impactos podem variar desde a divulgação de informações até a execução de código, uma vulnerabilidade direta na segurança da aplicação web. Na verdade, um ataque de injeção de CRLF pode ter repercussões muito sérias em uma aplicação web, embora nunca tenha sido listado na lista OWASP Top 10. Por exemplo, também é possível manipular arquivos de log em um painel administrativo, conforme explicado no exemplo abaixo.
Se um atacante conseguir injetar os caracteres CRLF na requisição HTTP, ele poderá alterar o fluxo de saída e falsificar as entradas de log. Ele pode mudar a resposta da aplicação web para algo como o abaixo:
Os %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 ofuscar suas próprias ações maliciosas. O atacante está literalmente realizando sequestro de página e modificando a resposta. Por exemplo, imagine um cenário onde o atacante tem a senha de admin e executou o parâmetro restrictedaction, que só pode ser usado por um admin.
O problema é que se o administrador notar que um IP desconhecido usou o parâmetro restrictedaction, perceberá 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 admin), isso 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 restricted action que será interpretado pelo servidor como outro parâmetro. Efetivamente, essa seria a mesma consulta como:
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 indicará ao navegador que o cabeçalho terminou e o corpo começou. Isso significa que ele agora é capaz de 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 um parâmetro get chamado "name". Se não houver codificação de URL em vigor e o valor for diretamente refletido dentro do cabeçalho, pode ser possível para um atacante inserir a combinação mencionada de CRLFCRLF para informar ao navegador que o corpo da solicitação começa. Dessa forma, ele pode inserir dados como payload XSS, por exemplo:
Ao explorar uma injeção CRLF, um atacante 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 política de mesma origem (same-origin-policy). Isso permite que o atacante obtenha informações sensíveis como tokens CSRF. Ele também pode configurar cookies que podem ser explorados ao fazer o login da vítima na conta do atacante ou ao explorar vulnerabilidades de cross-site scripting (XSS) que de outra forma seriam inexploráveis.
Se um atacante consegue injetar os cabeçalhos HTTP que ativam o CORS (Cross Origin Resource Sharing), ele pode usar javascript para acessar recursos que de outra forma seriam protegidos pela SOP (Same Origin Policy), que impede que sites de origens diferentes acessem uns aos outros.
Abusando da injeção CRLF, você pode **criar uma nova requisição HTTP e injetá-la**.\
Um bom exemplo pode ser feito usando o gadget de desserialização `SoapClient` em PHP. Esta classe é **vulnerável ao CRLF** dentro do parâmetro `user_agent`, permitindo **inserir novos cabeçalhos e conteúdo no corpo**. No entanto, você pode até ser capaz de abusar dessa vulnerabilidade para **injetar uma nova requisição HTTP:**
Então, **especifique uma segunda requisição**. Aqui você tem um **clássico** [**request smuggling**](http-request-smuggling/) com **cabeçalhos/corpo extra** anexados pelo servidor após a injeção.\
Para mais informações sobre esta técnica e problemas potenciais [**consulte a fonte original**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning).
Se uma plataforma está tomando **dados de uma requisição HTTP e os utilizando sem sanitização** para realizar **requisições** a um servidor **memcache**, um atacante poderia abusar desse comportamento para **injetar novos comandos memcache**.
Por exemplo, na vulnerabilidade originalmente descoberta, chaves de cache eram usadas para retornar o IP e porta que um usuário deveria se conectar, e atacantes conseguiram **injetar comandos memcache** que iriam **envenenar** o **cache para enviar os detalhes das vítimas** (incluindo nomes de usuário e senhas) para os servidores do atacante:
Além disso, pesquisadores também descobriram que eles poderiam dessincronizar as respostas do memcache para enviar o IP e portas dos atacantes para usuários cujo email o atacante não conhecia:
O impacto das injeções CRLF varia e também 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 de Mesma Origem nos navegadores das vítimas, deixando-os suscetíveis a ataques maliciosos.
A melhor técnica de prevenção é não usar diretamente a entrada dos usuários dentro dos cabeçalhos de resposta. Se isso não for possível, você deve sempre usar uma função para codificar os caracteres especiais CRLF. Outra boa prática de segurança em aplicações web é atualizar sua linguagem de programação para uma versão que não permita que CR e LF sejam injetados dentro de funções que definem cabeçalhos HTTP.
Se você tem interesse em **carreira de hacking** e em hackear o inquebrável - **estamos contratando!** (_é necessário polonês fluente, escrito e falado_).
* Você trabalha em uma **empresa de cibersegurança**? Quer ver sua **empresa anunciada no HackTricks**? ou quer ter acesso à **versão mais recente 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 de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* Adquira o [**material 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 seus truques de hacking enviando PRs para o repositório** [**hacktricks**](https://github.com/carlospolop/hacktricks) **e** [**hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
