Die Risiken beim Einsatz von HTTP nehmen zu, sind aber beherrschbar

Ob es uns gefällt oder nicht, HTTP ist das De-facto- Application der Neuzeit. Wir verwenden es überall. Es ist ebenso allgegenwärtig wie IP und TCP und dient weitgehend demselben Zweck. Sein einziges Ziel ist der Transport des digitalen Goldes der heutigen Wirtschaft: Daten.

Ob diese Daten JSON-, XML- oder URL-codiert sind, spielt keine Rolle. Es ist HTTP, das Apps und Geräte verwenden, um mit Servern und Diensten in der Cloud und vor Ort im Rechenzentrum zu kommunizieren.

Im Gegensatz zu IP und TCP ist HTTP jedoch ein textbasiertes Protokoll. Es ist äußerst flexibel und kann verschiedene Daten transportieren – von Binärdaten bis hin zu Text. Wir verwenden es zum Streamen von Daten, zum Abrufen von Daten und zum Sammeln von Daten.

Angreifer machen großzügig davon Gebrauch, da es sich, wie erwähnt, um ein textbasiertes Protokoll mit ziemlich laxen Regeln hinsichtlich der Erweiterungen der Header handelt, die alles spezifizieren, von der Aktion, die der Client vom Server erwartet (die HTTP-„Methode“), über die angeforderte Ressource (die URI) bis hin zu der Art des akzeptierten Inhalts (die „Accept“-Header). Diese Regeln sind locker, um Erweiterbarkeit zu ermöglichen.

Beispielsweise wurde der Header „X-Forwarded-For“ eingeführt, um sicherzustellen, dass Entwickler die ursprüngliche IP-Adresse des Clients „sehen“ konnten. In bestimmten Architekturen – insbesondere solchen, in denen Vermittler als Vollproxys fungieren – können diese Informationen verloren gehen. Einige Applications benötigen diese Daten und daher haben Entwickler (und Netzwerkanbieter) das HTTP-Protokoll durch die Einführung eines benutzerdefinierten Headers erweitert. Dies ist Teil der HTTP-Spezifikation; es ermöglicht Innovationen und die Einführung neuer Verhaltensweisen und Funktionen, ohne dass Änderungen am Protokoll erforderlich sind. Das ist eine gute Sache.

Außer wenn dies nicht der Fall ist.

Es ist nicht gut, wenn diese Flexibilität von den Entwicklern der HTTP-unterstützenden Server oder von denjenigen, die für die Sicherung von HTTP-basierten Applications verantwortlich sind, nicht berücksichtigt wird.

Hier ist eine kleine Auswahl von CVEs im Zusammenhang mit HTTP, die eine Schwachstelle in HTTP-Headern ausnutzen:

Ehrlich gesagt liefert eine Suche in den bekannten CVEs nach HTTP-Schwachstellen eine übermäßig lange Liste (und umfasst eine Vielzahl von Anbietern und Software), die ich hier nicht wiederholen werde. Ein erheblicher Teil davon wird im Allgemeinen durch den Missbrauch eines HTTP-Headers ausgelöst.

Eine Anmerkung zu Optionsbleed 

Optionsbleed ist eine der jüngsten Sicherheitslücken. Ich rufe es auf, weil es in Apache HTTP selbst vorhanden ist. Angesichts der Tatsache, dass Netcraft derzeit schätzt, dass Apache auf „mehr als 2,8 Millionen Computern mit Internetzugriff läuft, auf denen verschiedene Versionen und Derivate des Apache httpd laufen, was einem Anteil von 42,8 % aller Computer mit Internetzugriff entspricht“, stellen darin enthaltene Schwachstellen ein erhebliches Risiko dar. Glücklicherweise wird diese spezielle Sicherheitslücke über einen HTTP-Header ausgelöst, erfordert aber auch das Vorhandensein einer falsch konfigurierten Limits -Direktive in der .htaccess- Datei. Dieser Beitrag von Sophos bietet einen hervorragenden Überblick über die grausamen technischen Details, falls Sie Interesse haben. Die Kurzfassung lautet: Wenn die Fehlkonfiguration besteht, kann ein Angreifer eine Schwachstelle in Apache über den HTTP-Methodenheader ausnutzen und (so scheint es) den Server zwingen, Daten „auszubluten“, die, nun ja, jemand anderem gehören.

Nachdem ich das alles gesagt habe , kann ich auch Folgendes sagen: App-Sicherheit ist ein Stapel. Dieser Stapel umfasst die Plattformen (und damit Protokolle), auf denen Applications basieren. Wie HTTP.

Wir müssen HTTP besser davor schützen, missbraucht zu werden und die Sicherheit zu gefährden. Ob es sich dabei um ein Datenleck, einen DoS-Angriff oder einen Fernzugriff handelt, ist dabei nicht entscheidend. Das sind alles negative Auswirkungen. Wir müssen uns stärker darüber im Klaren sein, dass HTTP eine zunehmend beliebte Angriffsfläche darstellt. Da es textbasiert ist, sollte die gesamte Interaktion zwischen einem Client und dem HTTP-Dienst als Benutzereingabe klassifiziert werden.

Dies sollte wiederum eine Sicherheitsstrategie fördern, die Desinfektion einschließt dieser Eingabe. Ja, das bedeutet Protokolldurchsetzung und Upstream-Scrubbing (bevor es einen möglicherweise anfälligen HTTP-Server erreicht).

Dies bedeutet, dass vor jedem öffentlichen HTTP-Dienst eine Web Application Firewall oder ein programmierbarer Proxy installiert werden sollte, der eingehende HTTP-Anfragen aktiv bereinigt.

Der Grund hierfür liegt in der Art und Weise, wie Webplattformen HTTP-Header verarbeiten, also bevor die Anfrage überhaupt von einem Entwickler gesehen wird. Daher können wir nicht unbedingt mit dem Finger auf die Entwickler zeigen und unsichere Codierungspraktiken für Schwachstellen auf Plattformebene verantwortlich machen.

Die ultimative Lösung ist natürlich das Patchen. Vorausgesetzt, Sie (1) erfahren am Tag Null von der Sicherheitslücke, (2) ein Patch wird am Tag Null bereitgestellt und (3) haben kein Problem damit, einen möglicherweise ungetesteten Patch auf Produktionssystemen bereitzustellen.

Sie müssen Patches installieren, verstehen Sie mich nicht falsch, aber es besteht eine Lücke zwischen Offenlegung, Entdeckung, Verfügbarkeit und Application. In dieser Lücke liegt ein Risiko: das Risiko, dass eine sehr leicht auszunutzende Schwachstelle gegen Sie verwendet wird.

Die vorletzte Lösung besteht darin, sicherzustellen, dass ein System (eine Plattform) vorhanden ist, auf dem Sie sofortige Abhilfelösungen wie Skripte oder signaturbasierte Scans implementieren können, um eine Ausnutzung zu verhindern , während Sie sich auf das Patchen vorbereiten.

Die Bereinigung eingehender Daten und die Durchsetzung der Protokollkorrektheit sollten fester Bestandteil jeder Unternehmenssicherheitsrichtlinie sein.

HTTP birgt zunehmend Risiken, ist aber auch beherrschbar, wenn Sie bedenken, dass App-Sicherheit ein Stapel ist, und dann auf jeder Ebene dieses Stapels Schutzmaßnahmen implementieren.