Gunicorn: Möglichkeit zum Maskieren des HTTP-Antwortheaders Serverattribut

Normalerweise wird gunicorn hinter einem Reverse-Proxy-Server wie nginx in einer Produktionsumgebung bereitgestellt, und nginx würde sein eigenes Server Tag ausgeben.

oben plus eins

mit @benoitc können wir eine Option auf der Kommandozeile vorschlagen, was meint ihr? andernfalls schließen wir dieses Ticket wie von @georgexsh erklärt, im Produktionsmodus können Sie einen Reverse-Proxy (nginx, apache, ...) verwenden.

Könnte man nicht einfach die Umgebung in einem post_request Hook ändern?

@tilgovi , das würde funktionieren, denke ich ... bin mir dann nicht sicher, ob wir eine andere Option erstellen müssen ...

Funktioniert nicht. Die Anfrage wird bereits zu diesem Zeitpunkt gesendet.

Die Middleware Server in den Standardheadern enthalten ist.

Was ist, wenn wir einfach den Server-Header ganz entfernen?

+1

Wenn wir Ihnen erlauben, den Wert des Headers auf eine zufällige Zeichenfolge festzulegen, sollten wir Ihnen auch erlauben, den Header vollständig zu entfernen.

+1

Warum willst du die Kopfzeile entfernen?

In der Vergangenheit habe ich den Header aus Bereitstellungen entfernt, um die Serversoftware und -version zu verbergen, damit sie nicht von jemandem erkannt werden, der mit einem bekannten Exploit nach Servern kriecht.

Jep. Sicherheit ist einer der Gründe. Natürlich können Sie den Server in einen zufälligen Wert ändern, aber warum sollten Sie zusätzliche Bytes senden, die nicht wirklich erforderlich sind?

Ich habe mir erlaubt, eine PR für dieses Feature zu machen: #1384 . Es steht schon seit einiger Zeit auf meiner Fahndungsliste.

Um die Diskussion zu ergänzen: Ich würde argumentieren, dass, während einige Reverse-Proxy-Server den Server Header ändern, andere einen Via Header hinzufügen, wie in https://www.w3.org/Protocols/ beschrieben. rfc2616/rfc2616-sec14.html#sec14.38

Leider hat @mathiasverhoeven seine PR aus irgendeinem Grund geschlossen und hatte in letzter Zeit keine Aktivität.

Wäre es unmöglich, hier eine allgemeinere Option zu haben, wie in --set-headers wo Sie eine beliebige Anzahl von Headern als Schlüssel-Wert-Paare angeben können? Ein leerer Wert würde den Header komplett weglassen.

Im Moment möchte ich Server anpassen, aber ich möchte auch einen weiteren Antwortheader hinzufügen, zB X-Product: MyProduct .

Ich kann basierend auf der PR von @mathiasverhoeven etwas zusammenwerfen. @benoitc und @tilgovi was denkst du?

Lass das einfach hier: https://www.fastly.com/blog/headers-we-dont-want. Wie Sie im Artikel lesen können, ist der Header Server sowohl sehr verbreitet als auch völlig unnötig.

Ich würde auch gerne den Server-Header weglassen können. Ich verwende einen sicherheitsfokussierten Webserver namens Hiawatha, um den Proxy umzukehren, der so eingestellt ist, dass kein eigener Server-Header hinzugefügt wird.

Die Idee von @tuukkamustonen klingt für mich gut. :)

Edit: gerade gesehen https://github.com/benoitc/gunicorn/pull/1617. server_tokens = true|false|string wäre toll.

Läuft jemand Flask? https://stackoverflow.com/a/46858238/452210 schlägt vor, process_response umschließen und zu überschreiben und den Header zu ersetzen oder zu entfernen.

Ich würde auch gerne den Server-Header weglassen können. Ich verwende einen sicherheitsfokussierten Webserver namens Hiawatha, um den Proxy umzukehren, der so eingestellt ist, dass kein eigener Server-Header hinzugefügt wird.

