Was ist CRLF?

Wenn ein Browser eine Anfrage an einen Webserver sendet, antwortet der Webserver mit einer Antwort, die sowohl die HTTP-Antwortheader als auch den tatsächlichen Inhalt der Website, dh den Antworttext, enthält. Die HTTP-Header und die HTML-Antwort (der Inhalt der Website) werden durch eine bestimmte Kombination von Sonderzeichen getrennt, nämlich einen Wagenrücklauf und einen Zeilenvorschub. Kurz gesagt sind sie auch als CRLF bekannt.

Der Webserver verwendet die CRLF, um zu verstehen, wann ein neuer HTTP-Header beginnt und ein anderer endet. Die CRLF kann einer Webanwendung oder einem Benutzer auch mitteilen, dass eine neue Zeile in einer Datei oder in einem Textblock beginnt. Die CRLF-Zeichen sind eine Standard-HTTP / 1.1-Nachricht und werden daher von jedem Webservertyp verwendet, einschließlich Apache, Microsoft IIS und allen anderen.

Was ist die CRLF Injection Schwachstelle?

Bei einem CRLF-Injection-Angriff fügt der Angreifer sowohl die Wagenrücklauf- als auch die Zeilenvorschubzeichen in die Benutzereingabe ein, um den Server, die Webanwendung oder den Benutzer dazu zu bringen, zu glauben, dass ein Objekt beendet und ein anderes gestartet wurde. Als solche sind die CRLF-Sequenzen keine böswilligen Zeichen, sie können jedoch für böswillige Aktionen, für die Aufteilung von HTTP-Antworten usw. verwendet werden.

CRLF-Injektion in Webanwendungen

In Webanwendungen kann eine CRLF-Injektion schwerwiegende Auswirkungen haben, je nachdem, was die Anwendung mit einzelnen Elementen ausführt. Die Auswirkungen können von der Offenlegung von Informationen bis zur Codeausführung reichen, was sich direkt auf die Sicherheitsanfälligkeit von Webanwendungen auswirkt. Tatsächlich kann ein CRLF-Injection-Angriff sehr schwerwiegende Auswirkungen auf eine Webanwendung haben, obwohl sie nie in der OWASP Top 10-Liste aufgeführt wurde. Beispielsweise ist es auch möglich, Protokolldateien in einem Admin-Panel zu bearbeiten, wie im folgenden Beispiel erläutert.

Ein Beispiel für die CRLF-Injektion in eine Protokolldatei

Stellen Sie sich eine Protokolldatei in einem Admin-Panel mit dem Ausgabestreammuster des IP – Time – Visited-Pfads vor, z. B. das folgende:

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

Wenn ein Angreifer in der Lage ist, die CRLF-Zeichen in die HTTP-Anforderung einzufügen, kann er den Ausgabestream ändern und die Protokolleinträge fälschen. Er kann die Antwort von der Webs-Anwendung in etwas wie das Folgende ändern:

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

Die%0d und %0a sind die URL-codierten Formen von CR und LF. Daher würden die Protokolleinträge so aussehen, nachdem der Angreifer diese Zeichen eingefügt hat und die Anwendung sie anzeigt:

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

Daher kann der Angreifer durch Ausnutzung einer CRLF-Injection-Sicherheitsanfälligkeit Einträge in der Protokolldatei fälschen, um seine eigenen böswilligen Aktionen zu verschleiern. Der Angreifer führt buchstäblich Seiten-Hijacking durch und ändert die Antwort. Stellen Sie sich beispielsweise ein Szenario vor, in dem der Angreifer über das Administratorkennwort verfügt und den Parameter restrictedaction ausgeführt hat, der nur von einem Administrator verwendet werden kann.

Das Problem ist, dass, wenn der Administrator bemerkt, dass eine unbekannte IP den restrictedaction Parameter verwendet, wird feststellen, dass etwas nicht stimmt. Da es jetzt jedoch so aussieht, als ob der Befehl vom localhost (und daher wahrscheinlich von jemandem, der Zugriff auf den Server hat, wie ein Administrator) ausgegeben wurde, sieht er nicht verdächtig aus.

Der gesamte Teil der Abfrage, der mit %0d%0a beginnt, wird vom Server als ein Parameter behandelt. Danach gibt es ein weiteres & mit dem Parameter restrictedaction, das vom Server als weiterer Parameter analysiert wird. Effektiv wäre dies die gleiche Abfrage wie:

/index.php?page=home&restrictedaction=edit

Aufteilung der HTTP-Antwort

Beschreibung

Da der Header einer HTTP-Antwort und ihr Hauptteil durch CRLF-Zeichen getrennt sind, kann ein Angreifer versuchen, diese zu injizieren. Eine Kombination von CRLFCRLF teilt dem Browser mit, dass der Header endet und der Body beginnt. Das bedeutet, dass er jetzt Daten in den Antworttext schreiben kann, in dem der HTML-Code gespeichert ist. Dies kann zu einer Cross-Site-Scripting-Sicherheitsanfälligkeit führen.

Ein Beispiel für die HTTP-Antwortaufteilung, die zu XSS führt

Stellen Sie sich eine Anwendung vor, die beispielsweise einen benutzerdefinierten Header festlegt:

X-Your-Name: Bob

Der Wert des Headers wird über einen Get-Parameter namens „name“ gesetzt. Wenn keine URL-Codierung vorhanden ist und der Wert direkt im Header angezeigt wird, kann ein Angreifer möglicherweise die oben erwähnte Kombination von CRLFCRLF einfügen, um dem Browser mitzuteilen, dass der Anforderungstext beginnt. Auf diese Weise kann er Daten wie XSS-Nutzdaten einfügen, zum Beispiel:

?name=Bob%0d%0a%0d%0a<script>alert(document.domain)</script>

Das obige zeigt ein Warnfenster im Kontext der angegriffenen Domäne an.

HTTP Header Injection

Beschreibung

Durch die Ausnutzung einer CRLF-Injection kann ein Angreifer auch HTTP-Header einfügen, die verwendet werden können, um Sicherheitsmechanismen wie den XSS-Filter eines Browsers oder die Same-origin-Policy zu umgehen. Auf diese Weise kann der Angreifer vertrauliche Informationen wie CSRF-Token erhalten. Er kann auch Cookies setzen, die ausgenutzt werden können, indem er das Opfer im Konto des Angreifers anmeldet oder anderweitig nicht ausnutzbare Cross-Site Scripting (XSS) -Schwachstellen ausnutzt.

Ein Beispiel für HTTP-Header-Injection zum Extrahieren sensibler Daten

Wenn ein Angreifer in der Lage ist, die HTTP-Header zu injizieren, die CORS (Cross Origin Resource Sharing) aktivieren, kann er Javascript verwenden, um auf Ressourcen zuzugreifen, die ansonsten durch SOP (Same Origin Policy) geschützt sind, wodurch verhindert wird, dass Websites unterschiedlicher Herkunft aufeinander zugreifen.

Auswirkungen der CRLF-Injection-Schwachstelle

Die Auswirkungen von CRLF-Injections variieren und umfassen auch alle Auswirkungen von Cross-Site-Scripting auf die Offenlegung von Informationen. Es kann auch bestimmte Sicherheitsbeschränkungen wie XSS-Filter und die gleiche Ursprungsrichtlinie in den Browsern des Opfers deaktivieren, wodurch sie anfällig für böswillige Angriffe werden.

Verhindern von CRLF / HTTP-Header-Injektionen in Webanwendungen

Die beste Präventionstechnik besteht darin, Benutzereingaben nicht direkt in Antwortheadern zu verwenden. Wenn dies nicht möglich ist, sollten Sie immer eine Funktion verwenden, um die CRLF-Sonderzeichen zu codieren. Eine weitere gute Best Practice für die Sicherheit von Webanwendungen besteht darin, Ihre Programmiersprache auf eine Version zu aktualisieren, die es nicht zulässt, dass CR und LF in Funktionen eingefügt werden, die HTTP-Header festlegen.

Schwachstellenklassifizierung und Schweregradtabelle