CRLF (%0D%0A) Injection
Last updated
Last updated
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
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, Belohnungen von bis zu $100.000 zu verdienen!
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 anzuzeigen. 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-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.
Betrachten Sie eine Protokolldatei in einem Admin-Panel, die das Format: IP - Zeit - Besuchter Pfad folgt. Ein typischer Eintrag könnte so aussehen:
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:
Hier repräsentieren %0d und %0a die URL-kodierten Formen von CR und LF. Nach dem Angriff würde das Protokoll irreführend anzeigen:
Der Angreifer tarnt somit seine böswilligen 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 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).
Die Anwendung setzt einen benutzerdefinierten Header wie folgt: X-Custom-Header: UserInput
Die Anwendung ruft den Wert für UserInput aus einem Abfrageparameter ab, sagen wir "user_input". In Szenarien, in denen es an ordnungsgemäßer Eingangsvalidierung und -kodierung mangelt, kann ein Angreifer eine Nutzlast erstellen, die die CRLF-Zeichenfolge enthält, gefolgt von bösartigem Inhalt.
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.
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.
Browser zu:
Und der Server antwortet mit dem Header:
Anderes Beispiel: (von https://www.acunetix.com/websitesecurity/crlf-injection/)
Sie können die Payload innerhalb des URL-Pfads senden, um die Antwort vom Server zu steuern (Beispiel von hier):
Check more examples in:
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, was potenziell zu unbefugtem Zugriff auf sensible Daten, wie CSRF-Token, oder zur Manipulation von Benutzersitzungen durch Cookie-Platzierung führen kann.
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.
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:
Für weitere Informationen zu dieser Technik und möglichen 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:
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:
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
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 ist ein Key-Value-Store, der ein Klartextprotokoll verwendet. Weitere Informationen finden Sie in:
Für die vollständigen Informationen lesen Sie die originale Ausarbeitung
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 (einschließlich Benutzernamen und Passwörter) 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:
Um die Risiken von CRLF (Carriage Return und Line Feed) oder HTTP-Header-Injektionen in Webanwendungen zu mindern, werden die folgenden Strategien empfohlen:
Vermeiden Sie direkte Benutzereingaben in Antwort-Headern: Der sicherste Ansatz besteht darin, Benutzereingaben nicht direkt in Antwort-Header zu integrieren.
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.
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.
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!
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
