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

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Ob es uns gefällt oder nicht: HTTP ist de facto das Transportprotokoll für Anwendungen unserer Zeit. Wir verwenden es überall. Es ist ebenso allgegenwärtig wie IP und TCP und erfüllt einen ganz ähnlichen Zweck. Sein einziges Ziel besteht darin, das digitale Gold der heutigen Geschäftswelt zu transportieren: Daten.

Ob diese Daten im JSON- oder XML-Format vorliegen oder URL-codiert sind, spielt keine Rolle. Apps und Geräte nutzen HTTP, um mit Servern und Diensten in der Cloud und lokal im Rechenzentrum zu kommunizieren.

Im Gegensatz zu IP und TCP ist HTTP jedoch ein textbasiertes Protokoll. Es ist äußerst flexibel und kann eine Vielzahl von Daten übertragen – von Binärdaten bis hin zu Text. Wir verwenden es, um Daten zu streamen, abzurufen und zu erfassen.

Angreifer machen ausgiebig davon Gebrauch, da es sich, wie bereits erwähnt, um ein textbasiertes Protokoll handelt, dessen Regeln für die Erweiterung der Header relativ großzügig sind. Diese Header legen alles fest – von der Aktion, die der Client vom Server erwartet (die HTTP-„Methode“), über die angeforderte Ressource (den URI) bis hin zur Art der Inhalte, die akzeptiert werden können (die „Accept“-Header). Diese Regeln sind bewusst großzügig gehalten, um Erweiterbarkeit zu ermöglichen.

Beispielsweise wurde der X-Forwarded-For-Header eingeführt, damit Entwickler die ursprüngliche Client-IP-Adresse „sehen“ können. In bestimmten Architekturen – insbesondere solchen, in denen Vermittler als Full-Proxys fungieren – können diese Informationen verloren gehen. Einige Anwendungen benötigen diese Daten, weshalb Entwickler (und Netzwerkanbieter) das HTTP-Protokoll durch die Einführung eines benutzerdefinierten Headers erweiterten. Dies ist Teil der HTTP-Spezifikation und ermöglicht Innovationen sowie die Einführung neuer Verhaltensweisen und Funktionen, ohne dass Änderungen am Protokoll erforderlich sind. Das ist eine gute Sache.

Außer, wenn es das nicht ist.

Es ist problematisch, wenn diese Flexibilität weder von den Entwicklern der HTTP-unterstützenden Server noch von den Verantwortlichen für die Absicherung HTTP-basierter Anwendungen berücksichtigt wird.

Hier ist eine kleine Auswahl HTTP-bezogener CVEs, die eine Schwachstelle in HTTP-Headern ausnutzen:

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

Ein Hinweis zu Optionsbleed

Optionsbleed ist eine der jüngsten Sicherheitslücken. Ich hebe sie hervor, weil sie direkt in Apache HTTP selbst besteht. Laut aktuellen Schätzungen von Netcraft laufen auf „mehr als 2,8 Millionen mit dem Internet verbundenen Computern derzeit verschiedene Versionen und Derivate von Apache httpd, was einem Anteil von 42,8 % aller mit dem Internet verbundenen Computer entspricht“. Dadurch stellen Sicherheitslücken darin ein erhebliches Risiko dar. Glücklicherweise wird diese spezielle Sicherheitslücke zwar über einen HTTP-Header ausgelöst, setzt aber zusätzlich eine falsch konfigurierte Limits-Direktive in der Datei .htaccess voraus. Dieser Beitrag von Sophos bietet einen hervorragenden Überblick über die unschönen technischen Details, falls Sie sich dafür interessieren. Kurz gesagt: Wenn diese Fehlkonfiguration vorliegt, kann ein Angreifer über den HTTP-Methoden-Header eine Sicherheitslücke in Apache ausnutzen und den Server – so scheint es – dazu bringen, Daten preiszugeben, die nun ja, jemand anderem gehören.

Nun habe ich all das gesagt, um Folgendes festzuhalten: Anwendungssicherheit besteht aus mehreren Ebenen. Dazu gehören auch die Plattformen (und damit die Protokolle), auf die Anwendungen angewiesen sind. Zum Beispiel HTTP.

Wir müssen HTTP besser davor schützen, zur Gefährdung der Sicherheit missbraucht zu werden. Ob es sich dabei um ein Datenleck, einen DoS-Angriff oder einen Fernzugriff handelt, ist nicht entscheidend. All dies hat schwerwiegende Folgen. Wir müssen besser erkennen, dass HTTP eine immer beliebtere Angriffsfläche darstellt. Da es textbasiert ist, sollte die gesamte Interaktion zwischen einem Client und dem HTTP-Dienst als Benutzereingabe eingestuft werden.

Das sollte wiederum zu einer Sicherheitsstrategie führen, die eine Bereinigung dieser Eingaben vorsieht. Ja, das bedeutet, das Protokoll bereits vorgelagert durchzusetzen und die Eingaben dort zu bereinigen (bevor sie einen potenziell anfälligen HTTP-Server erreichen).

Das bedeutet, dass eine Web Application Firewall oder ein programmierbarer Proxy jedem öffentlich zugänglichen HTTP-Dienst vorgeschaltet sein und eingehende HTTP-Anfragen aktiv bereinigen sollte.

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

Natürlich ist das Einspielen eines Patches die ultimative Lösung. Vorausgesetzt, Sie (1) erfahren bereits am Tag null von der Sicherheitslücke, (2) ein Patch wird noch am selben Tag bereitgestellt und (3) Sie sind bereit, einen möglicherweise ungetesteten Patch auf Produktivsystemen einzuspielen.

Verstehen Sie mich nicht falsch: Sie müssen Patches einspielen. Doch zwischen Offenlegung, Entdeckung, Verfügbarkeit und Anwendung klafft eine Lücke. Darin liegt das Risiko, dass eine sehr leicht auszunutzende Schwachstelle gegen Sie eingesetzt wird.

Die vorletzte Lösung besteht darin, sicherzustellen, dass ein System (eine Plattform) vorhanden ist, auf dem bzw. der Sie sofortige Abhilfemaßnahmen wie Skripte oder signaturbasierte Scans bereitstellen können, um eine Ausnutzung zu verhindern, während Sie die Installation des Patches vorbereiten.

Die Bereinigung eingehender Daten und die Durchsetzung der Protokollkonformität sollten fester Bestandteil jeder unternehmensweiten Sicherheitsrichtlinie sein.

HTTP birgt zunehmend Risiken, lässt sich aber beherrschen, wenn Sie sich vor Augen halten, dass Anwendungssicherheit aus mehreren Ebenen besteht, und anschließend jede dieser Ebenen entsprechend absichern.

Über den Autor

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.

Weitere Blogbeiträge von Lori Mac Vittie