Gunicorn: Possibilité de masquer l'attribut serveur d'en-tête de réponse http

Généralement, gunicorn est déployé derrière un serveur proxy inverse comme nginx dans un environnement de production, et nginx produirait sa propre balise Server .

à l'étage plus un

avec @benoitc on peut proposer une option en ligne de commande, qu'en pensez vous ? sinon, nous fermerons ce ticket comme expliqué par @georgexsh , en mode production, vous pouvez utiliser un reverse proxy (nginx, apache, ...).

Ne pourrait-on pas simplement modifier l'environ dans un crochet post_request ?

@tilgovi cela fonctionnerait je suppose... je ne sais pas si nous devons créer une autre option...

Ne fonctionne pas. La demande est déjà envoyée à ce stade.

Le middleware Server est dans les en-têtes par défaut.

Et si nous supprimions simplement l'en-tête Server ?

+1

Si nous vous permettons de définir la valeur de l'en-tête sur une chaîne aléatoire, nous devrions également vous permettre de supprimer complètement l'en-tête.

+1

pourquoi veux-tu supprimer l'en-tête ?

Dans le passé, j'ai supprimé l'en-tête des déploiements pour masquer le logiciel et la version du serveur afin qu'il ne soit pas récupéré par une personne cherchant des serveurs avec un exploit connu.

Ouais. La sécurité est l'une des raisons. Bien sûr, vous pouvez changer la Server en quelque chose d'aléatoire, mais pourquoi envoyer des octets supplémentaires qui ne sont pas vraiment nécessaires ?

J'ai pris la liberté de faire un PR pour cette fonctionnalité : #1384 . Il est sur ma liste de personnes recherchées depuis un certain temps.

Pour ajouter à la discussion : je dirais que si certains serveurs proxy inverses modifient l'en-tête Server , certains ajoutent un en-tête Via comme décrit dans https://www.w3.org/Protocols/ rfc2616/rfc2616-sec14.html#sec14.38

Malheureusement, @mathiasverhoeven a fermé ses relations publiques pour une raison quelconque et n'a pas eu d'activité ces derniers temps.

Serait-il impossible d'avoir une option plus générique ici, comme dans --set-headers où vous pouvez spécifier n'importe quel nombre d'en-têtes en tant que paires clé-valeur ? Une valeur vide omettrait complètement l'en-tête.

Pour le moment, j'aimerais ajuster Server , mais j'aimerais également ajouter un autre en-tête de réponse, par exemple X-Product: MyProduct .

Je peux organiser quelque chose sur la base des relations publiques de @benoitc et @tilgovi qu'en pensez-vous ?

Je vais juste laisser ça ici : https://www.fastly.com/blog/headers-we-dont-want. Comme vous pouvez le lire dans l'article, l'en-tête Server est à la fois très courant ET totalement inutile.

J'aimerais également pouvoir omettre l'en-tête Server. J'utilise un serveur Web axé sur la sécurité appelé Hiawatha pour inverser le proxy, configuré pour ne pas ajouter son propre en-tête de serveur, donc l'en-tête de serveur de gunicorn est actuellement transmis aux clients.

L'idée de @tuukkamustonen me semble bonne. :)

Edit : je viens de voir https://github.com/benoitc/gunicorn/pull/1617. server_tokens = true|false|string serait génial.

Quelqu'un utilise Flask ? https://stackoverflow.com/a/46858238/452210 suggère d'envelopper et de remplacer process_response , en remplaçant ou en supprimant l'en-tête.

J'aimerais également pouvoir omettre l'en-tête Server. J'utilise un serveur Web axé sur la sécurité appelé Hiawatha pour inverser le proxy, configuré pour ne pas ajouter son propre en-tête de serveur, donc l'en-tête de serveur de gunicorn est actuellement transmis aux clients.

J'ai remarqué que même cloudflare affiche un en-tête de serveur, donc je ne sais pas ces jours-ci en quoi il s'agit plus de sécurité que de renommée.

Je pense que plutôt que d'ajouter une autre option à la ligne de commande ou à la configuration, je supprimerais simplement la version de l'en-tête pour commencer. Ajoutez ensuite un paramètre de fichier de configuration uniquement pour supprimer le server_token. L'avantage est que le serveur effectuant une mise à niveau progressive vers la nouvelle version pourra ajouter ce paramètre sans arrêter le service. Les pensées?

J'ai remarqué que même cloudflare affiche un en-tête de serveur, donc je ne sais pas ces jours-ci en quoi il s'agit plus de sécurité que de renommée.

Je pense que l'en-tête du service et du serveur de Cloudflare a un contexte différent de celui du serveur d'un site individuel. Lorsqu'un site fait l'objet d'un proxy inverse via Cloudflare, le fait que ce soit Cloudflare qui effectue le proxy n'est pas autrement inconnu ; cela se voit via les serveurs de noms et/ou l'adresse IP, etc. En revanche, le fait que j'héberge un site sur un VPS sans proxy inverse tiers me donne potentiellement un espoir d'éviter au moins une identification directe via l'en-tête HTTP du logiciel serveur. (L'idée étant, bien sûr, que s'il s'avère à l'avenir que gunicorn présente une certaine vulnérabilité, il devrait être plus difficile de trouver des cibles que de simplement rechercher son en-tête de serveur.)

Je pense que plutôt que d'ajouter une autre option à la ligne de commande ou à la configuration, je supprimerais simplement la version de l'en-tête pour commencer. Ajoutez ensuite un paramètre de fichier de configuration uniquement pour supprimer le server_token. L'avantage est que le serveur effectuant une mise à niveau progressive vers la nouvelle version pourra ajouter ce paramètre sans arrêter le service. Les pensées?

Ce serait génial. :+1: :slightly_smiliing_face:

Oui, veuillez au moins supprimer la version. La version n'ajoute rien à la renommée et fait gagner beaucoup de temps aux attaquants.

Je pense juste supprimer la version. @tilgovi des pensées à ce sujet?

Bien pour moi !

Des progrès sur celui-ci ? Cela semble être une victoire rapide pour la sécurité.

qui fera partie du prochain 20.1

Je pense juste supprimer la version.

Le paramètre de fichier de configuration uniquement pour supprimer complètement l'en-tête du serveur est-il toujours prévu ?

@DavidOliver pourquoi la question ?

@benoitc Votre commentaire que j'ai cité pourrait être interprété comme signifiant que c'est "juste"/seulement le numéro de version qui sera supprimé, alors que plus tôt dans la conversation, le paramètre pour supprimer complètement l'en-tête du serveur (ce que j'aimerais faire) était être considéré.

Merci.

Si nous pouvons simplement supprimer complètement l'en-tête du serveur, nous devrions le faire.

Je dois encore être convaincu que le retirer a quelque chose à voir avec le
Sécurité. Cela n'a pas été un problème au cours des 10 dernières années. Sécurité par
l'obscurité n'aide pas non plus, je préférerais savoir que nous avons un problème et
répare le. Connaître également le serveur peut aider les opérations

Je suis enclin à supprimer la version pour le moment car cette version donne
trop d'informations sur la façon dont le serveur est maintenu. Nous devrions le faire pour
chaque branche que nous entretenions.

Les pensées?

Benoît

Le dimanche 29 décembre 2019 à 04:23 Randall Leeds [email protected] a écrit :

Si nous pouvons simplement supprimer complètement l'en-tête du serveur, nous devrions le faire.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/benoitc/gunicorn/issues/825?email_source=notifications&email_token=AAADRIQBGN2KQRKOKLAYK43Q3AJ2PA5CNFSM4ASCOWF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LN5MVXH2ZJKTDNE
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AAADRISEUFGD43CKXLV3EZTQ3AJ2PANCNFSM4ASCOWFQ
.

>

Envoyé depuis mon mobile

Salut,

J'utilise gunicorn pour servir des réponses sur une connexion où les données
coûte cher, tout ce que je peux enlever est tout ce que je n'ai pas à payer.

L'en-tête du serveur est petit, mais les petites choses s'additionnent, et parfois
petites choses signifie que vous pouvez tout ranger dans un paquet de moins : le
l'en-tête du serveur avec la version est de 24 octets, environ 1,7% de la charge utile
avec un MSS de 1460 et des en-têtes TLS. Même sans le paquet supplémentaire,
un paquet plus volumineux est beaucoup plus susceptible de devoir être entièrement renvoyé
lorsque la connexion est mauvaise (comme un réseau cellulaire dans un endroit distant).

Sur une nouvelle connexion HTTPS, la poignée de main et le certificat
l'échange fait la plupart de la charge utile et les petites choses peuvent être
ignoré. Pour les petites demandes répétées utilisant keep-alive, redondant
les en-têtes deviennent une partie beaucoup plus importante de la demande/réponse.

Cela peut également être important pour les personnes qui se soucient davantage du client
performances (latence supérieure au débit) que coût.

Pour ce cas d'utilisation, l'option la plus utile est de pouvoir
supprimer entièrement l'en-tête, pas simplement supprimer la valeur
ou la partie version.

Ce commentaire est principalement limité à l'ajout d'informations de référence/spécifications/RFC pertinentes, et (espérons-le) pour la plupart des interprétations/commentaires sans opinion.

Protocole de transfert hypertexte RFC7231 (HTTP/1.1) : sémantique et contenu https://tools.ietf.org/html/rfc7231#section -7.4.2

... Un serveur d'origine PEUT générer un champ Server dans ses réponses.

