Injection CRLF.

L'injection CRLF abuse de la signification spéciale de la séquence CR (0x0D) et LF (0x0A) qui termine les lignes dans de nombreux protocoles texte. Quand une application reflète une entrée non validée dans des en-têtes HTTP, des journaux, des commandes SMTP ou des requêtes LDAP, un attaquant peut injecter un couple CRLF suivi de contenu pour forger des en-têtes, fractionner des réponses, masquer des entrées de log ou contrebander des commandes. La faiblesse est répertoriée sous CWE-93 (neutralisation incorrecte des séquences CRLF) ; son dérivé spécifique aux en-têtes HTTP est CWE-113, qui couvre le fractionnement de requêtes/réponses HTTP.

Côté web, la forme la plus dommageable est le HTTP response splitting, décrit pour la première fois par Amit Klein de Sanctum dans un article de 2004. Comme le CRLF injecté ferme le bloc d'en-têtes, l'attaquant peut ajouter une seconde réponse entièrement sous son contrôle — empoisonnant les caches partagés, fixant des cookies arbitraires ou injectant du XSS dans un corps que le navigateur considère comme fiable. Le bug réapparaît dans les bibliothèques standard : CVE-2019-9740 permettait à des séquences CRLF présentes dans une URL passée à urllib.request.urlopen de Python d'injecter des en-têtes HTTP (voire des commandes Redis via la chaîne de requête), corrigée dans Python 2.7.17 et 3.5.10/3.6.10/3.7.4. Les défenses comprennent le rejet ou l'encodage en pourcentage des CR/LF dans toute entrée destinée aux en-têtes, l'usage d'API de haut niveau refusant les caractères de contrôle dans les valeurs d'en-tête, et des encodeurs de logs stricts et structurés plutôt que la concaténation brute.

flowchart TD
  A[Entrée utilisateur<br/>name=foo%0d%0aSet-Cookie: admin=true] --> B{Valider / retirer CR LF ?}
  B -->|Non| C[Entrée écrite brute dans l'en-tête]
  C --> D[Le CRLF termine l'en-tête courant]
  D --> E[En-tête ou corps contrôlé par l'attaquant]
  E --> F[Empoisonnement de cache / injection de cookie / XSS]
  B -->|Oui, rejeter CR LF| G[Réponse sûre]