Injection CRLF

Qu’est-ce que l’injection de CRLF ?

L’injection CRLF est une vulnérabilité qui permet à un pirate malveillant d’injecter des caractères de retour chariot (CR) et de saut de ligne (LF) pour modifier le fonctionnement d’une application Web ou pour confondre son administrateur. Il existe deux principales utilisations malveillantes des injections CRLF : l’empoisonnement de journal (également appelé injection de journal, fractionnement de journal ou falsification de journal) et le fractionnement de réponse HTTP .

Les attaquants peuvent utiliser des injections CRLF pour escalader d’autres types de vulnérabilités, principalement les scripts intersites (XSS) . Les injections CRLF peuvent également être utilisées dans les applications Web pour influencer le comportement des e-mails – c’est ce qu’on appelle l’injection d’e-mails ( injection d’en-tête d’e-mail) .

Gravité:		grave dans de rares circonstances
Prévalence:		découvert rarement
Portée:		des applications Web
Impact technique :		escalade potentielle vers les scripts intersites
Conséquences dans le pire des cas :		compromis complet du système
Solution rapide:		utiliser le filtrage d’entrée utilisateur et l’encodage de sortie

Qu’est-ce que le CRLF ?

CR et LF sont des caractères spéciaux de la table ASCII (13 et 10). Ils sont également souvent appelés \r\n après les codes d’échappement de ces deux caractères ( \r = CR, \n = LF).

CR et LF sont utilisés (ensemble ou séparément) pour signifier la fin d’une ligne (EoL) dans les systèmes d’exploitation et les protocoles Internet, y compris HTTP. Windows utilise la combinaison CRLF, les systèmes d’exploitation comme Linux/UNIX et le macOS actuel n’utilisent que LF à cette fin, et l’ancien Mac OS n’utilisait que CR.

Qu’est-ce que l’empoisonnement des journaux ?

Dans une attaque d’empoisonnement des journaux basée sur l’injection CRLF, un pirate malveillant injecte des caractères CRLF dans les fichiers journaux du serveur Web pour confondre à la fois les systèmes d’analyse automatique des journaux et les administrateurs système parcourant les journaux manuellement.

Le format des journaux du serveur Web

De nombreux serveurs Web, tels qu’Apache, utilisent le format de journal commun NCSA (CLF). Le format des entrées Common Log Format est toujours le même :

host ident user date request status size

Par exemple:

233.252.0.123 - - [11/Oct/2022:11:34:50 +0100] "GET /example.php?id=3 HTTP/1.0" 200 452

Voici comment vous liriez cette entrée :

• 233.252.0.123est l’hôte – l’adresse IP d’où provient la demande.
• -est l’ identité RFC 1413 du client. Le tiret (-) signifie aucune donnée, ce qui est la valeur habituelle.
• -est l’ID utilisateur de la personne demandant le document. Le tiret (-) signifie aucune donnée, ce qui est la valeur habituelle (sauf s’il y a une authentification dans .htaccess ).
• [11/Oct/2022:11:34:50 +0100]est l’horodatage de la réception de la requête, généralement au format strftime : %d/%b/%Y:%H:%M:%S %z .
• "GET /example.php?id=3 HTTP/1.0"est la ligne de requête reçue du client et inclut la méthode HTTP ( GET), la ressource et les paramètres demandés ( /example.php?id=3) et le protocole ( HTTP/1.0).
• 200est le code d’état HTTP envoyé au client.
• 452est la taille de l’objet renvoyé en octets.

Un autre format standard est le format de journal combiné, qui est similaire mais avec quelques champs supplémentaires.

Exemple d’empoisonnement du journal

Imaginez que le client soit capable d’injecter des caractères CR et LF dans les requêtes envoyées au serveur Web www.example.com , et qu’il envoie la requête suivante :

https://www.example.com/example.php?id=3+HTTP%2F1.0%22+200+452%0D%0A
10.0.23.30+-+admin+%5B01%2FJan%2F2020%3A00%3A00%3A00+%2B0100%5D+%22GET+%2Fadmin.php%3Fuserid%3D12

La demande contient une fausse entrée de journal, donc lorsqu’elle est enregistrée, le fichier journal inclura une ligne supplémentaire :

233.252.0.123 - - [11/Oct/2022:11:34:50 +0100] "GET /example.php?id=3 HTTP/1.0" 200 452
10.0.23.30 - admin [01/Jan/2020:00:00:00 +0100] "GET /admin.php?userid=123 HTTP/1.0" 200 452

Les caractères soulignés représentent le contenu qui a été injecté à l’aide de l’injection CRLF ( %0D%0Asont des caractères CRLF codés).

