# HTTPoxy

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](https://www.ionos.de/digitalguide/hosting/hosting-technik/was-ist-http/ "Was ist 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](https://www.ionos.de/digitalguide/websites/web-entwicklung/was-ist-ein-cgi/ "Was ist ein CGI?")) 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.

## Was ist HTTPoxy?

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](https://www.ionos.de/digitalguide/hosting/hosting-technik/http-request-erklaert/ "HTTP-Request erklärt") 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.

## Eine ewige Sicherheitslücke?

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](https://www.ionos.de/digitalguide/server/tools/einstieg-in-curl-in-linux/ "Einstieg in cURL in Linux") 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](https://www.ionos.de/digitalguide/websites/web-entwicklung/was-ist-eine-laufzeitumgebung/ "Was ist eine 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:

- CVE-2016-5385: PHP
- CVE-2016-5386: Go CVE-2016-5387: Apache HTTP Server
- CVE-2016-5388: Apache Tomcat
- CVE-2016-6286: spiffy-cgi-handlers for CHICKEN
- CVE-2016-6287: CHICKEN’s http-client
- CVE-2016-1000104: mod\_fcgi
- CVE-2016-1000105: Nginx cgi script
- CVE-2016-1000107: Erlang inets
- CVE-2016-1000108: YAWS
- CVE-2016-1000109: HHVM FastCGI
- CVE-2016-1000110: Python CGIHandler
- CVE-2016-1000111: Python Twisted
- CVE-2016-1000212: lighttpd

## So schützen Sie sich und Ihren Server vor HTTPoxy

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](https://www.ionos.de/digitalguide/websites/webseiten-erstellen/wie-stelle-ich-meine-seite-auf-ssl-und-https-um/) 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:

1. Sie filtern den Proxy-Header aus allen eingehenden Pakten heraus.
2. Sie blockieren automatisch alle eingehenden Pakete, die einen Proxy-Header enthalten.

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**.

### HTTPoxy mit Apache umgehen

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](https://www.ionos.de/digitalguide/server/knowhow/debian-die-universelle-system-software/ "Debian – die universelle System-Software"):

Im ersten Schritt gilt es, das **Modul zu aktivieren**, was Sie mit dem folgenden Befehl erledigen:

```none
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:

```none
sudo nano /etc/apache2/apache2.conf
```

Erweitern Sie diese Datei nun am Ende um den folgenden Eintrag:

```none
<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:

```none
sudo a2enconf httpoxy
sudo service apache2 restart
```

**CentOS 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:

```none
sudo nano /etc/httpd/conf/httpd.conf
```

In diese fügen Sie am Ende den neuen Eintrag

```none
RequestHeader unset Proxy early
```

ein. Abschließend speichern Sie die Änderungen und führen einen [Neustart des Apache-Servers](https://www.ionos.de/digitalguide/server/konfiguration/apache-neustart/) durch:

```none
sudo service httpd restart
```

### HTTP-Proxy-Header mit NGINX entfernen

NGINX 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:

```none
echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi.conf
echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi_params
```

Sofern 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:

```none
echo 'proxy_set_header Proxy "";' | sudo tee -a /etc/nginx/proxy_params
```

Im letzten Schritt starten Sie NGINX mit diesem Befehl neu:

```none
sudo service nginx restart
```

**CentOS 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:

```none
echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi.conf
echo 'fastcgi_param HTTP_PROXY "";' | sudo tee -a /etc/nginx/fastcgi_params
```

Um 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:

```none
sudo grep -r "proxy_pass" /etc/nginx
```

Sie erhalten eine Auflistung der Textdateien, in denen die **Direktive** aufgeführt wird, wobei die Ausgabe in etwa wie in dem folgenden Beispiel aussieht:

```none
/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:

```none
proxy_pass http://127.0.0.1;
proxy_set_header Proxy "";
```

Zum Abschluss steht in beiden Fällen der **Neustart des Servers** an:

```none
sudo service nginx restart
```

### So sichern Sie HAProxy-Server gegen HTTPoxy ab

Wenn 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:

```none
sudo nano /etc/haproxy/haproxy.cfg
```

Auf 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:

```none
frontend name
    http-request del-header Proxy
…
backend name
    http-request del-header Proxy
…
listen name
    http-request del-header Proxy
```

Speichern Sie die Änderungen ab und starten den HAProxy-Dienst neu:

```none
sudo service haproxy restart
```

### Sicherheits-Check mit dem HTTPOXY Vulnerability Checking Tool

Nachdem 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](https://httpoxy.rehmann.co/ "Webprojekt auf HTTPoxy-Schwachstelle überprüfen mit dem 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.

[![Bild: Web-Tool HTTPOXY Vulnerability Checking Tool](https://www.ionos.de/digitalguide/fileadmin/_processed_/3/5/csm_httpoxy-vulnerability-checking-tool_b065944e1e.webp "Web-Tool HTTPOXY Vulnerability Checking Tool")](https://www.ionos.de/digitalguide/fileadmin/DigitalGuide/Screenshots/httpoxy-vulnerability-checking-tool.jpg) Web-Tool HTTPOXY Vulnerability Checking Tool 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.


This is a markdown version of: [https://www.ionos.de/digitalguide/server/konfiguration/httpoxy-das-steckt-hinter-der-cgi-schwachstelle/](https://www.ionos.de/digitalguide/server/konfiguration/httpoxy-das-steckt-hinter-der-cgi-schwachstelle/) for AI/LLM consumption.