Mir ist aufgefallen, dass sogar Cloudflare einen Server-Header anzeigt, daher bin ich mir heutzutage nicht sicher, warum es mehr um Sicherheit als um Ruhm geht.

Ich denke, anstatt der Befehlszeile oder Konfiguration eine weitere Option hinzuzufügen, würde ich zunächst die Version einfach aus dem Header entfernen. Fügen Sie dann eine Einstellung nur für die Konfigurationsdatei hinzu, um das server_token zu entfernen. Der Vorteil besteht darin, dass der Server, der ordnungsgemäß auf die neue Version aktualisiert wird, diese Einstellung hinzufügen kann, ohne den Dienst zu stoppen. Die Gedanken?

Mir ist aufgefallen, dass sogar Cloudflare einen Server-Header anzeigt, daher bin ich mir heutzutage nicht sicher, warum es mehr um Sicherheit als um Ruhm geht.

Ich denke, der Service- und Server-Header von Cloudflare hat einen anderen Kontext als der Server einer einzelnen Site. Wenn eine Site über Cloudflare einen Reverse-Proxy erhält, ist die Tatsache, dass Cloudflare das Proxying durchführt, nicht unbekannt. es ist offensichtlich über Nameserver und / oder IP-Adresse usw. Im Gegensatz dazu gibt mir das Hosten einer Site auf einem VPS ohne Reverse-Proxy von Drittanbietern möglicherweise die Hoffnung, zumindest eine direkte Identifizierung über den HTTP-Header der Serversoftware zu vermeiden. (Der Gedanke ist natürlich, dass es schwieriger sein sollte, Ziele zu finden, als nur nach seinem Server-Header zu suchen, wenn in Zukunft eine Schwachstelle von Gunicorn festgestellt wird.)

Ich denke, anstatt der Befehlszeile oder Konfiguration eine weitere Option hinzuzufügen, würde ich zunächst die Version einfach aus dem Header entfernen. Fügen Sie dann eine Einstellung nur für die Konfigurationsdatei hinzu, um das server_token zu entfernen. Der Vorteil besteht darin, dass der Server, der ordnungsgemäß auf die neue Version aktualisiert wird, diese Einstellung hinzufügen kann, ohne den Dienst zu stoppen. Die Gedanken?

Das wäre toll. :+1: :leicht_lächelndes_Gesicht:

Ja, bitte entfernen Sie zumindest die Version. Version trägt nichts zum Ruhm bei und spart Angreifern viel Zeit.

Ich überlege, die Version einfach zu entfernen. @tilgovi irgendwelche Gedanken dazu?

Gut für mich!

Gibt es diesbezüglich Fortschritte? Dies scheint ein schneller Gewinn für die Sicherheit zu sein.

das wird Teil der nächsten 20.1

Ich überlege, die Version einfach zu entfernen.

Ist die Einstellung "Nur Konfigurationsdatei" zum Entfernen des Server-Headers insgesamt noch geplant?

@DavidOliver warum die Frage?

@benoitc Ihr Kommentar, den ich zitiert habe, könnte so interpretiert werden, dass "nur" / nur die Versionsnummer entfernt wird, während früher in der Unterhaltung die Einstellung zum Entfernen des Server-Headers insgesamt (was ich gerne tun würde) war in Betracht gezogen wird.

Danke.

Wenn wir nur den Server-Header ganz entfernen können, sollten wir dies tun.

Ich muss immer noch davon überzeugt sein, dass das Entfernen etwas mit dem zu tun hat
Sicherheit. In den letzten 10 Jahren war das kein Thema. Sicherheit durch
Unklarheit hilft auch nicht, ich wüsste lieber, dass wir ein Problem haben und
repariere es. Auch die Kenntnis des Servers kann den Betrieb unterstützen

Ich bin geneigt, die Version im Moment zu entfernen, da diese Version gibt
zu viele Informationen darüber, wie der Server gewartet wird. Wir sollten es tun für
jede Filiale, die wir gepflegt haben.

Die Gedanken?

Benoît

Am Sonntag, 29. Dezember 2019 um 04:23 Uhr schrieb Randall Leeds [email protected] :

Wenn wir nur den Server-Header ganz entfernen können, sollten wir dies tun.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/benoitc/gunicorn/issues/825?email_source=notifications&email_token=AAADRIQBGN2KQRKOKLAYK43Q3AJ2PA5CNFSM4ASCOWF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBWLOW63LNMVXHJKTcom
oder abmelden
https://github.com/notifications/unsubscribe-auth/AAADRISEUFGD43CKXLV3EZTQ3AJ2PANCNFSM4ASCOWFQ
.

>

Von meinem Handy gesendet

Hallo,

Ich verwende Gunicorn, um Antworten über eine Verbindung bereitzustellen, bei der Daten
ist teuer, alles, was ich entfernen kann, muss ich nicht bezahlen.

Der Server-Header ist klein, aber kleine Dinge summieren sich und manchmal
kleine Dinge bedeuten, dass Sie alles in einem Paket unterbringen können: die
Server-Header mit Version ist 24 Byte, etwa 1,7% der Nutzlast
mit einem MSS von 1460 und TLS-Headern. Auch ohne das zusätzliche Paket,
ein größeres Paket muss mit größerer Wahrscheinlichkeit vollständig erneut gesendet werden
wenn die Verbindung schlecht ist (wie ein Mobilfunknetz an einem entfernten Ort).

Bei einer neuen HTTPS-Verbindung, Handshake und Zertifikat
Austausch machen das meiste aus der Nutzlast und kleine Dinge können sein
ignoriert. Für kleine wiederholte Anfragen mit Keep-Alive, redundant
Header werden zu einem viel größeren Teil der Anfrage/Antwort.

Dies könnte auch für Leute von Bedeutung sein, denen der Kunde mehr am Herzen liegt
Leistung (Latenz mehr als Durchsatz) als Kosten.

Für diesen Anwendungsfall ist die nützlichste Option, in der Lage zu sein,
Entfernen Sie den Header vollständig, nicht nur den Wert
oder der Versionsteil.

Dieser Kommentar beschränkt sich hauptsächlich auf das Hinzufügen relevanter Referenz-/Spezifikations-/RFC-Informationen und (hoffentlich) größtenteils uneinsichtige Interpretationen/Kommentare.

RFC7231 Hypertext Transfer Protocol (HTTP/1.1): Semantik und Inhalt https://tools.ietf.org/html/rfc7231#section -7.4.2

...Ein Ursprungsserver KANN in seinen Antworten ein Serverfeld generieren.

Ein Ursprungsserver SOLLTE KEIN Serverfeld generieren, das unnötig detaillierte Details enthält und das Hinzufügen von Unterprodukten durch Dritte einschränken. Zu lange und detaillierte Serverfeldwerte erhöhen die Antwortlatenz und offenbaren möglicherweise interne Implementierungsdetails, die es Angreifern (etwas) leichter machen, bekannte Sicherheitslücken zu finden und auszunutzen.

https://tools.ietf.org/html/rfc7231#section -9.6

9.6. Offenlegung von Produktinformationen
Die Header-Felder User-Agent (Abschnitt 5.5.3), Via (Abschnitt 5.7.1 von [RFC7230]) und Server (Abschnitt 7.4.2) geben oft Informationen über die Softwaresysteme des jeweiligen Absenders preis. Theoretisch kann dies einem Angreifer das Ausnutzen bekannter Sicherheitslücken erleichtern; In der Praxis neigen Angreifer dazu, alle potenziellen Lücken auszuprobieren, unabhängig von den offensichtlich verwendeten Softwareversionen. Proxys, die als Portal durch eine Netzwerk-Firewall dienen, sollten besondere Vorkehrungen bezüglich der Übertragung von Header-Informationen treffen, die Hosts hinter der Firewall identifizieren könnten. Das Via-Header-Feld ermöglicht es Vermittlern, sensible Maschinennamen durch Pseudonyme zu ersetzen.

Von (veraltet) RFC2616:

15.1.2 Übertragung sensibler Informationen
Wie jedes generische Datenübertragungsprotokoll kann HTTP weder den Inhalt der übertragenen Daten regulieren, noch gibt es eine a priori Methode zur Bestimmung der Sensibilität einer bestimmten Information im Kontext einer bestimmten Anfrage. Daher SOLLTEN Anwendungen dem Anbieter dieser Informationen so viel Kontrolle wie möglich über diese Informationen geben. Besonders hervorzuheben sind in diesem Zusammenhang vier Header-Felder: Server, Via, Referer und From.
Das Aufdecken der spezifischen Softwareversion des Servers kann dazu führen, dass der Servercomputer anfälliger für Angriffe auf Software wird, die bekanntermaßen Sicherheitslücken enthält. Implementierer SOLLTEN das Server-Header-Feld zu einer konfigurierbaren Option machen.

PEP3333 Python-Webserver-Gateway-Schnittstelle v1.0.1 https://www.python.org/dev/peps/pep-3333/#the -start-response-callable

Im Allgemeinen ist der Server oder das Gateway dafür verantwortlich, dass die korrekten Header an den Client gesendet werden: Wenn die Anwendung einen von HTTP (oder anderen relevanten Spezifikationen, die gültig) erforderlichen Header auslässt, muss der Server oder das Gateway diesen hinzufügen. Beispielsweise werden die HTTP-Header Date: und Server: normalerweise vom Server oder Gateway bereitgestellt.

• Der Server-Response-Header ist gemäß HTTP 1.1 optional
• Der RFC erkennt an, dass übermäßig detaillierte Serverfelder das Durchsuchen von Sites nach anfälligen Servern erleichtern können. Offensichtlich ist dies eine Vorkehrung, die es einen Schritt schwerer macht, und wie viele Details zu viel sind, ist umständlich.
• Das veraltete HTTP 1.1 RFC2616 ist im Wert des Ausblendens des Server-Headers etwas kühner.
• PEP3333 scheint leicht zu überschreiten, wenn der Server-Header im Kontext erforderlicher oder normaler Header erwähnt wird.

Viele Meinungen dazu, wie zum Beispiel in Apache HTTPD ServerTokens : https://httpd.apache.org/docs/2.4/mod/core.html#servertokens

Das Festlegen von ServerTokens auf weniger als minimal wird nicht empfohlen, da es das Debuggen von Interoperationsproblemen erschwert. Beachten Sie auch, dass das Deaktivieren des Server: Headers überhaupt nichts dazu beiträgt, Ihren Server sicherer zu machen. Die Idee von "Sicherheit durch Dunkelheit" ist ein Mythos und führt zu einem falschen Sicherheitsgefühl.

Den Server-Header so zu ändern, dass er nur gunicorn sagt, ist eine praktische Lösung, und ich denke, wir sollten dies ohne Konfiguration tun.

Leute wie @kmichel-sereema, die die Größe jedes Transfers optimieren wollen, sind meiner Meinung nach nicht der richtige Ort für eine solche Mikrooptimierung. Wenn die HTTP-Header zu viel Overhead haben, ist HTTP 1.x nicht das ideale Protokoll, und ich denke, wir sollten keine zusätzliche Konfiguration hinzufügen, um das Ändern oder Deaktivieren des Server-Headers zu ermöglichen.

Der Vorschlag von @tilgovi scheint mir ein guter Kompromiss zu sein.

In vielen Umgebungen kann dies sogar strittig sein. In den Bereitstellungsdokumenten von gunicorn wird empfohlen, einen Proxy-Server wie nginx vor gunicorn zu haben. nginx entfernt automatisch den Server-Antwort-Header vom Proxy-Server, bevor er an den Client geht, und kann so konfiguriert werden, dass weitere Header entfernt werden. Sicherlich können sicherheitsorientierte Proxys dasselbe tun.

nach meinem Vorschlag und Kommentaren von @tilgovi & @jamadden schließe ich diese Ausgabe zugunsten von #2233. Danke an alle für den Code und die Kommentare!