Les outils de surveillance et les administrateurs analysant ce journal seraient confus par cette entrée étrange – il semble qu’un utilisateur administrateur authentifié ait demandé la ressource admin.php à un moment donné dans un passé lointain. Cette confusion pourrait permettre à l’attaquant de distraire l’administrateur et de retarder l’analyse du journal dans l’espoir de s’en tirer avec d’autres actions malveillantes qui seraient apparentes dans les entrées de journal ultérieures.

Qu’est-ce que le fractionnement de réponse HTTP ?

Dans une attaque par fractionnement de réponse HTTP, l’attaquant injecte des séquences CRLF dans une réponse HTTP pour modifier la façon dont le navigateur interprète les en-têtes HTTP et le corps de la requête. Les injections CRLF peuvent être utilisées pour ajouter du contenu malveillant au corps de la requête ou pour ajouter des en-têtes HTTP supplémentaires.

Comment le protocole HTTP utilise les caractères CRLF

Le protocole HTTP utilise la séquence de caractères CRLF de deux manières :

• Une seule séquence CRLF signifie qu’un en-tête se termine et qu’un autre commence.
• Une double séquence CRLF sépare tous les en-têtes du corps. Un corps de requête HTTP contient des données soumises par le client, tandis qu’un corps de réponse contient généralement des données de site Web renvoyées par le serveur.

De même, il existe deux manières pour les attaquants de modifier le trafic HTTP :

• Si l’attaquant insère un seul CRLF dans un en-tête de réponse HTTP, il peut ajouter un nouvel en-tête juste après cette nouvelle ligne. Par exemple, ils pourraient injecter un en-tête Location pour rediriger l’utilisateur vers un site Web contrôlé par un attaquant. Les cybercriminels peuvent utiliser cette technique, souvent appelée injection d’en-tête HTTP, pour le hameçonnage ou la dégradation.
• Si l’attaquant insère un double CRLF, il peut terminer prématurément les en-têtes HTTP et injecter du contenu malveillant avant le contenu réel du site Web. Le contenu injecté peut inclure du code JavaScript. L’attaquant peut même faire en sorte que le navigateur ignore tout le contenu légitime du site Web provenant du serveur Web. C’est ainsi que le fractionnement des réponses HTTP peut conduire à des scripts intersites.

Notez que les attaquants peuvent également injecter des en-têtes spéciaux pour empoisonner les proxies ou les caches Web, leur permettant de diffuser du contenu malveillant à de nombreux utilisateurs.

Exemple de fractionnement de réponse HTTP avec XSS

Dans l’exemple suivant, l’attaquant utilise le fractionnement de la réponse HTTP et l’injection d’en-tête HTTP pour envoyer une requête HTTP qui ajoute des en-têtes supplémentaires à la réponse HTTP, supprime les en-têtes prématurément et introduit une vulnérabilité de script intersite reflétée .

L’attaquant envoie la charge utile suivante dans un e-mail de phishing qui encourage l’utilisateur à cliquer sur un lien ou un bouton :

http://www.example.com/example.php?id=%0d%0aContent-Length:%200%0d%0a%0d%0a
HTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2025%0d%0a%0d%0a
%3Cscript%3Ealert(1)%3C/script%3E

La charge utile utilise l’injection CRLF pour diviser la réponse HTTP comme suit :

• http://www.example.com/example.php?id=– lancer une requête valide vers une page avec une vulnérabilité d’injection CRLF.
• %0d%0aContent-Length:%200– un faux en-tête de réponse HTTP de type Content-Length: 0. Cela amène le navigateur Web à traiter cette réponse comme terminée et à commencer à analyser la réponse suivante.

• %0d%0a%0d%0aHTTP/1.1%20200%20OK– la nouvelle réponse injectée commence ici par une double séquence CRLF suivie de HTTP/1.1 200 OK.
• %0d%0aContent-Type:%20text/html– un autre faux en-tête de réponse HTTP : Content-Type: text/html. Ceci est nécessaire pour que le navigateur traite ces données comme du contenu HTML.
• %0d%0aContent-Length:%2025– encore un autre faux en-tête de réponse HTTP : Content-Length: 25. Cela demande au navigateur d’analyser uniquement les 25 octets suivants et de rejeter toutes les données restantes comme indésirables, ce qui l’oblige à ignorer le contenu HTTP légitime envoyé par le serveur Web.
• %0d%0a%0d%0a%3Cscript%3Ealert(1)%3C/script%3E– une double séquence CRLF signale que les en-têtes sont terminés et que le corps de la réponse commence. Le contenu de la page injecté est , ce qui fait que le navigateur de l’utilisateur affiche une alerte au lieu de la page example.php réelle .

