Qu’est-ce que le 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 un saut 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, il est donc utilisé par tout type de serveur Web, y compris Apache, Microsoft IIS et tous les autres.

Quelle est la vulnérabilité d’injection CRLF ?

Dans une attaque de vulnérabilité par injection CRLF, l’attaquant insère à la fois les caractères de retour chariot et de saut de ligne dans l’entrée utilisateur pour inciter le serveur, l’application Web ou l’utilisateur à penser qu’un objet est terminé et qu’un autre a démarré. En tant que telles, les séquences CRLF ne sont pas des caractères malveillants, mais elles peuvent être utilisées pour des intentions malveillantes, pour le fractionnement de réponses HTTP, etc.

Injection de CRLF dans les applications web

Dans les applications Web, une injection de CRLF peut avoir des impacts graves, en fonction de ce que l’application fait avec des éléments uniques. Les impacts peuvent aller de la divulgation d’informations à l’exécution de code, une vulnérabilité de sécurité des applications Web à impact direct. En fait, une attaque par 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 des 10 premiers OWASP. Par exemple, il est également possible de manipuler des 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 du chemin IP-Time-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 peut modifier le flux de sortie et simuler les entrées du journal. Il peut changer la réponse de l’application webs en quelque chose comme ci-dessous:

/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

Les %0d et %0a sont les formes codées par URL de CR et LF. Par conséquent, les entrées du journal ressembleraient à ceci après que l’attaquant ait inséré ces caractères et que l’application les affiche:

Chemin IP-Temps 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 simuler des entrées dans le fichier journal pour masquer 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 exécute 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 ait été émise par l’hôte local (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 restrictedactionqui sera analysé par le serveur comme un autre paramètre. Effectivement, ce serait la même requête que:

/index.php?page=home&restrictedaction=edit

Division de la réponse HTTP

Description

Étant donné que 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 de les injecter. 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 dans le corps de la réponse où le code HTML est stocké. Cela peut conduire à une vulnérabilité de script intersite.

Un exemple de division de réponse HTTP 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 peut être possible pour un attaquant d’insérer la combinaison de 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 que la charge utile XSS, par exemple:

?name=Bob%0d%0a%0d%0a<script>alert(document.domain)</script>

Ce qui précède affichera une fenêtre d’alerte dans le contexte du domaine attaqué.

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 vaincre les mécanismes de sécurité tels que le filtre XSS d’un navigateur ou la même stratégie 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 enregistrant la victime sur le compte de l’attaquant ou en exploitant des vulnérabilités de scripts intersites (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 (Cross Origin Resource Sharing), 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 d’origines différentes d’accéder les uns aux autres.

Impacts de la vulnérabilité de l’injection de CRLF

L’impact des injections de CRLF varie et inclut également tous les impacts des scripts inter-sites sur la divulgation d’informations. Il peut également désactiver certaines restrictions de sécurité telles que les filtres XSS et la même politique d’origine dans les navigateurs de la victime, les laissant vulnérables aux attaques malveillantes.

Comment empêcher les injections d’en-têtes CRLF / HTTP dans les applications Web

La meilleure technique de prévention consiste à ne pas utiliser les entrées des utilisateurs directement 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 en matière de sécurité des applications Web consiste à mettre à jour votre langage de programmation vers une version qui ne permet pas d’injecter CR et LF dans les fonctions qui définissent les en-têtes HTTP.

Tableau de classification et de gravité des vulnérabilités