Web14: Sicherheitsprobleme im HTTP-Protokoll

In diesem Artikel werden einige Sicherheitsprobleme im HTTP-Protokoll vorgestellt , die in den beiden Dokumenten RFC 7230 und RFC 7231 angesprochen werden. Beispiele im Artikel zu bestimmten Fehlern werden von OWASP referenziert.

1. Risiken durch Zwischenfaktoren

HTTP ermöglicht den Einsatz von Vermittlern, um über eine Reihe von Verbindungen auf Anfragen zu antworten. Es gibt drei gemeinsame Zwischenelemente: Proxy, Gateway und Tunnel.

Eine Anfrage oder Antwort muss die Punkte A, B und C durchlaufen. Sie können auf vertrauliche Informationen zugreifen, die übertragen werden, wie z. B. persönliche Informationen von Benutzern oder Organisationen. Die mangelnde Beachtung von Sicherheit und Datenschutz durch Vermittler kann zu einer Vielzahl potenzieller Angriffe führen.

Systementwickler und Entwickler sollten Datenschutz- und Sicherheitsfaktoren während des Systemdesign-, Codierungs- und Bereitstellungsprozesses berücksichtigen.

Benutzer müssen sich der Gefahren der Verwendung nicht vertrauenswürdiger Proxys oder Gateways bewusst sein.

2. Antwortaufteilung

Die Aufteilung von Antworten (auch bekannt als CRLF-Injection) ist eine beliebte Web-Exploit-Technik. Der Angreifer sendet in einigen Anforderungsparametern verschlüsselte Daten, die dann dekodiert und in einem bestimmten Feld des Antwortheaders wiederholt werden.

Wenn es sich bei diesen Daten um ein Symbol handelt, das das Ende der Antwort darstellt, und eine nachfolgende Antwort eingeleitet wird, wird die ursprüngliche Antwort in zwei Teile geteilt und der Inhalt der zweiten Antwort wird vom Angreifer kontrolliert. Der Angreifer kann dann innerhalb derselben dauerhaften Verbindung eine weitere Anfrage stellen und den Empfänger (einschließlich Vermittlern) dazu verleiten, zu glauben, dass diese zweite Antwort eine Antwort auf die zweite Anfrage ist.

3. Fordern Sie Schmuggel an

Beim Anforderungsschmuggel handelt es sich um eine Technik, die Unterschiede in der Verarbeitung von Anforderungen durch verschiedene Servertypen ausnutzt, um scheinbar harmlose, an die ursprüngliche Anforderung angehängte Anforderungen zu verbergen.

Betrachten wir das folgende Beispiel:

Angenommen, eine POST-Anfrage enthält im Header zwei „Content-length“-Felder mit zwei unterschiedlichen Werten. Einige Server lehnen diese Anfrage ab (IIS und Apache), andere jedoch nicht. Beispielsweise verwendet SunONE W/S 6.1 zuerst das Feld „Inhaltslänge“, während sunONE Proxy 3.6 das Feld „Inhaltslänge“ als zweites verwendet.

Angenommen, SITE ist der DNS eines SunONE W/S, der sich hinter einem SunONE-Proxy befindet, befindet sich auf dem SunONE W/S eine Datei „poison.html“. So können Sie HTTP Request Suggling aufgrund von Inkonsistenzen bei der Verarbeitung zwischen zwei Servern ausnutzen:

[Beachten Sie, dass jede Zeile mit einem CRLF („“) endet, außer Zeile 10]

Betrachten wir, was passiert, wenn eine Anfrage über den Proxyserver an W/S gesendet wird. Zunächst analysiert der Proxy die Anfrage aus den Zeilen 1 bis 7 (blau) und stößt auf zwei Content-Length-Felder. Wie oben erwähnt, ignoriert es das erste Feld und geht davon aus, dass der Anforderungstext 44 Byte lang ist. Daher werden die Daten aus den Zeilen 8 bis 10 als erster Anforderungstext behandelt (die Daten aus den Zeilen 8 bis 10 sind genau 44 Byte lang). Der Proxy analysiert dann die Zeilen 11 bis 14 (in Rot) als zweite Anfrage des Clients.

Sehen wir uns nun an, wie W/S die oben genannten Daten interpretiert, wenn sie vom Proxy weitergeleitet werden. Im Gegensatz zu Proxys verwendet W/S das erste Content-Length-Feld und interpretiert es wie folgt: Die erste Anfrage hat keinen Hauptteil und die zweite Anfrage beginnt in Zeile 8 (beachten Sie, dass W/S ab Zeile 11 den Wert analysiert). des Bla-Feldes).

