CRLF Injection
Copyright © Shutterstock / BEST-BACKGROUNDS
Inhaltsverzeichnis
Was ist CRLF Injection?
Definition
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
Sie haben noch Fragen?