Un serveur d'origine NE DEVRAIT PAS générer un champ Serveur contenant des détails inutilement fins et DEVRAIT limiter l'ajout de sous-produits par des tiers. Des valeurs de champ de serveur trop longues et détaillées augmentent la latence de réponse et révèlent potentiellement des détails de mise en œuvre internes qui pourraient permettre (légèrement) aux attaquants de trouver et d'exploiter les failles de sécurité connues.

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

9.6. Divulgation des informations sur le produit
Les champs d'en-tête User-Agent (Section 5.5.3), Via (Section 5.7.1 de [RFC7230]) et Server (Section 7.4.2) révèlent souvent des informations sur les systèmes logiciels de l'expéditeur respectif. En théorie, cela peut permettre à un attaquant d'exploiter plus facilement les failles de sécurité connues ; dans la pratique, les attaquants ont tendance à essayer toutes les failles potentielles, quelles que soient les versions logicielles apparentes utilisées. Les proxys qui servent de portail à travers un pare-feu réseau doivent prendre des précautions particulières concernant le transfert des informations d'en-tête qui pourraient identifier les hôtes derrière le pare-feu. Le champ d'en-tête Via permet aux intermédiaires de remplacer les noms de machines sensibles par des pseudonymes.

De (obsolète) RFC2616 :

15.1.2 Transfert d'informations sensibles
Comme tout protocole générique de transfert de données, HTTP ne peut pas réguler le contenu des données transférées, et il n'y a pas non plus de méthode a priori pour déterminer la sensibilité d'une information particulière dans le contexte d'une requête donnée. Par conséquent, les applications DEVRAIENT fournir autant de contrôle que possible sur ces informations au fournisseur de ces informations. Quatre champs d'en-tête méritent une mention particulière dans ce contexte : Server, Via, Referer et From.
La révélation de la version logicielle spécifique du serveur peut permettre à la machine serveur de devenir plus vulnérable aux attaques contre les logiciels connus pour contenir des failles de sécurité. Les implémenteurs DEVRAIENT faire du champ d'en-tête Server une option configurable.

PEP3333 Interface de passerelle de serveur Web Python v1.0.1 https://www.python.org/dev/peps/pep-3333/#the -start-response-callable

En général, le serveur ou la passerelle est chargé de s'assurer que les en-têtes corrects sont envoyés au client : si l'application omet un en-tête requis par HTTP (ou d'autres spécifications pertinentes en vigueur), le serveur ou la passerelle doit l'ajouter. Par exemple, les en-têtes HTTP Date : et Server : seraient normalement fournis par le serveur ou la passerelle.

• L'en-tête de réponse du serveur est facultatif selon HTTP 1.1
• La RFC reconnaît que des champs de serveur trop détaillés peuvent faciliter l'analyse des sites à la recherche de serveurs vulnérables. De toute évidence, il s'agit d'une disposition d'obscurité plus difficile, et la quantité de détails est trop circonstancielle.
• Obsolète HTTP 1.1 RFC2616 est un peu plus audacieux dans la valeur de masquage de l'en-tête du serveur.
• PEP3333 semble dépasser légèrement lors de la mention de l'en-tête du serveur dans le contexte des en-têtes requis ou normaux.

Beaucoup d'opinions à ce sujet, comme dans Apache HTTPD ServerTokens : https://httpd.apache.org/docs/2.4/mod/core.html#servertokens

Il n'est pas recommandé de définir ServerTokens sur une valeur inférieure au minimum car cela rend plus difficile le débogage des problèmes interopérationnels. Notez également que la désactivation de l'en-tête Server: ne fait rien du tout pour rendre votre serveur plus sécurisé. L'idée de « sécurité par l'obscurité » est un mythe et conduit à un faux sentiment de sécurité.

Changer l'en-tête du serveur pour dire simplement gunicorn est une solution pratique et je pense que nous devrions le faire, sans configuration.

Des gens comme @kmichel-sereema, qui veulent optimiser la taille de chaque transfert, je pense que ce n'est pas le lieu pour effectuer une telle micro-optimisation. Si les en-têtes HTTP sont trop lourds, HTTP 1.x n'est pas le protocole idéal à utiliser, et je ne pense pas que nous devrions ajouter une configuration supplémentaire pour permettre de modifier ou de désactiver l'en-tête du serveur.

La suggestion de @tilgovi me semble être un bon compromis.

Dans de nombreux environnements, cela peut même être sans objet. Les documents de déploiement de gunicorn recommandent d'avoir un serveur proxy comme nginx devant gunicorn. nginx supprime automatiquement l'en-tête de

suite à ma suggestion et aux commentaires de @tilgovi & @jamadden, je ferme ce numéro en faveur de #2233. Merci à tous pour le code et les commentaires !