Conséquences potentielles d’une attaque par injection CRLF

L’impact des injections CRLF peut sembler limité, mais elles sont mentionnées dans la liste OWASP top 10 2021 de la sécurité des applications Web dans la section A03:2021-Injection . Les attaquants peuvent utiliser cette technique pour passer à des attaques malveillantes plus dangereuses telles que les scripts intersites, le piratage de pages, la défiguration entre utilisateurs, etc.

Les vulnérabilités de fractionnement de réponse HTTP permettent aux attaquants de modifier les en-têtes HTTP et de contourner des mécanismes de sécurité spécifiques, tels que les filtres XSS, les indicateurs de sécurité des cookies et les restrictions de la politique de même origine (SOP) . Cela ouvre la voie à certains types d’ attaques de l’homme du milieu (MITM) et à l’exploitation des vulnérabilités de falsification de requêtes intersites (CSRF) , qui, à leur tour, pourraient conduire à la divulgation d’informations sensibles ou plus.

Comment détecter les vulnérabilités d’injection CRLF ?

La meilleure façon de détecter les vulnérabilités d’injection CRLF dépend de si elles sont connues ou inconnues.

• Si vous utilisez uniquement des applications Web commerciales ou open source et que vous ne développez pas vos propres applications Web, il peut suffire d’identifier la version exacte de l’application que vous utilisez. Si la version identifiée est sensible aux injections CRLF, vous pouvez supposer que votre site Web ou votre application est vulnérable. Vous pouvez identifier la version manuellement ou utiliser un outil de sécurité approprié, tel qu’une solution d’analyse de la composition logicielle (SCA) .Si vous développez vos propres applications Web ou si vous souhaitez avoir la possibilité de trouver des vulnérabilités d’injection CRLF jusque-là inconnues (jours zéro) dans des applications connues, vous devez être en mesure d’exploiter avec succès la vulnérabilité pour être certain qu’elle existe. Cela nécessite soit d’effectuer des tests d’intrusion manuels avec l’aide de chercheurs en sécurité, soit d’utiliser un outil de test de sécurité (scanner) qui peut utiliser l’automatisation pour exploiter les vulnérabilités Web. 

Comment prévenir les vulnérabilités d’injection CRLF dans les applications Web ?

De nombreux frameworks Web empêchent aujourd’hui le fractionnement des réponses HTTP via l’injection CRLF en ne permettant pas l’inclusion de séquences CRLF dans les en-têtes HTTP. Si votre framework n’effectue pas automatiquement cette validation d’entrée, vous pouvez utiliser l’une des approches suivantes :

• Modifiez votre code afin de ne jamais utiliser de contenu fourni par l’utilisateur directement dans le flux HTTP. Il s’agit de la meilleure pratique pour prévenir non seulement les injections CRLF, mais également d’autres vulnérabilités d’injection, et est fortement recommandée.
• Désinfectez automatiquement les entrées de l’utilisateur et supprimez tous les caractères de retour à la ligne avant de transmettre le contenu dans l’en-tête HTTP.
• Encodez les données que vous transmettez dans les en-têtes HTTP. Cela brouillera les codes CR et LF si l’attaquant tente de les injecter.

Notez que vous ne pouvez pas empêcher l’empoisonnement du journal via l’injection CRLF au niveau de l’application simplement parce qu’il incombe au serveur Web de consigner les requêtes dans un format sécurisé. De même, les outils d’analyse de journaux doivent analyser les fichiers journaux, y compris ceux créés par les serveurs Web, d’une manière sécurisée qui ne permet pas de réussir des attaques d’empoisonnement ou de falsification de journaux.

Comment atténuer les attaques par injection CRLF ?

Étant donné que les injections CRLF ne sont pas dangereuses en elles-mêmes, mais peuvent ouvrir la voie à d’autres attaques, vous devez vous concentrer principalement sur l’atténuation de ces attaques de suivi, par exemple, les attaques de script intersite et l’empoisonnement du cache Web.

Pour une atténuation temporaire, vous pouvez vous fier aux règles WAF (pare-feu d’application Web) . Avec de telles règles, les utilisateurs ne pourront pas fournir d’entrées malveillantes à votre application Web, de sorte qu’aucun code malveillant ne s’exécutera dans leurs navigateurs. Cependant, étant donné que les pare-feu d’applications Web ne comprennent pas le contexte de votre application, ces règles peuvent être contournées par des attaquants et ne doivent jamais être traitées comme une solution permanente.