Zahlreiche Webprojekte greifen aus Gründen der Performance und Sicherheit auf Proxy-Server zurück. Diese praktischen Programme fungieren als Kommunikationsschnittstelle zwischen Client und Website und entlasten den Webserver, indem sie HTTP-Anfragen entgegennehmen, bearbeiten, weiterleiten und beantworten. Aufgrund einer als HTTPoxy bekannten Sicherheitslücke kann diese Technik von Angreifern jedoch zum Datendiebstahl missbraucht werden. Betroffen sind Anwendungen, die sich auf den CGI-Standard (Common Gateway Interface) stützen und dadurch konfigurierbare Variablen – sogenannte Umgebungsvariablen – mit sich bringen. Einige Programme können aus betreffenden Variablen zum Beispiel auch Ihre Proxy-Konfigurationen lesen, was schnell zum Problem wird, wenn Kriminelle diese Einstellungen manipulieren.
Wenn ein Webserver via Common Gateway Interface mit dem Client eines Nutzers kommuniziert, sieht der RFC-Standard 3875 vor, dass die Header aller verschickten HTTP-Anfragen als Umgebungsvariablen gespeichert werden. Die Bezeichnung dieser Variablen setzt sich aus dem Präfix „HTTP_“ und dem Namen des Headers in Großbuchstaben zusammen. Im hier geschilderten Fall geht es um den Header „Proxy“, der automatisch die Variable HTTP_PROXY erzeugt. Diese ist standardmäßig für die Konfiguration der Proxy-Einstellungen vorgesehen. Erreicht die CGI-Anwendung also eine Anfrage, die HTTP_PROXY umfasst, oder führt sie eine solche aus, wird diese über den entsprechenden Proxy-Server umgeleitet.
Die geschilderten Umstände erlauben es einem Angreifer nun, seinen eigenen Proxy-Server ins Spiel zu bringen und auf diese Weise an vertrauliche Informationen zu gelangen. Zu diesem Zweck sendet er einen HTTP-Request mit dem Header Proxy und einem entsprechenden Wert (zum Beispiel der IP-Adresse des Proxys), woraufhin künftige Nutzeranfragen – eingehend oder ausgehend – auf diesen umgeleitet werden. Je nach gewähltem Szenario kann der Angreifer dann nach Belieben eigene Daten zurücksenden oder auf direktem Wege Eingabedaten der User mitlesen.
Erstmalig fiel die Schwachstelle, deren Name keine spezielle Bedeutung hat, im März 2001 auf. Der Programmierer Randal L. Schwartz hatte HTTPoxy in der Perl-Bibliothek libwww-perl entdeckt und dies Gisle Aas mitgeteilt, dem Entwickler der Bibliothek. Dieser schloss die Sicherheitslücke umgehend im Update 5.51, indem er den Variablennamen, über den die Proxy-Konfiguration gesteuert werden kann, in CGI_HTTP_PROXY abänderte. Im gleichen Jahr machte man die Schwachstelle auch im Datentransferprogramm cURL aus, woraufhin der Entwickler Daniel Stenberg die Software dahingehend anpasste, dass diese fortan nur noch die kleingeschriebene Variante http_proxy zur Bestimmung des Proxy-Servers hinzuzog – unter dem gleichzeitigen Hinweis, dass dies für Microsoft-Systeme im Grunde genommen nicht ausreichend ist. In aktuellen Windows-Versionen soll das Problem jedoch nicht mehr bestehen.
Rund ein Jahrzehnt später stieß das Ruby-Team im Juli 2012 bei der Implementierung der Klasse NET::HTTP, einer HTTP-Client-API für Ruby-Anwendungen, auf die längst vergessene HTTPoxy-Problematik. Um das Problem zu umgehen, nahm man HTTP_PROXY unter anderem den Status als Standardvariable. In den folgenden Jahren gesellten sich unter anderem auch die Webserver-Anwendungen NGINX (2013) und Apache (2015) zu den prominenten Fällen, bei denen aufmerksame User die Entwickler über eine potenzielle Gefahrenlage in Kenntnis setzten.
2016 stellte das Sicherheitsteam der Entwicklerfirma Vend schließlich fest, dass die HTTPoxy-Sicherheitslücke auch 15 Jahre nach der ersten Entdeckung noch in PHP und diversen anderen Programmiersprachen sowie Bibliotheken ausnutzbar ist – sofern diese in Kombination mit CGI bzw. einer vergleichbaren Laufzeitumgebung mit konfigurierbaren Variablen zum Einsatz kommt. Viele betroffene Anwendungen, die die Ausnutzung von HTTPoxy ermöglichen, wurde in den offiziellen Spezifikationen für Sicherheitslücken, den sogenannten CVEs (Common Vulnerabilities and Exposures), aufgelistet:
Unabhängig davon, ob Sie einen eigenen Webserver betreiben oder nicht, stellt HTTPoxy für Sie ein Risiko dar, wenn Sie im World Wide Web unterwegs sind. Kann der aufgerufene Webservice durch externe HTTP-Requests unerwünscht umgeleitet werden, sind infolgedessen auch Ihre Daten nicht in sicheren Händen. Um das Risiko des Datenverlustes zu minimieren, sollten Sie daher Seiten bevorzugen, die durch ein TLS-/SSL-Zertifikat geschützt sind und alle Informationen in verschlüsselter Form übertragen. Auf diese Weise ist zwar weiterhin die Umleitung der Daten über einen falschen Proxy möglich, Kriminelle schlagen aus diesen gesicherten Informationen aber deutlich weniger bzw. im Optimalfall gar keinen Profit. Als Betreiber einer eigenen Seite gehört die Umstellung auf HTTPS heute ohnehin zum Pflichtprogramm.
Sie haben aber immer auch die Option, HTTPoxy generell zu vermeiden, indem Sie die Schwachstelle ganz einfach beseitigen. Da der Proxy-Header weder in einem IETF-Standard festgehalten noch bei der IANA als offizielle Kopfzeile registriert ist, können Sie ihn ohne Bedenken abfangen, bevor er Ihre Webanwendung erreicht. Standardkonforme HTTP-Clients und Server senden von sich aus ohnehin keine Datenpakete mit diesem Header. Grundsätzlich haben Sie neben der Verschlüsselung des HTTP-Datenaustauschs zwei Möglichkeiten, um die gefährdenden Requests von Ihrem Webprojekt fernzuhalten:
Erstere Variante ist wesentlich verbreiteter und lässt sich mithilfe jeglicher gewöhnlicher Webserver-, Proxy- oder Load-Balancing-Software bewerkstelligen. In den folgenden Abschnitten finden Sie Informationen darüber, wie Sie den potenziell gefährlichen Header mithilfe der Webserver-Anwendungen Apache und NGINX sowie der Proxy-Server-Software HAProxy auf verschiedenen Linux-Distributionen aus dem Verkehr ziehen.
Die freie Software Apache ist auf allen gängigen Linux-Distributionen standardmäßig installiert und für viele bis heute die erste Wahl, wenn es darum geht, einen eigenen Webserver zu betreiben. Bestandteil des Programms ist unter anderem das Modul mod_headers, das es Ihnen ermöglicht, den Proxy-Header aller eingehenden HTTP-Requests auszufiltern. Die Vorgehensweise unterscheidet sich leicht von Distribution zu Distribution.
Ubuntu und Debian:
Im ersten Schritt gilt es, das Modul zu aktivieren, was Sie mit dem folgenden Befehl erledigen:
sudo a2enmod headersÖffnen Sie anschließend die zentrale Konfigurationsdatei von Apache mit einem Editor, wobei das im Beispiel genutzte Kommandozeilen-Tool nano sehr zu empfehlen ist:
sudo nano /etc/apache2/apache2.confErweitern Sie diese Datei nun am Ende um den folgenden Eintrag:
<IfModule mod_headers.c>
RequestHeader unset Proxy early
</IfModule>Nachdem Sie die Datei gespeichert haben, aktivieren Sie den HTTPoxy-Schutz, indem Sie die spezifizierte Konfigurationsdatei per a2enconf-Skript laden und den Server im Anschluss neustarten:
sudo a2enconf httpoxy
sudo service apache2 restartCentOS und Fedora:
Nutzen Sie eine Version der Linux-Distributionen CentOS oder Fedora, ist das mod_headers-Modul standardmäßig bereits aktiviert, weshalb Sie diesen Schritt überspringen und gleich die Konfigurationsdatei öffnen können:
sudo nano /etc/httpd/conf/httpd.confIn diese fügen Sie am Ende den neuen Eintrag
RequestHeader unset Proxy earlyein. Abschließend speichern Sie die Änderungen und führen einen Neustart des Apache-Servers durch:
sudo service httpd restartNGINX ist als Webserver-Anwendung mittlerweile eine etablierte Größe, die sich zunehmender Beliebtheit erfreut. Mithilfe der Open-Source-Software sind ebenfalls nur wenige Schritte notwendig, um CGI-Anwendungen, die auf dem Server laufen bzw. zwischen Client und Server ausgeführt werden, ausreichend vor der HTTPoxy-Sicherheitslücke zu schützen.
Ubuntu und Debian:
Für gewöhnlich sind FastCGI-Parameter (bei FastCGI handelt es sich um eine Optimierung des CGI-Standards) unter Ubuntu und Debian in den Dateien fastcgi_params oder fastcgi.conf enthalten, wenn Sie einen NGINX-FastCGI-Proxy einrichten. In beiden Dateien können Sie den Proxy-Header in HTTP-Requests abstellen. Nutzen Sie dafür einfach folgende Befehlszeilen:
echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi.conf
echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi_paramsSofern Sie NGINX als konventionellen HTTP-Proxy nutzen, können Sie den Header ebenfalls herausfiltern. Zu diesem Zweck fügen Sie die entsprechende Regel in die Datei proxy_params ein, in der die Parameter für den Proxy-Server aufgeführt sind:
echo 'proxy_set_header Proxy "";' | sudo tee -a /etc/nginx/proxy_paramsIm letzten Schritt starten Sie NGINX mit diesem Befehl neu:
sudo service nginx restartCentOS und Fedora:
Die Vorgehensweise bei der Bannung der HTTPoxy-Gefahr für FastCGI-Proxys, die Sie mit CentOS oder Fedora betreiben, unterscheidet sich nicht von der Prozedur, die für Ubuntu- und Debian-Systeme von Nöten ist. Da die NGINX-Konfigurationen auch auf diesen Distributionen entweder in der Datei fastcgi_params oder in der Datei fastcgi.conf festgelegt sind, schalten Sie den Proxy-Header hier ebenfalls mit den bereits aufgeführten Befehlen aus:
echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi.conf
echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi_paramsUm konventionelle Proxys unter Fedora und CentOS zu schützen, müssen Sie sicherstellen, dass der Header überall dort blockiert wird, wo NGINX die Direktive proxy_pass ausführt. Um herauszufinden, wo diese zum Einsatz kommt, können Sie auf die Dienste des Suchbefehls grep zurückgreifen:
sudo grep -r "proxy_pass" /etc/nginxSie erhalten eine Auflistung der Textdateien, in denen die Direktive aufgeführt wird, wobei die Ausgabe in etwa wie in dem folgenden Beispiel aussieht:
/etc/nginx/nginx.conf.default: # proxy_pass http://127.0.0.1;In diesem Fall wäre proxy_pass also in der NGINX-Konfigurationsdatei gesetzt. Den entsprechenden Eintrag in der nginx.conf sollten Sie daher folgendermaßen ergänzen:
proxy_pass http://127.0.0.1;
proxy_set_header Proxy "";Zum Abschluss steht in beiden Fällen der Neustart des Servers an:
sudo service nginx restartWenn Sie HTTP-Anfragen über einen HAProxy-Server auf Ihr Webprojekt weiterleiten, können Sie den Proxy-Header entfernen, noch bevor der Proxy die Requests verschickt. Für die verschiedenen genannten Linux-Distributionen unterscheidet sich die Vorgehensweise dabei nicht. Zunächst gilt es, die zentrale Konfigurationsdatei der Proxy-Anwendung zu öffnen, was Sie mit dem folgenden Kommando tun:
sudo nano /etc/haproxy/haproxy.cfgAuf diese Weise öffnen Sie die Datei haproxy.cfg mit dem bereits oben genutzten Kommandozeilen-Editor nano. Haben Sie bei der Installation ein alternatives Verzeichnis für HAProxy angegeben, müssen Sie den Befehl natürlich entsprechend anpassen.
In der geöffneten Datei können Sie nun für die drei Sektionen „frontend“, „backend“ und „listen“ eine HTTP-Request-Direktive einfügen, die die unerwünschte Kopfzeile entfernt. Das Ergebnis sieht folgendermaßen aus:
frontend name
http-request del-header Proxy
…
backend name
http-request del-header Proxy
…
listen name
http-request del-header ProxySpeichern Sie die Änderungen ab und starten den HAProxy-Dienst neu:
sudo service haproxy restartNachdem Sie Ihre Proxy-Konfiguration mithilfe der aufgelisteten Schutzmöglichkeiten gegen HTTPoxy abgesichert haben, sollten Sie überprüfen, ob diese wie gewünscht greifen. Zu diesem Zweck gibt es Anwendungen wie das HTTPOXY Vulnerability Checking Tool von Luke Rehmann. Dieser kostenfrei nutzbare Webservice überprüft URLs auf die HTTPoxy-Schwachstelle, indem er eine HTTP-Anfrage inklusive Proxy-Header an die URLs verschickt, die auf einen alternativen Server umleitet. Erhält das Tool keine Antwort von diesem Server, wurde der Header erfolgreich blockiert.
Um den Service in Anspruch zu nehmen, müssen Sie einfach nur die URL der zu überprüfenden Webanwendung in das Eingabefeld einfügen und auf „Test“ klicken.
Das Thema Datensicherheit wird zunehmend wichtiger, sowohl im privaten als auch im professionellen Bereich. Als Website-Betreiber sollte man alle Vorkehrungen treffen, um den Besuch auf seiner Seite so sicher wie möglich zu machen und eine risikofreie Datenübertragung zu gewährleisten. Indem Sie Ihre Website auf HTTPS umstellen, absolvieren Sie den ersten Schritt zu mehr Sicherheit und einem...
Beim Ausfüllen eines Onlineformulars, beim Klick in den Warenkorb oder beim Kommentieren auf einem Blog – Nutzer kommen im Netz täglich mit Common Gateway Interfaces in Kontakt. Mit der Technologie lassen sich dynamische Funktionen umsetzen, während Server-Ressourcen geschont werden. Wie funktionert CGI, welche Vor- und Nachteile hat es und welche Alternativen stehen Entwicklern zur Verfügung?
Schnell, sicher und State-of-the-Art – nutzen Sie unsere starke Plattform für Ihre Kunden
