mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/pentesting-web/crlf-0d-0a.md'] to fr
This commit is contained in:
Translator
parent
89b65f048d
commit
74fc3a642a
@ -4,11 +4,11 @@
|
||||
|
||||
### 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.
|
||||
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éciales 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.
|
||||
|
||||
### CRLF Injection Vulnerability
|
||||
|
||||
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.
|
||||
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 la réponse HTTP et à d'autres activités malveillantes.
|
||||
|
||||
### Example: CRLF Injection in a Log File
|
||||
|
||||
@ -42,14 +42,14 @@ HTTP Response Splitting est une vulnérabilité de sécurité qui survient lorsq
|
||||
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<script>alert('XSS')</script>`
|
||||
- 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.
|
||||
- Dans cette URL, `%0d%0a%0d%0a` est la forme encodée en URL de CRLFCRLF. Cela trompe le serveur en lui faisant insérer une séquence CRLF, amenant le serveur à traiter 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, conduisant à 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
|
||||
|
||||
From [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)
|
||||
Depuis [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)
|
||||
|
||||
Browser to:
|
||||
Navigateur vers :
|
||||
```
|
||||
/%0d%0aLocation:%20http://myweb.com
|
||||
```
|
||||
@ -63,7 +63,7 @@ http://www.example.com/somepage.php?page=%0d%0aContent-Length:%200%0d%0a%0d%0aHT
|
||||
```
|
||||
#### Dans le chemin URL
|
||||
|
||||
Vous pouvez envoyer la charge utile **dans le chemin URL** pour contrôler la **réponse** du serveur (exemple de [ici](https://hackerone.com/reports/192667)):
|
||||
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
|
||||
@ -76,15 +76,15 @@ https://github.com/EdOverflow/bugbounty-cheatsheet/blob/master/cheatsheets/crlf.
|
||||
|
||||
### 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), pouvant mener à 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.
|
||||
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 le SOP (Same-Origin Policy), pouvant mener à 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.
|
||||
Un attaquant peut injecter des en-têtes HTTP pour activer CORS (Cross-Origin Resource Sharing), contournant les restrictions imposées par le 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 une nouvelle requête HTTP entièrement. Ci-dessous un exemple PHP démontrant cette exploitation :
|
||||
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 complètement 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';
|
||||
@ -131,7 +131,7 @@ Après cela, une deuxième requête peut être spécifiée. Ce scénario impliqu
|
||||
|
||||
### Injection Memcache
|
||||
|
||||
Memcache est un **magasin de clés-valeurs qui utilise un protocole en texte clair**. Plus d'infos dans :
|
||||
Memcache est un **store clé-valeur qui utilise un protocole en texte clair**. Plus d'infos dans :
|
||||
|
||||
{{#ref}}
|
||||
../network-services-pentesting/11211-memcache/
|
||||
@ -139,22 +139,22 @@ Memcache est un **magasin de clés-valeurs qui utilise un protocole en texte cla
|
||||
|
||||
**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**.
|
||||
Si une plateforme prend **des données d'une requête HTTP et les utilise sans les assainir** pour effectuer **des requêtes** à 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 :
|
||||
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 **empoisonneraient** le **cache pour envoyer les détails des victimes** (noms d'utilisateur et mots de passe inclus) aux serveurs de l'attaquant :
|
||||
|
||||
<figure><img src="../images/image (659).png" alt="https://assets-eu-01.kc-usercontent.com/d0f02280-9dfb-0116-f970-137d713003b6/ba72cd16-2ca0-447b-aa70-5cde302a0b88/body-578d9f9f-1977-4e34-841c-ad870492328f_10.png?w=1322&h=178&auto=format&fit=crop"><figcaption></figcaption></figure>
|
||||
|
||||
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 :
|
||||
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'email l'attaquant ne connaissait pas :
|
||||
|
||||
<figure><img src="../images/image (637).png" alt="https://assets-eu-01.kc-usercontent.com/d0f02280-9dfb-0116-f970-137d713003b6/c6c1f3c4-d244-4bd9-93f7-2c88f139acfa/body-3f9ceeb9-3d6b-4867-a23f-e0e50a46a2e9_14.png?w=1322&h=506&auto=format&fit=crop"><figcaption></figcaption></figure>
|
||||
|
||||
### 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 :
|
||||
Pour atténuer les risques d'injections CRLF (Carriage Return and 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 des entrées fournies par l'utilisateur directement 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.
|
||||
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'employer 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
|
||||
@ -181,20 +181,57 @@ Pour atténuer les risques d'injections CRLF (Carriage Return et Line Feed) ou d
|
||||
• %E5%98%BC = %3C = \u563c (<)
|
||||
• Payload = %E5%98%8A%E5%98%8DSet-Cookie:%20test
|
||||
```
|
||||
### Vulnérabilités Récentes (2023 – 2025)
|
||||
|
||||
Les dernières années ont produit plusieurs bugs d'injection CRLF/HTTP à fort impact dans des composants largement utilisés côté serveur et client. Reproduire et étudier ces bugs localement est un excellent moyen de comprendre les modèles d'exploitation dans le monde réel.
|
||||
|
||||
| Année | Composant | CVE / Avis | Cause racine | Point fort du PoC |
|
||||
|-------|-----------|------------|--------------|-------------------|
|
||||
| 2024 | RestSharp (≥110.0.0 <110.2.0) | **CVE-2024-45302** | L'assistant `AddHeader()` ne nettoyait pas CR/LF, permettant la construction de plusieurs en-têtes de requête lorsque RestSharp est utilisé comme client HTTP dans des services back-end. Les systèmes en aval pouvaient être contraints à SSRF ou au request smuggling. | `client.AddHeader("X-Foo","bar%0d%0aHost:evil")` |
|
||||
| 2024 | Refit (≤ 7.2.101) | **CVE-2024-51501** | Les attributs d'en-tête sur les méthodes d'interface étaient copiés textuellement dans la requête. En intégrant `%0d%0a`, les attaquants pouvaient ajouter des en-têtes arbitraires ou même une seconde requête lorsque Refit était utilisé par des tâches de travail côté serveur. | `[Headers("X: a%0d%0aContent-Length:0%0d%0a%0d%0aGET /admin HTTP/1.1")]` |
|
||||
| 2023 | Tableau de bord Apache APISIX | **GHSA-4h3j-f5x9-r6x3** | Le paramètre `redirect` fourni par l'utilisateur était renvoyé dans un en-tête `Location:` sans encodage, permettant une redirection ouverte + un empoisonnement de cache. | `/login?redirect=%0d%0aContent-Type:text/html%0d%0a%0d%0a<script>alert(1)</script>` |
|
||||
|
||||
Ces bugs sont importants car ils sont déclenchés **à l'intérieur du code au niveau de l'application** et pas seulement à la périphérie du serveur web. Tout composant interne qui effectue des requêtes HTTP ou définit des en-têtes de réponse doit donc appliquer un filtrage CR/LF.
|
||||
|
||||
### Contournements Avancés de Unicode / Caractères de Contrôle
|
||||
|
||||
Les piles WAF/rewrite modernes suppriment souvent les `\r`/`\n` littéraux mais oublient d'autres caractères que de nombreux back-ends traitent comme des terminators de ligne. Lorsque CRLF est filtré, essayez :
|
||||
|
||||
* `%E2%80%A8` (`U+2028` – SÉPARATEUR DE LIGNE)
|
||||
* `%E2%80%A9` (`U+2029` – SÉPARATEUR DE PARAGRAPHE)
|
||||
* `%C2%85` (`U+0085` – LIGNE SUIVANTE)
|
||||
|
||||
Certaines frameworks Java, Python et Go convertissent ces caractères en `\n` lors de l'analyse des en-têtes (voir la recherche Praetorian de 2023). Combinez-les avec des charges utiles classiques :
|
||||
```
|
||||
/%0A%E2%80%A8Set-Cookie:%20admin=true
|
||||
```
|
||||
Si le filtre normalise d'abord UTF-8, le caractère de contrôle est transformé en un saut de ligne régulier et l'en-tête injecté est accepté.
|
||||
|
||||
### Évasion WAF via le truc de `Content-Encoding` dupliqué (2023)
|
||||
|
||||
Les chercheurs de Praetorian ont également montré qu'en injectant :
|
||||
```
|
||||
%0d%0aContent-Encoding:%20identity%0d%0aContent-Length:%2030%0d%0a
|
||||
```
|
||||
dans un en-tête réfléchi, les navigateurs ignoreront le corps fourni par le serveur et rendront le HTML fourni par l'attaquant qui suit, donnant un XSS stocké même lorsque le contenu de l'application est inerte. Parce que `Content-Encoding: identity` est autorisé par la RFC 9110, de nombreux reverse-proxies le transmettent sans changement.
|
||||
|
||||
## Outils Automatiques
|
||||
|
||||
- [https://github.com/Raghavd3v/CRLFsuite](https://github.com/Raghavd3v/CRLFsuite)
|
||||
- [https://github.com/dwisiswant0/crlfuzz](https://github.com/dwisiswant0/crlfuzz)
|
||||
* [CRLFsuite](https://github.com/Raghavd3v/CRLFsuite) – scanner actif rapide écrit en Go.
|
||||
* [crlfuzz](https://github.com/dwisiswant0/crlfuzz) – fuzzer basé sur une liste de mots qui prend en charge les charges utiles de nouvelle ligne Unicode.
|
||||
* [crlfix](https://github.com/glebarez/crlfix) – utilitaire 2024 qui corrige les requêtes HTTP générées par des programmes Go et peut être utilisé de manière autonome pour tester des services internes.
|
||||
|
||||
## 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)
|
||||
- [carlospolop/Auto_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/)
|
||||
- [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/)
|
||||
- [https://nvd.nist.gov/vuln/detail/CVE-2024-45302](https://nvd.nist.gov/vuln/detail/CVE-2024-45302)
|
||||
- [https://security.praetorian.com/blog/2023-unicode-newlines-bypass/](https://security.praetorian.com/blog/2023-unicode-newlines-bypass/)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user