CRLF ist das Akronym für Zeilenvorschub (\n) mit Wagenrücklauf (\r). Wie aus den Symbolen in den Klammern hervorgeht, bezieht sich „Wagenrücklauf“ auf das Ende einer Zeile und „Zeilenvorschub“ auf die neue Zeile. Daher werden sowohl CR als auch LF verwendet, um den Endpunkt einer Linie zu bezeichnen. Wenn ein Benutzer Inhalte auf einer Website anfordert, gibt der Server den Inhalt der Website zusammen mit den HTTP-Headern zurück. Die Kopfzeilen und der Inhalt werden durch eine definierte Kombination von CR und LF getrennt. Aufgrund von CRLF weiß ein Server, wo ein neuer Header beginnt oder endet. Eine Carriage Return Line Feed (CRLF) Injection Verwundbarkeit ist eine Art von Server Side Injection, die auftritt, wenn ein Angreifer die CRLF-Zeichen in ein Eingabefeld einfügt, um den Server zu täuschen, indem er denkt, dass ein Objekt beendet wurde und ein neues begonnen hat. Dies geschieht, wenn die Webanwendung Benutzereingaben für CRLF-Zeichen nicht bereinigt. Es hat einen mittleren Schweregrad (P3 nach Bugcrowds VRT).

CRLF Injection Attack hat zwei wichtigste Anwendungsfälle:

• Log Splitting: Der Angreifer fügt ein Zeilenende und eine zusätzliche Zeile ein, um die Einträge in der Protokolldatei zu verfälschen, um die Systemadministratoren zu täuschen, indem er andere Angriffe verbirgt.
• HTTP Response Splitting: CRLF Injection wird verwendet, um HTTP-Header zur HTTP-Antwort hinzuzufügen und beispielsweise einen XSS-Angriff durchzuführen, der zur Offenlegung von Informationen führt.

Beispiel:

Eine einfache GET-Anforderung kann wie folgt erstellt werden:

GET /%0d%0aSet-Cookie:CRLFInjection=PreritPathak HTTP/1.1

Hinweis: %0d und %0a sind codierte Formen von \r bzw. \n. Wenn die Webanwendung anfällig ist, kann ein Angreifer ein Cookie auf der Website setzen.

Auswirkungen der CRLF-Injektion

Mit der CRLF-Injektion kann der Angreifer gefälschte Cookies setzen, CSRF-Token stehlen, Benutzerinformationen durch Injizieren eines Skripts (XSS) offenlegen und eine Vielzahl anderer Angriffe ausführen. Es ermöglicht Angreifern auch, & Sicherheitsmaßnahmen wie XSS-Filter & Same Origin Policy (SOP) zu deaktivieren, wodurch sie anfällig für die folgenden Angriffe werden:

1. XSS oder Cross Site Scripting
XSS oder Cross Site Scripting ist eine Sicherheitslücke, die es einem Angreifer ermöglicht, bösartigen JavaScript-Code in die Webanwendung einzufügen. Die folgenden GET-Anforderungen werden in einem Versuch der CRLF-Injektion mit XSS erstellt.
Durch das Auslösen einer Warnung mit sensiblen Benutzerinformationen

www.target.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

Durch Deaktivieren des XSS-Schutzes

www.target.com/%0d%0aContent-Length:35%0d%0aX-XSS-Protection:0%0d%0a%0d%0a23

2. Cookie Injection
HTTP Response Splitting ermöglicht es einem Angreifer, bösartige Cookies im Browser des Opfers zu setzen. In den meisten Fällen führt die folgende GET-Anforderung zu einer 307-Umleitung, und das Opfer wird daher zu umgeleitet target.com & Die URL enthält den Parameter Set-Cookie nicht. Im Hintergrund wird jedoch das Cookie gesetzt.

www.target.com/%0d%0aSet-Cookie:CRLFInjection=MaliciousCookieSet