Sehen wir uns als Nächstes an, wie die Antwort an den Client zurückgegeben wird. Die Anfrage, die W/S versteht, ist „POST /foobar.html“ (aus Zeile 1) und „GET /poison.html“ (aus Zeile 8), sodass dem Client zwei Antworten mit dem Inhalt der Foobar-Seite gesendet werden. html undpoison.html. Der Proxy versteht, dass diese beiden Antworten zwei Anfragen entsprechen: „POST /foobar.html“ (aus Zeile 1) und „GET /page_to_poison.html“ (Zeile 11). Der Proxy speichert den Inhalt der Seite „poison.html“, die der URL „page_to_poison.html“ entspricht, im Cache (Cache-Poisoning). Wenn der Client von dort „page_to_poison.html“ anfordert, erhält er den Inhalt der Seite „poison.html“.

4. Angriff basierend auf dem Dateipfad

Webserver nutzen häufig ihr lokales Dateisystem, um die Zuordnung von Dateinamen in URIs zu tatsächlichen Ressourcen auf dem Server zu verwalten. Die meisten Dateisysteme sind nicht darauf ausgelegt, vor bösartigen Dateipfaden zu schützen. Daher muss der Server den Zugriff auf wichtige Systemdateien vermeiden.

Beispielsweise verwenden UNIX, Microsoft Windows und mehrere andere Betriebssysteme „..“ als Pfadelement, um ein Verzeichnis eine Ebene über der aktuellen Datei/dem aktuellen Verzeichnis darzustellen. Ohne ordnungsgemäße Eingabekontrolle und Autorisierung kann auf vertrauliche Dateien/Ordner des Systems zugegriffen werden, indem Pfade eingegeben werden, die auf diese Dateien/Ordner verweisen.

5. Arten von Angriffen: Command-Injection, Code-Injection, Query-Injection

[Webserver verwenden häufig Parameter im URI als Eingabe, um Systembefehle und Datenbankabfragen auszuführen. Den in der Anfrage erhaltenen Daten kann jedoch nicht immer vertraut werden. Ein Angreifer kann Komponenten in der Anfrage erstellen und ändern (z. B. Methoden, Felder im Header, Text usw.), um Systembefehle auszuführen, die Datenbank abzufragen usw.

SQL-Injection ist beispielsweise ein häufiger Angriff, bei dem der Webserver Parameter im URI empfängt, die Teil der SQL-Abfrage sind. Daher kann ein Angreifer den Webserver dazu verleiten, illegale SQL-Abfragen auszuführen, um die Datenbank zu stehlen oder zu sabotieren.
Im Allgemeinen sollten von Benutzern übermittelte Daten nicht direkt zur Ausführung von Vorgängen auf dem Server verwendet werden. Diese Daten müssen Filter durchlaufen, die definieren, was gültig und was ungültig ist, und so unerwünschte Daten eliminieren.

6. Offenlegung personenbezogener Daten

Clients enthalten oft viele persönliche Informationen, einschließlich Informationen, die der Benutzer für die Interaktion mit dem Server bereitstellt (z. B. Benutzername, Passwort, Standort, E-Mail-Adresse usw.) und Informationen über Webbrowsing-Aktivitäten des Benutzers (Verlauf, Lesezeichen, usw.). Bei der Umsetzung sollte darauf geachtet werden, dass Punkte vermieden werden, die diese privaten Informationen preisgeben können.

7. Offenlegung vertraulicher Informationen in der URI

URIs sind von Natur aus dazu gedacht, mit allen Benutzern geteilt zu werden, und es kann nicht garantiert werden, dass sie sicher sind. URIs werden häufig im Quellcode der Website angezeigt und ohne Schutzmechanismen in Lesezeichen gespeichert. Daher ist es unsicher, wenn der URI vertrauliche Informationen, persönliche Informationen usw. enthält.

Vermeiden Sie die Verwendung der GET-Methode zum Senden persönlicher Informationen an den Server, da diese im URI angezeigt werden. Verwenden Sie stattdessen die POST-Methode.

8. Offenlegung verwendeter Softwareinformationen

Die Felder User-Agent, Via, Server im Header geben normalerweise Auskunft über die vom Absender verwendete Software. Theoretisch können Angreifer dadurch bekannte Schwachstellen in dieser Software leichter ausnutzen.