CRLF-Injection.

CRLF-Injection missbraucht die besondere Bedeutung der Bytefolge CR (0x0D) und LF (0x0A), die in vielen Textprotokollen Zeilen abschließt. Wenn eine Anwendung ungeprüfte Benutzereingaben in HTTP-Antwortheader, Logeinträge, SMTP-Befehle oder LDAP-Anfragen einbettet, kann ein Angreifer ein CRLF-Paar samt weiterem Inhalt einschleusen, um Header zu fälschen, Antworten zu splitten, Logeinträge zu verschleiern oder Befehle zu schmuggeln. Die Schwäche ist als CWE-93 (unsachgemäße Neutralisierung von CRLF-Sequenzen) katalogisiert; ihr header-spezifischer Ableger ist CWE-113, der HTTP Request/Response Splitting abdeckt.

Im Web ist HTTP Response Splitting die gefährlichste Form, erstmals 2004 von Amit Klein (Sanctum) in einem Fachpapier beschrieben. Weil das eingeschleuste CRLF den Headerblock beendet, kann der Angreifer eine zweite, vollständig von ihm kontrollierte Antwort anhängen — er vergiftet Shared Caches, setzt beliebige Cookies oder schleust XSS in einen Körper ein, den der Browser als vertrauenswürdig behandelt. Der Fehler taucht immer wieder in Standardbibliotheken auf: CVE-2019-9740 erlaubte, dass CRLF-Sequenzen in einer an Pythons urllib.request.urlopen übergebenen URL HTTP-Header (über die Query sogar Redis-Befehle) einschleusten; behoben in Python 2.7.17 und 3.5.10/3.6.10/3.7.4. Schutz bieten das Ablehnen oder Prozent-Kodieren von CR/LF in jeder für Header bestimmten Eingabe, High-Level-APIs, die Steuerzeichen in Headerwerten verweigern, und strikte, strukturierte Log-Encoder statt roher Stringverkettung.

flowchart TD
  A[Benutzereingabe<br/>name=foo%0d%0aSet-Cookie: admin=true] --> B{CR LF validieren / entfernen?}
  B -->|Nein| C[Eingabe roh in Header geschrieben]
  C --> D[CRLF beendet aktuellen Header]
  D --> E[Vom Angreifer kontrollierter Header oder Körper]
  E --> F[Cache-Poisoning / Cookie-Injection / XSS]
  B -->|Ja, CR LF ablehnen| G[Sichere Antwort]