3. Phishing-Angriffe
Ein Angreifer kann den Standort-Header festlegen, der das Opfer auf die böse Website umleiten würde. Diese Website kann so entwickelt werden, dass sie genau wie die Zielwebsite aussieht, und wenn das Opfer seine Anmeldeinformationen eingibt, werden sie an den Angreifer gesendet. Der Location-Header kann wie folgt eingestellt werden:

GET /%0d%0aLocation:%20https://evil.com HTTP/1.1

4. Session Fixation
Ähnlich wie beim Cookie Injection-Angriff setzt der Angreifer hier die Sitzungs-ID eines Benutzers auf einen bestimmten Wert. Dieser Link wird an das Opfer gesendet, und wenn sich das Opfer mit dieser Sitzung anmeldet, kann sich der Angreifer auch mit derselben Sitzungs-ID anmelden.

www.target.com/%0d%0aSet-Cookie:session_id=942....

5. HTTP Header Injection
Ein Angreifer kann die CRLF-Injection nutzen, um HTTP-Header in eine Anwendung zu injizieren, um Sicherheitsmechanismen wie XSS-Filter oder die Same-Origin-Policy zu umgehen.

www.target.com/%0d%0aHackersHeader:NewHeader

CORS (Cross Origin Resource Sharing): Header können injiziert werden & Der Angreifer kann JavaScript verwenden, um auf sensible Ressourcen zuzugreifen, die ansonsten durch SOP (Same Origin Policy) geschützt sind, wodurch verhindert wird, dass Websites unterschiedlicher Herkunft aufeinander zugreifen.
6. Web-Cache-Poisoning
Web-Cache-Poisoning ist eine Technik, mit der ein Angreifer vergiftete Inhalte bereitstellen kann, indem er einen Web-Cache manipuliert. Um dieses Problem erfolgreich auszunutzen, müsste ein Angreifer den Caching-Proxy, Syndikatoren, Content Delivery Networks (CDNs) oder andere Caching-Mechanismen der anfälligen Website zwischen dem Client und dem Server vergiften. Nach einer erfolgreichen Webcache-Vergiftung hat das Opfer keine Ahnung mehr von den schädlichen Inhalten, die ihm vom Cache bereitgestellt werden. Im Folgenden finden Sie ein Beispiel dafür, wie ein Angreifer möglicherweise eine Host-Header-Injektion (mithilfe von CRLF) ausnutzen kann, indem er einen Webcache vergiftet.

Für die folgende Anfrage:

$ telnet www.target.com 80Trying x.x.x.x...Connected to www.target.com.Escape character is '^]'.GET /%0d%0aX-Forwarded-Host:hacker.com HTTP/1.1 //or HostHost: target.com

Es würde folgende Antwort geben:

HTTP/1.1 200 OK

Verschiedene Anwendungsfälle:

1. Injizieren eines gefälschten HTTP-Antwortheaders:

Content-Length: 10

Jetzt analysiert der Webbrowser nur noch die nächsten 10 Bytes.
2. Injizieren eines gefälschten HTTP-Antwortheaders:

Content-Length: 0

Dies wird als beendete Antwort behandelt & Die Webbrowser beginnen mit dem Parsen einer neuen Antwort.

Mitigations:

Ein Entwickler sollte die folgenden Dinge beachten, um CRLF-Injection zu verhindern:

• Bereinigung von Benutzereingaben.
• Kodieren CR & LF-Zeichen (\r, \n), so dass sie selbst dann, wenn sie bereitgestellt werden, vom Server nicht erkannt werden.
• Validieren Sie die Benutzereingaben, bevor sie die Antwortheader erreichen (z. B. mithilfe von Methoden wie StringEscapeUtils .escapeJava()).
• Ein unnötiger Header sollte deaktiviert werden.
  In der folgenden Tabelle wird der Schweregrad der CRLF-Injektion gemäß verschiedenen Industriestandards hervorgehoben: