PHP, Python und andere Website-Anwendungen legen eine Remote-Proxy-Sicherheitslücke offen: httpoxy

[Shenzhen] Yuanchuanghui: 17.26 Uhr, der Partysaal wartet auf Sie.“

Hierbei handelt es sich um eine Sicherheitslücke, die auf CGI-Anwendungen in PHP, Go, Python und anderen Sprachen abzielt.

httpoxy ist der Name einer Familie von Schwachstellen, die sich auf Anwendungen auswirken, die CGI oder CGI-ähnlich ausgeführt werden. Vereinfacht ausgedrückt handelt es sich um ein Namespace-Konfliktproblem.

RFC 3875 (CGI) definiert, wie ProxyUmgebungsvariablen direkt aus dem Header der HTTP-Anfrage gefüllt werdenHTTP_PROXY
HTTP_PROXYIst eine Umgebungsvariable, die häufig zum Konfigurieren ausgehender Agenten verwendet wird

Dieser Fehler ermöglicht Remote-Angriffe. Wenn Sie ein PHP- oder CGI-Programm ausführen, sollten Sie den Proxy-Header sofort blockieren! sofort! Spezifische Anweisungen finden Sie weiter unten. httpoxy ist eine Sicherheitslücke in serverseitigen Webanwendungen. Wenn Sie diesen Code nicht serverseitig bereitstellen, müssen Sie sich keine Sorgen machen.

Was passiert, wenn meine Webanwendung diese Sicherheitslücke aufweist?

Wenn ein HTTP-Client, der diese Schwachstelle ausnutzt, eine Anfrage stellt, kann er:

Proxy-Anfragen an andere URLs über Ihre Webanwendung
Bitten Sie Ihren Server direkt, die angegebene Remote-Adresse und den angegebenen Port zu öffnen
Verschwenden Sie Serverressourcen und greifen Sie auf bestimmte Ressourcen für Angreifer zu

Die httpoxy-Sicherheitslücke lässt sich sehr einfach ausnutzen. Hoffentlich wird das Sicherheitspersonal diese Schwachstelle so schnell wie möglich scannen und schnell beheben.

Welche sind betroffen?

In folgenden Situationen können Sicherheitslücken bestehen:

Der Code wird in einem CGI-Kontext ausgeführt, der zu HTTP_PROXYeiner realen oder simulierten Umgebungsvariablen wird
Ein vertrauenswürdiger HTTP_PROXYHTTP-Client, der Proxy-Funktionalität unterstützt
Der Client initiiert innerhalb der Anfrage eine HTTP- (oder HTTPS-)Anfrage

Die folgenden Situationen sind Umgebungen, in denen dieser Fehler gefunden wurde:

Sprache	Umfeld	HTTP-Client
PHP	php-fpm mod_php	Fressen Sie 4+ Artax
Python	wsgiref.handlers.CGIHandler twisted.web.twcgi.CGIScript	Anfragen
Gehen	net/http/cgi	net/http

Es gibt sicherlich viele Sprachen und Umgebungen, bei denen wir keine Fehler festgestellt haben.

PHP

Ob der Fehler vorliegt, hängt von Ihrem Anwendungscode und Ihrer PHP-Bibliothek ab, aber die Auswirkungen scheinen sehr weitreichend zu sein
Solange eine Bibliothek mit diesem Fehler bei der Verarbeitung von Benutzeranfragen verwendet wird, kann sie ausgenutzt werden
Wenn Sie eine Bibliothek mit diesem Fehler verwenden, betrifft der Fehler jede PHP-Version
- Es kann sich sogar auf alternative PHP-Laufzeitumgebungen auswirken, wie z. B. HHVM, das im FastCGI-Modus bereitgestellt wird
Es ist bestätigt, dass Bibliotheken wie Guzzle und Artax betroffen sind, und möglicherweise sind noch viele weitere Bibliotheken betroffen.
- Guzzle 4.0.0rc2 und spätere Versionen sind betroffen, Guzzle 3 und niedrigere Versionen sind nicht betroffen
- Weitere Beispiele sind die StreamContextBuilder-Dienstprogrammklasse von Composer

Wenn Sie beispielsweise das Guzzle 6-Modul in Drupal verwenden, um ausgehende Anfragen zu initiieren (z. B. das Anfordern einer Wetter-API), weisen die vom Modul initiierten Anfragen diesen httpoxy-Fehler auf.

Python

Python-Code ist nur dann fehlerhaft, wenn er im CGI-Modus bereitgestellt wird. Im Allgemeinen verwendet der fehlerhafte Code wsgiref.handlers.CGIHandlereinen CGI-Controller wie
- Python-Webanwendungen, die auf normale Weise bereitgestellt werden, sind nicht betroffen (die meisten Leute verwenden WSGI oder FastCGI, diese beiden sind nicht betroffen), daher sind weitaus weniger Python-Anwendungen betroffen als PHP
- wsgi ist nicht betroffen, da os.environ nicht durch CGI-Daten kontaminiert ist
Die fehlerhafte Anforderungsbibliothek muss vertrauenswürdig sein und verwendet werden os.environ['HTTP_PROXY']. Sie führt keine Inhaltsprüfung durch

Gehen

Go-Code muss unter CGI bereitgestellt werden, um betroffen zu sein. Im Allgemeinen verwendet betroffener Code net/http/cgidas Paket
- Wie bei Python ist dies nicht die übliche Art, Go als Webanwendung bereitzustellen. Es gibt also nur sehr wenige Fälle, in denen es zu Beeinträchtigungen kommt
- Im Vergleich dazu legt das Go- net/http/fcgiPaket keine tatsächlichen Umgebungsvariablen fest und ist daher nicht betroffen
Die fehlerhafte net/httpVersion muss vertrauenswürdig sein und in ausgehenden Anfragen HTTP_PROXYohne Inhaltsprüfung verwendet werden

Reparier es jetzt

ProxyDie beste Lösung besteht darin, Anforderungsheader frühzeitig zu blockieren, bevor sie Ihre Anwendung angreifen . Es ist einfach und sicher.

Es gilt als sicher, da Proxyder Anforderungsheader nicht von der IETF definiert und nicht in der Nachrichtenheader-Registrierung der IANA aufgeführt ist . Dies weist darauf hin, dass die Verwendung dieses Headers nicht dem Standard entspricht und nicht einmal ad hoc verwendet wird
Standardkonforme HTTP-Clients und -Server sollten diesen Header niemals lesen oder senden
Sie können diesen Header aus der Anfrage entfernen oder Anfragen, die ihn verwenden, vollständig blockieren.
Sie können das Problem selbst beheben, wenn der Upstream keinen Patch veröffentlicht
- Durch die Prüfung eingehender HTTP-Anfragen können viele fehlerhafte Anwendungen auf einmal behoben werden
- Anwendungs-Culling hinter Reverse-Proxys und Anwendungs-Firewalls. ProxyAnforderungsheader sind sicher

ProxyWie Sie Anforderungsheader blockieren , hängt von Ihrer Konfiguration ab. Am einfachsten ist es, diesen Header in Ihrer Webanwendungs-Firewall oder direkt auf Apache und Nginx zu blockieren. Hier sind einige Hinweise dazu:

Nginx/FastCGI

Verwenden Sie die folgende Anweisung, um die an PHP-FPM und PHP-PM übergebenen Anforderungsheader zu blockieren. Diese Anweisung kann in fastcgi.conf oder fastcgi_param platziert werden (je nachdem, welche Konfigurationsdatei Sie verwenden):

fastcgi_param HTTP_PROXY "";

PHP ist im FastCGI-Modus fehlerhaft (die meisten anderen Sprachen, die Nginx FastCGI verwenden, sind jedoch nicht betroffen).

Apache

Für das konkrete Ausmaß der Auswirkungen auf Apache sowie andere Apache-Softwareprojekte wie Tomcat wird empfohlen, sich auf die offizielle Ankündigung der Apache Software Foundation zu beziehen . Hier einige Kernbotschaften:

Wenn Sie den Apache-HTTP-Server verwenden, mod_cgium in Go oder Python geschriebene Skripte auszuführen, sind diese betroffen (wobei HTTP_PROXYdie Umgebungsvariablen „echt“ sind). Da mod_phpes in PHP-Skripten verwendet wird, besteht dieser Fehler auch.

Wenn Sie das Modul mod_headers verwenden , können Sie ProxyAnforderungsheader vor der weiteren Verarbeitung der Anforderung mit der folgenden Konfiguration zurücksetzen:

RequestHeader unset Proxy early

Wenn Sie das Modul mod_security verwenden , können Sie eine SecRuleRegel verwenden, um ProxyAnfragen mit Anfrageheadern abzulehnen. Hier ist ein Beispiel. Stellen Sie sicher, dass SecRuleEnginees aktiviert ist. Sie können es entsprechend Ihrer eigenen Situation anpassen.

SecRule &REQUEST_HEADERS:Proxy "@gt 0" "id:1000005,log,deny,msg:'httpoxy denied'"

Wenn Sie schließlich Apache Traffic Server verwenden, ist dieser selbst nicht betroffen. Sie können damit jedoch den Proxy-Anforderungsheader entfernen, um andere Dienste dahinter zu schützen. Weitere Informationen finden Sie in der ASF-Anleitung .

HAProxy

Entfernen Sie den Anforderungsheader durch die folgende Konfiguration:

http-request del-header Proxy

Lack

Um diesen Header zu löschen, fügen Sie ihn bitte in den vorhandenen vcl_recv-Abschnitt ein:

sub vcl_recv {
    [...]
    unset req.http.proxy;
    [...]
}

OpenBSD weitergeleitet

Verwenden Sie die folgende Anweisung, um diesen Header zu entfernen. Fügen Sie es in einen vorhandenen Filter ein:

http protocol httpfilter {
    match request header remove "Proxy"
}

lighttpd (<= 1.4.40)

Bounces- ProxyAnfragen, die Header enthalten.

Erstellen Sie eine /path/to/deny-proxy.luaDatei und machen Sie sie für lighttpd schreibgeschützt mit folgendem Inhalt:

if (lighty.request["Proxy"] == nil) then return 0 else return 403 end

Ändern Sie es , um das Modul lighttpd.confzu laden und den obigen Lua-Code auszuführen:mod_magnet

server.modules += ( "mod_magnet" )
magnet.attract-raw-url-to = ( "/path/to/deny-proxy.lua" )

lighttpd2 (in Entwicklung)

ProxyHeader aus Anfragen entfernen. Fügen Sie die folgende Anweisung hinzu lighttpd.conf:

req_header.remove "Proxy";

Die clientseitige PHP-Korrektur hat keine Auswirkung

Es gibt keine benutzerseitigen Korrekturen zur Behebung des Fehlers. Machen Sie sich also keine Sorgen:

Die Verwendung unset($_SERVER['HTTP_PROXY'])hat keinen Einfluss getenv()auf den zurückgegebenen Wert und ist daher nutzlos
Die Verwendung putenv('HTTP_PROXY=')hat keine Auswirkung (putenv kann nur Werte aus tatsächlichen Umgebungsvariablen beeinflussen, nicht aus Anforderungsheadern).

Geschichte von httpoxy

Die Sicherheitslücke wurde erstmals vor 15 Jahren entdeckt.

Im März 2001 entdeckte Randal L. Schwartz diesen Fehler in libwww-perl und behob ihn.

Im April 2001 entdeckte Cris Bailiff diesen Fehler in Curl und behob ihn.

Der Fehler wurde von Akira Tanaka vom Ruby-Team im Juli 2012 bei der Implementierung Net::HTTPvon entdecktHTTP_PROXY

Der Fehler wurde im November 2013 auf der Nginx-Mailingliste erwähnt. Der Entdecker Jonathan Matthews war sich nicht so sicher, aber es stellte sich heraus, dass er recht hatte.

Stefan Fritsch erwähnte es im Februar 2015 auf der Apache httpd-dev-Mailingliste.

Der Fehler wurde im Juli 2016 von Scott Geary vom Vend-Sicherheitsteam entdeckt und betrifft viele moderne Programmiersprachen und Bibliotheken wie PHP.

Dieser Fehler schlummerte also seit vielen Jahren und viele Menschen haben seine Existenz in verschiedenen Aspekten entdeckt, aber seine Auswirkungen auf andere Sprachen und Bibliotheken nicht berücksichtigt. Sicherheitsforscher haben eigens zu diesem Zweck eine Website eingerichtet: https://httpoxy.org/ , auf der Sie mehr erfahren können.