CRLF Injection

Crlf Injection

Copyright ┬ę Unsplash/Obi Onyeador

Was ist CRLF Injection?

Ein CRLF Injection Angriff tritt auf, wenn es einem Benutzer gelingt, eine CRLF in eine Anwendung einzureichen. Dies geschieht meistens durch Ändern eines HTTP-Parameters oder einer URL.

Der Begriff CRLF bezieht sich auf Zeilenvorschub (ASCII 13, r) f├╝r Wagenr├╝cklauf (ASCII 10, n)┬áund wird verwendet, um die Beendigung einer Zeile zu vermerken, die jedoch in den heute g├Ąngigen Betriebssystemen unterschiedlich behandelt wird. Im HTTP-Protokoll wird immer die CR-LF-Sequenz verwendet, um eine Zeile zu beenden.

Beschreibung

Durch das Hinzuf├╝gen nicht validierter Daten in einen HTTP-Header kann ein Angreifer die Gesamtheit der HTTP-Antwort angeben, die vom Browser ausgegeben wird. Wenn eine HTTP-Anforderung unerwartete CR (Wagenr├╝cklauf) und LF (Zeilenvorschub) Zeichen enth├Ąlt, antwortet der Server m├Âglicherweise mit einem Ausgabestrom, der anstelle einer als zwei verschiedene HTTP-Antworten interpretiert wird. Ein Angreifer kann die zweite Reaktion steuern und Angriffe durchf├╝hren, z.B. Cross-Site-Scripting und Cache-Poisoning Angriffe.

Schwachstellen bei der HTTP-Antwortaufteilung k├Ânnen vorliegen, wenn:

  • Daten werden ├╝ber eine nicht vertrauensw├╝rdige Quelle, meistens eine HTTP-Anforderung, in eine Webanwendung eingegeben.
  • Die Daten sind in einem HTTP-Antwortheader enthalten, der an einen Webbenutzer gesendet wird, ohne auf sch├Ądliche Zeichen ├╝berpr├╝ft zu werden.

Mit dem CRLF Injection Scanner werden verschiedene CRLF-Sonderzeichen als Parameter an den Server versendet, die einem angelegten “Set-Cookie”-Header vorangestellt sind. Wenn die Antwort einen identischen Set-Cookie-Header enth├Ąlt, wird eine Warnmeldung ausgegeben und der Scanner kehrt sofort zur├╝ck.

Tipp

├ťberpr├╝fen Sie die Sicherheit Ihrer Website mit unserem kostenlosen Security Crawler oder mit der OSG Performance Suite Free Version.

L├Âsung

Konstruieren Sie HTTP-Header sehr sorgf├Ąltig und vermeiden Sie die Verwendung nicht validierter Eingabedaten. Die Eingaben sollten vor der Validierung dekodiert und kanonisiert werden, um sie der aktuellen internen Darstellung der Anwendung anzupassen. Stellen Sie sicher, dass die Anwendung dieselbe Eingabe nicht zweimal decodiert. Solche Fehler k├Ânnten verwendet werden, um Whitelist-Validierungsschemen zu umgehen, indem nach der ├ťberpr├╝fung gef├Ąhrliche Eingaben vorgenommen werden.

Datenbanklink zur Schwachstelle

https://cwe.mitre.org/data/definitions/113.html


Sie haben noch Fragen?

Kontaktieren Sie uns

Kostenloser SEO-Check der OSG


Weitere Inhalte