CRLF est l’acronyme utilisé pour désigner le retour chariot (\r) d’alimentation en ligne (\n). Comme on peut le remarquer à partir des symboles entre parenthèses, « Retour chariot” fait référence à la fin d’une ligne, et « Entrée de ligne” fait référence à la nouvelle ligne. Par conséquent, CR et LF sont utilisés pour désigner le point final d’une ligne. Lorsqu’un utilisateur demande du contenu sur un site Web, le serveur renvoie le contenu du site Web avec les en-têtes HTTP. Les en-têtes et le contenu sont séparés par une combinaison définie de CR et LF. C’est à cause de CRLF qu’un serveur sait où commence ou se termine un nouvel en-tête. Une vulnérabilité d’injection de flux de ligne de retour Chariot (CRLF) est un type d’injection Côté serveur qui se produit lorsqu’un attaquant insère les caractères CRLF dans un champ de saisie pour tromper le serveur en lui faisant croire qu’un objet s’est terminé et qu’un nouvel objet a commencé. Cela se produit lorsque l’application Web n’assainit pas les entrées utilisateur pour les caractères CRLF. Il a une cote de gravité moyenne (P3 selon la VRT de Bugcrowd).

L’attaque par injection CRLF a deux cas d’utilisation les plus importants :

• Fractionnement des journaux: L’attaquant insère un caractère de fin de ligne et une ligne supplémentaire pour falsifier les entrées du fichier journal afin de tromper les administrateurs système en masquant d’autres attaques.
• Division de la réponse HTTP: L’injection CRLF est utilisée pour ajouter des en-têtes HTTP à la réponse HTTP et, par exemple, effectuer une attaque XSS qui conduit à la divulgation d’informations.

Exemple :

Une simple requête GET peut être conçue comme suit :

GET /%0d%0aSet-Cookie:CRLFInjection=PreritPathak HTTP/1.1

Remarque: %0d et %0a sont des formes codées de \r et \n respectivement. Si l’application Web est vulnérable, un attaquant pourra installer un cookie sur le site Web.

Impacts de l’injection CRLF

L’injection CRLF permet à l’attaquant de définir de faux cookies, de voler des jetons CSRF, de divulguer des informations utilisateur en injectant un script (XSS) et d’effectuer une variété d’autres attaques. Il permet également aux attaquants de désactiver &contourner les mesures de sécurité telles que les filtres XSS &Même politique d’origine (SOP), les rendant sensibles aux attaques suivantes :

1. XSS ou Cross Site Scripting
XSS ou Cross Site Scripting est une vulnérabilité de sécurité qui permet à un attaquant d’injecter du code JavaScript malveillant dans l’application Web. Les requêtes GET suivantes sont conçues dans une tentative d’injection CRLF en chaîne avec XSS.
En déclenchant une alerte contenant des informations utilisateur sensibles

www.target.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

En Désactivant la protection XSS

www.target.com/%0d%0aContent-Length:35%0d%0aX-XSS-Protection:0%0d%0a%0d%0a23

2. Injection de cookies
Le fractionnement de la réponse HTTP permet à un attaquant de définir des cookies malveillants sur le navigateur de la victime. Dans la plupart des cas, la demande GET suivante entraînera une redirection 307 et la victime sera donc redirigée vers target.com &l’URL ne contiendra pas le paramètre Set-Cookie. En arrière-plan cependant, le cookie sera défini.

www.target.com/%0d%0aSet-Cookie:CRLFInjection=MaliciousCookieSet

3. Attaques de phishing
Un attaquant peut définir l’en-tête de localisation qui redirigerait la victime vers le site Web maléfique. Ce site Web peut être développé pour ressembler au site Web cible et lorsque la victime saisit ses informations d’identification, elles seront envoyées à l’attaquant. L’en-tête de localisation peut être défini comme suit :

GET /%0d%0aLocation:%20https://evil.com HTTP/1.1

4. Fixation de session
Similaire à l’attaque par injection de cookies, l’attaquant définit ici l’ID de session d’un utilisateur sur une valeur particulière. Ce lien est envoyé à la victime et lorsque la victime se connecte à l’aide de cette session, l’attaquant peut également se connecter en utilisant le même ID de session.

www.target.com/%0d%0aSet-Cookie:session_id=942....

5. Injection d’en-tête HTTP
Un attaquant peut tirer parti de l’injection CRLF pour injecter des en-têtes HTTP dans une application afin de vaincre les mécanismes de sécurité tels que les filtres XSS ou la même stratégie d’origine.

www.target.com/%0d%0aHackersHeader:NewHeader

Les en-têtes d’activation de CORS (Cross Origin Resource Sharing) peuvent être injectés &l’attaquant peut utiliser JavaScript pour accéder à des ressources sensibles 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.
6. Empoisonnement du cache Web
L’empoisonnement du cache Web est une technique grâce à laquelle un attaquant peut servir du contenu empoisonné en manipulant un cache Web. Afin d’exploiter avec succès ce problème, un attaquant devrait empoisonner le proxy de mise en cache du site Web vulnérable, les syndicateurs, les réseaux de diffusion de contenu (CDN) ou d’autres mécanismes de mise en cache entre le client et le serveur. Après un empoisonnement réussi du cache Web, la victime n’aura aucune idée du contenu malveillant qui lui est servi par le cache. Voici un exemple de la façon dont un attaquant pourrait potentiellement exploiter une injection d’en-tête d’hôte (en utilisant CRLF) en empoisonnant un cache Web.

Pour la demande suivante:

$ telnet www.target.com 80Trying x.x.x.x...Connected to www.target.com.Escape character is '^]'.GET /%0d%0aX-Forwarded-Host:hacker.com HTTP/1.1 //or HostHost: target.com

Il y aurait la réponse suivante:

HTTP/1.1 200 OK

Cas d’utilisation divers :

1. Injection d’un faux en-tête de réponse HTTP:

Content-Length: 10

Maintenant, le navigateur Web n’analysera que les 10 octets suivants.
2. Injection d’un faux en-tête de réponse HTTP :

Content-Length: 0

Ceci est traité comme une réponse terminée &les navigateurs Web commencent à analyser une nouvelle réponse.

Atténuations:

Un développeur doit garder à l’esprit les éléments suivants pour éviter l’injection de CRLF :

• Désinfection des entrées utilisateur.
• Encodez les caractères CR& LF (\r, \n) de sorte que même lorsqu’ils sont fournis, ils ne sont pas reconnus par le serveur.
• Validez l’entrée utilisateur avant qu’elle n’atteigne les en-têtes de réponse (par exemple en utilisant des méthodes telles que StringEscapeUtils.L’évasion ()).
• Un en-tête inutile doit être désactivé.
  Le tableau suivant met l’accent sur la gravité de l’injection de CRLF selon diverses normes de l’industrie: