Wenn Benutzer im Internet surfen und verschiedene Aufgaben ausführen, sind wir Angriffen ausgesetzt. Cyberkriminelle suchen nach Schwachstellen und Fehlern in unseren Betriebssystemen, um ihre Vorteile zu nutzen. Daher sind ein aktualisiertes Betriebssystem und ein gutes Antivirenprogramm immer ein guter Ausgangspunkt für unsere Verteidigung. Internetnutzer sind jedoch nicht das einzige Ziel von Cyberkriminellen. Sie führen auch Angriffe auf einen Webserver durch, a Firewall, einen Proxy-Server und mehr. Heute werden wir über eine Art von Angriff sprechen, die letztere betrifft. In diesem Tutorial werden wir darüber sprechen, was Schmuggel von HTTP-Anfragen ist und wir werden auch erklären, warum es so gefährlich ist.
Was macht dieser Angriff und Gefahren
We kann einen HTTP Request Smuggling-Angriff definieren als solche, die die Diskrepanzen in der Analyse ausnutzt, wenn sich ein oder mehrere HTTP-Geräte / -Entitäten im Datenfluss zwischen dem Benutzer und dem Webserver befinden. Wir stoßen auf eine Technik, die die Art und Weise stört, wie eine Website die Streams von HTTP-Anfragen verarbeitet, die von einem oder mehreren Benutzern empfangen werden.
Diese Schwachstellen sind oft kritischer Natur und ermöglichen es Cyberkriminellen, Sicherheitskontrollen zu umgehen, unbefugten Zugriff auf private Daten zu erlangen und sogar andere Benutzer der Anwendung direkt zu gefährden. Dieser illegale Verkehr von HTTP-Anfragen ermöglicht verschiedene Angriffe wie Cache-Poisoning, Session-Hijacking und auch die Möglichkeit, den Firewall-Schutz von Webanwendungen zu umgehen.
Dieser HTTP Request Smuggling-Angriff kann verschiedene Computer und Dienste betreffen:
- Webserver.
- Firewall.
- Proxy Server.
Der Ursprung geht auf das Jahr 2005 zurück, als dieser Angriff von einer Gruppe von Watchfire-Forschern, darunter Klein, Ronen Heled, Chaim Linhart und Steve Orrin, demonstriert wurde. In den letzten Jahren wurden jedoch eine Reihe von Verbesserungen vorgenommen, die die Angriffsfläche erweitern und maximalen Zugriff auf interne APIs und Cache-Poisoning ermöglichen.
Wie dieser Angriff abläuft
Webanwendungen verwenden heute häufig HTTP-Server-Strings zwischen Benutzern und der endgültigen Anwendungslogik. Auf diese Weise senden Benutzer Anforderungen an einen Front-End-Server, und der Front-End-Server sendet die Anforderungen dann an einen oder mehrere Back-End-Server. Es ist zu beachten, dass diese Architektur immer häufiger und in einigen Fällen unvermeidbar ist, beispielsweise bei Cloud-basierten Anwendungen.
Wenn ein Front-End-Server HTTP-Anforderungen an einen Back-End-Server weiterleitet, sendet er normalerweise mehrere Anforderungen über dieselbe Back-End-Netzwerkverbindung. Dies geschieht, weil es effizienter ist und eine höhere Leistung bietet. Die Vorgehensweise ist einfach, zunächst werden die HTTP-Requests nacheinander gesendet. Der empfangende Server parst dann die Header jeder HTTP-Anfrage, um zu bestimmen, wo eine Anfrage endet und wann die nächste beginnt.
Ein sehr wichtiger Aspekt ist, dass die Frontend- und Backend-Systeme sollen sich auf die Grenzen der Anfragen einigen . Dies ist relevant, da ein Cyberkrimineller andernfalls eine mehrdeutige Anfrage an die Front-End- und Back-End-Systeme senden könnte und diese anders verstehen könnten.
Dabei bewirkt der Angreifer, dass ein Teil seiner Frontend-Anfrage vom Backend-Server als Beginn der nächsten Anfrage interpretiert wird. Was dann passiert, ist, dass sie der nächsten Anforderung vorausgeht, was zu Störungen bei der Verarbeitung dieser Anforderung durch die Anwendung führt. Wir würden auf einen HTTP Request Smuggling-Angriff stoßen, der für den Besitzer dieses Servers katastrophale Folgen haben kann.
Warum diese Angriffe auftreten
Ein großer Teil der Schwachstellen beim HTTP-Request-Smuggling tritt auf, weil die HTTP-Spezifikation zwei verschiedene Möglichkeiten bietet, um anzugeben, wo eine Anfrage endet. Ein Header ist einfach, er gibt die Länge des Nachrichtentexts in Bytes an. Dies kann verwendet werden, um anzugeben, dass der Nachrichtentext eine Chunk-Codierung verwendet. Dies bedeutet, dass der Textkörper dieser Nachricht ein oder mehrere Daten enthält. Einige Sicherheitsadministratoren wissen nicht, dass Chunked-Verschlüsselung in HTTP-Anforderungen verwendet werden kann, und dies ist ein Problem.
Falls Sie es nicht wissen, bietet HTTP zwei verschiedene Methoden, um die Länge von HTTP-Nachrichten zu bestimmen. Es sollte auch beachtet werden, dass es für eine einzelne Nachricht möglich ist, beide Methoden gleichzeitig zu verwenden, in diesem Fall würden sie miteinander in Konflikt geraten. Das HTTP-Protokoll versucht, dieses Problem zu lösen, indem es angibt, dass, wenn sowohl der Content-Length- als auch der Transfer-Encoding-Header vorhanden sind, der Content-Length-Header nicht verwendet werden sollte. Diese Formel kann ausreichen, um Mehrdeutigkeiten zu vermeiden, wenn wir nur einen aktiven Server haben, aber nicht, wenn zwei oder mehr Server verkettet sind.
Wenn sich die Front-End- und Back-End-Server in Bezug auf einen möglicherweise verschleierten Header vom Typ Transfer-Encoding unterschiedlich verhalten, können sie sich daher hinsichtlich der Grenzen zwischen aufeinanderfolgenden Anforderungen nicht einig sein. Dies könnte zu Sicherheitslücken und einem HTTP-Request-Smuggling-Angriff führen.
So verhindern Sie diesen gefährlichen Angriff
Bei HTTP-Request-Smuggling-Angriffen werden sowohl der Content-Length-Header als auch der Transfer-Encoding-Header in derselben HTTP-Anfrage platziert und dann so manipuliert, dass die Front-End- und Back-End-Server die Anfrage unterschiedlich verarbeiten.
Klein, den wir bereits erwähnt haben, fordert die Normalisierung ausgehender HTTP-Anfragen von Proxy-Servern und hebt die Notwendigkeit einer robusten Open-Source-Firewall-Lösung für Webanwendungen hervor, die in der Lage ist, diese Art von Angriffen zu bewältigen. Um dieses Problem zu lösen, hat Klein ein C++-basiertes Projekt veröffentlicht, das sicherstellt, dass alle eingehenden HTTP-Anfragen vollständig gültig, konform und eindeutig sind. Dieses Werk ist auf GitHub veröffentlicht und Sie können es sich ansehen hier .
Auf der anderen Seite könnten wir folgende Dinge tun, um einen HTTP-Request-Smuggling-Angriff zu vermeiden:
- Deaktivieren Sie die Wiederverwendung von Back-End-Verbindungen, damit jede Back-End-Anfrage über eine separate Netzwerkverbindung gesendet wird.
- Verwenden Sie HTTP / 2 für Back-End-Verbindungen, da dieses Protokoll Mehrdeutigkeiten in den Grenzen zwischen den Anforderungen vermeidet.
- Für die Front-End- und Back-End-Server muss die exakt gleiche und identische Webserver-Software verwendet werden. Dadurch wird sichergestellt, dass sie sich auf die Grenzen zwischen den Anforderungen einigen.
Wie Sie gesehen haben, ist der HTTP Request Smuggling-Angriff aufgrund seiner Schwere sehr wichtig, er ist jedoch ziemlich gefährlich. Wir haben jedoch verschiedene Möglichkeiten, diesen Angriff zu verhindern und richtig abzuwehren.
