CRLF-Injection verstehen: Eine Sicherheitslücke in Webanwendungen und deren Entschärfung

Home » Cybersicherheit » Anwendungssicherheit » CRLF-Injection verstehen: Eine Sicherheitslücke in Webanwendungen und deren Entschärfung

CRLF-Injection (Carriage Return Line Feed) ist eine Sicherheitslücke in einer Webanwendung, die auftritt, wenn ein Angreifer bösartige CRLF-Zeichen in eine HTTP-Antwort einschleusen kann. Diese Sicherheitslücke kann zu verschiedenen Sicherheitsproblemen führen, wie z. B. HTTP-Header-Injection, HTTP-Response-Splitting, Sitzungsfixierung, Cross-Site-Scripting (XSS) und Cache-Poisoning.

Um die CRLF-Injektion zu verstehen, schlüsseln wir den Begriff auf:

Wagenrücklauf (CR):Es handelt sich um ein Steuerzeichen (ASCII-Code 13), das den Cursor anweist, zum Anfang der aktuellen Zeile zurückzukehren.

Zeilenvorschub (LF):Es handelt sich um ein Steuerzeichen (ASCII-Code 10), das den Cursor anweist, zur nächsten Zeile zu wechseln.

Im Kontext von HTTP bezieht sich CRLF auf die Folge von CR- und LF-Zeichen („\r\n“). Diese Zeichen werden zum Trennen von Zeilen im HTTP-Protokoll verwendet.

Die CRLF-Injection-Schwachstelle entsteht, wenn benutzergesteuerte Daten (Eingaben) nicht ordnungsgemäß bereinigt oder validiert werden, bevor sie zum Erstellen einer HTTP-Antwort verwendet werden. Angreifer nutzen diese Schwachstelle aus, indem sie CRLF-Zeichen in Benutzereingaben einschleusen, mit dem Ziel, die HTTP-Antwort zu manipulieren.

CRLF-Injection kann als Teil einer Schwachstellenkette verwendet werden, um verschiedene Sicherheitsprobleme auszunutzen. Hier sind einige häufige Schwachstellen in der Kette, die zusammen mit der CRLF-Injection ausgenutzt werden können:

Die CRLF-Injection kann mit anderen Schwachstellen kombiniert werden, etwa einer unzureichenden Eingabevalidierung oder einer unsicheren Verkettung von Benutzereingaben, um HTTP-Response-Splitting-Angriffe durchzuführen. Durch das Einfügen von CRLF-Zeichen kann ein Angreifer die Antwortheader manipulieren und die Antwort möglicherweise in mehrere Teile aufteilen, was zu verschiedenen Sicherheitsproblemen wie Cache-Poisoning, Sitzungsfixierung oder Cross-Site-Scripting (XSS) führt.

Beispiel:

Betrachten wir ein anderes Beispiel, bei dem das Codesegment die E-Mail-Adresse eines Benutzers aus einer HTTP-Anfrage liest und sie als Cookie-Header in einer HTTP-Antwort festlegt:

In diesem Beispiel nimmt die Anwendung die in der Anfrage übermittelte E-Mail-Adresse und legt sie als Cookie mit dem Namen „user_email“ in der HTTP-Antwort fest.

Angenommen, die E-Mail-Adresse „[email protected]“ wird in der Anfrage angegeben. Die HTTP-Antwort einschließlich dieses Cookies könnte wie folgt aussehen:

Diese Antwort behält ihre beabsichtigte Form bei, da die Eingabe („[email protected]“) eine gültige E-Mail-Adresse ohne schädliche Zeichen ist.

Betrachten wir nun, was passiert, wenn ein Angreifer eine bösartige E-Mail-Adresse mit CRLF-Zeichen übermittelt:

Der Wert für den Parameter „email“ ist „john.doe%40example.com%0d%0aSet-Cookie%3A+admin%3Dtrue%0d%0a“. Wenn die Anwendung diese Eingabe verarbeitet und das Cookie setzt, könnte die HTTP-Antwort wie folgt manipuliert werden

In diesem Fall fügte der Angreifer CRLF-Zeichen („%0d%0a“) in den E-Mail-Parameter ein, was zum Einfügen eines zusätzlichen „Set-Cookie“-Headers in die Antwort führte. Der Angreifer hat faktisch ein weiteres Cookie namens „admin“ mit dem Wert „true“ gesetzt. Dies könnte zur Rechteausweitung oder anderen sicherheitsrelevanten Angriffen genutzt werden.

CRLF-Injection kann als Sprungbrett für Cross-Site-Scripting-Angriffe genutzt werden. Durch das Einfügen von CRLF-Zeichen zur Manipulation der Antwort kann ein Angreifer bösartige Skripte einschleusen, die im Kontext anderer Benutzer ausgeführt werden können, was zu Sitzungsentführung, Datendiebstahl oder anderen Formen unbefugten Zugriffs führt.

Beispiel:

Lassen Sie eine Nutzlast erstellen, um CRLF zu Cross Site Scripting (XSS) zu eskalieren:

Bei der Durchführung eines VAPT (Vulnerability Assessment and Penetration Testing) für eine Webanwendung habe ich eine potenzielle CRLF-Schwachstelle (Carriage Return Line Feed) entdeckt. Hier finden Sie die Erklärung zur Erkennung und Ausnutzung der CRLF-Sicherheitslücke mit Proof of Concept:

Durch das Hinzufügen eines Kommentars werden alle unnötigen Überschriften und Inhalte kommentiert. Ein HTML-Kommentar wird verwendet, da die Antwort einen Content-Type:text/html-Header hat.

Nutzlast: (XSS über CRLF)

Bild 1: Anfrage und Antwort einer schädlichen URL

Bild 2: Durch Öffnen der schädlichen URL im Browser des Benutzers wird JavaScript erfolgreich ausgeführt.

Der grundlegende Ablauf zur Prüfung auf CRLF-Injection in einer Webanwendung ist wie folgt:

Der obige Prozess kann mithilfe der unten beschriebenen Kernvorlage automatisiert werden

Automatisierung: Nuclei-Vorlage zur Validierung grundlegender CRLF-Prüfungen:

%0d entspricht der hexadezimalen ASCII-Darstellung des Carriage Return (CR)-Zeichens (Dezimal 13).

%0a entspricht der hexadezimalen ASCII-Darstellung des Zeilenvorschubzeichens (LF) (dezimal 10).

Bei der URL-Codierung werden Zeichen, die für die Verwendung in einer URL nicht sicher sind, durch ein „%“ gefolgt von ihrer hexadezimalen ASCII-Darstellung ersetzt. Dies wird häufig beim Senden von Daten in URLs oder als Teil von Abfrageparametern verwendet.

\r steht für das Carriage Return (CR)-Zeichen.

\n steht für das Zeilenvorschubzeichen (LF).

In vielen Programmiersprachen werden Escape-Sequenzen verwendet, um Sonderzeichen darzustellen, die nicht einfach eingegeben oder direkt gedruckt werden können. „\r“ und „\n“ sind Escape-Sequenzen, die zur Darstellung der CR- bzw. LF-Zeichen verwendet werden. Diese Escape-Sequenzen werden häufig in Zeichenfolgenliteralen im Code verwendet, um Zeilenumbrüche oder andere Steuerzeichen anzugeben.

Bypass-Nutzlasten filtern:

%E5%98%8A: Dies ist eine Darstellung eines Zeichens mittels URL-Codierung. Es entspricht der UTF-8-Kodierung des Zeichens 嘊. In UTF-8 wird 嘊 durch die Bytes 0xE5 0x98 0x8A dargestellt.

%0A: Dies ist die Darstellung des Zeilenvorschubzeichens (LF) in der URL-Codierung. In ASCII hat LF den Hexadezimalwert 0x0A, was der Dezimalzahl 10 entspricht. Es stellt eine neue Zeile oder einen Zeilenumbruch im Text dar.

\u560a: Dies ist die Darstellung des Zeichens 嘊 mithilfe einer Unicode-Escape-Sequenz in Programmiersprachen. Der Unicode-Codepunkt von 嘊 ist U+560A, und die Escape-Sequenz \u wird verwendet, um Unicode-Zeichen in einem Zeichenfolgenliteral darzustellen.

%E5%98%8D: Dies ist eine weitere Darstellung eines Zeichens mithilfe der URL-Codierung. Es entspricht der UTF-8-Kodierung des Zeichens 嘍. In UTF-8 wird 嘍 durch die Bytes 0xE5 0x98 0x8D dargestellt.

%0D: Dies ist die Darstellung des Carriage Return (CR)-Zeichens in der URL-Codierung. In ASCII hat CR den Hexadezimalwert 0x0D, was der Dezimalzahl 13 entspricht. Es stellt einen Wagenrücklauf dar oder den Cursor, der sich an den Zeilenanfang bewegt.

\u560d: Dies ist die Darstellung des Zeichens 嘍 mithilfe einer Unicode-Escape-Sequenz in Programmiersprachen. Der Unicode-Codepunkt von 嘍 ist U+560D.

Erstellen wir eine Nutzlast, um CRLF zur offenen Umleitung zu eskalieren:

Um CRLF-Injection-Schwachstellen zu verhindern, ist es wichtig, sichere Codierungspraktiken zu befolgen, wie zum Beispiel:

https://owasp.org/www-community/vulnerabilities/CRLF_Injection

https://book.hacktricks.xyz/pentesting-web/crlf-0d-0a

Der Beitrag CRLF-Injection verstehen: Eine Sicherheitslücke und Schadensbegrenzung in Webanwendungen erschien zuerst auf WeSecureApp :: Simplifying Enterprise Security.

*** Dies ist ein syndizierter Blog des Security Bloggers Network von WeSecureApp :: Simplifying Enterprise Security, verfasst von Sekhar Poola. Lesen Sie den Originalbeitrag unter: https://wesecureapp.com/blog/understanding-crlf-injection-a-web-application-vulnerability-and-mitigation/