Gunicorn: 能够屏蔽 http 响应头服务器属性

通常，gunicorn 在生产环境中部署在像 nginx 这样的反向代理服务器之后，并且 nginx 会输出自己的Server标签。

楼上加一

通过@benoitc，我们可以在命令行上提出一个选项，你怎么看？ 否则，我们将按照@georgexsh 的解释关闭此票证，在生产模式下，您可以使用反向代理（nginx、apache 等）。

不能在post_request钩子中修改环境吗？

@tilgovi我猜这会起作用……不确定我们是否需要创建另一个选项……

不起作用。 该请求已在该点发送。

@tilgovi中间件也不起作用，因为Server位于默认标头中。

如果我们完全删除 Server 标头怎么办？

+1

如果我们允许您将标头的值设置为随机字符串，我们也应该允许您完全删除标头。

+1

为什么要删除标题？

过去，我从部署中删除了标头以隐藏服务器软件和版本，这样就不会被那些使用已知漏洞抓取服务器的人发现。

对。 安全是原因之一。 当然，您可以将Server值更改为随机值，但是为什么要发送不必要的额外字节呢？

我冒昧地为此功能制作了 PR：#1384。 它在我的通缉名单上已经有一段时间了。

添加到讨论中：我认为虽然一些反向代理服务器修改了Server标头，但有些添加了Via标头，如https://www.w3.org/Protocols/ 中所述rfc2616/rfc2616-sec14.html#sec14.38

不幸的是， @mathiasverhoeven由于某种原因关闭了他的 PR，并且最近没有活动。

在这里是否不可能有更通用的选项，例如在--set-headers ，您可以将任意数量的标头指定为键值对？ 空值将完全省略标题。

目前，我想调整Server ，但我还想再添加一个响应头，例如X-Product: MyProduct 。

我可以根据@mathiasverhoeven的公关将一些东西放在一起。 @benoitc和@tilgovi你怎么看？

只是要离开这里： https : Server标头既非常常见又完全没有必要。

我还希望能够省略 Server 标头。 我使用名为 Hiawatha 的以安全为中心的 Web 服务器进行反向代理，设置为不添加自己的 Server 标头，因此 gunicorn 的 Server 标头目前正在将其发送给客户端。

@tuukkamustonen的想法对我来说听起来不错。 :)

编辑：刚刚看到https://github.com/benoitc/gunicorn/pull/1617。 server_tokens = true|false|string会很棒。

有人运行 Flask 吗？ https://stackoverflow.com/a/46858238/452210建议包装和覆盖process_response ，替换或删除标题。

我还希望能够省略 Server 标头。 我使用名为 Hiawatha 的以安全为中心的 Web 服务器进行反向代理，设置为不添加自己的 Server 标头，因此 gunicorn 的 Server 标头目前正在将其发送给客户端。

我注意到即使是 cloudflare 也显示了一个服务器标头，所以现在我不确定它是如何更多地关注安全而不是名声。

我认为与其在命令行或配置中添加另一个选项，不如简单地从标题中删除版本以开始。 然后添加一个仅配置文件设置以删除 server_token。 它的优点是服务器优雅地升级到新版本将能够在不停止服务的情况下添加该设置。 想法？

我注意到即使是 cloudflare 也显示了一个服务器标头，所以现在我不确定它是如何更多地关注安全而不是名声。

我认为 Cloudflare 的服务和服务器标头与单个站点的服务器具有不同的上下文。 当一个站点通过 Cloudflare 反向代理时，由 Cloudflare 进行代理的事实并不是未知的； 这很明显通过名称服务器和/或 IP 地址等。相比之下，我在没有第三方反向代理的 VPS 上托管站点确实让我有希望至少避免通过服务器软件的 HTTP 标头直接识别。 （当然，我们的想法是，如果将来发现 gunicorn 存在一些漏洞，那么寻找目标应该比仅仅搜索其服务器标头更困难。）

我认为与其在命令行或配置中添加另一个选项，不如简单地从标题中删除版本以开始。 然后添加一个仅配置文件设置以删除 server_token。 它的优点是服务器优雅地升级到新版本将能够在不停止服务的情况下添加该设置。 想法？

那很好啊。 :+1: :slightly_smiling_face:

是的，请至少删除版本。 版本不会增加任何名气，并为攻击者节省了大量时间。

我正在考虑删除版本。 @tilgovi 对此有何想法？

对于我来说足够了！

这方面有进展吗？ 这似乎是安全方面的快速胜利。

这将是下一个 20.1 的一部分

我正在考虑删除版本。

是否仍在计划完全删除服务器标头的仅配置文件设置？

@DavidOliver为什么这个问题？

@benoitc我引用的您的评论可以被解释为“只是”/仅是将被删除的版本号，而在对话的早些时候，完全删除服务器标头的设置（我想这样做）是正在考虑。

谢谢。

如果我们可以完全删除服务器标头，我们应该这样做。

我仍然必须确信删除它与
安全。 在过去的 10 年中，这不是问题。 安全由
默默无闻也无济于事，我更愿意知道我们有问题并且
修理它。 也知道服务器可以帮助操作

我现在倾向于删除该版本，因为此版本正在提供
关于如何维护服务器的太多信息。 我们应该这样做
我们维护的每个分支。

想法？

伯努瓦

在Sun 2019年12月29日在04:23兰德尔利兹[email protected]写道：

如果我们可以完全删除服务器标头，我们应该这样做。

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/benoitc/gunicorn/issues/825?email_source=notifications&email_token=AAADRIQBGN2KQRKOKLAYK43Q3AJ2PA5CNFSM4ASCOWF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63HYLNMVXWS2700000000000000000004000400400004
或取消订阅
https://github.com/notifications/unsubscribe-auth/AAADRISEUFGD43CKXLV3EZTQ3AJ2PANCNFSM4ASCOWFQ
.

>

从我的手机发送

你好，

我正在使用 gunicorn 通过数据连接提供响应
很贵，我可以删除的任何东西都是我不必支付的。

服务器标头很小，但小东西加起来，有时
小东西意味着你可以把所有东西都放在一个小包里：
带有版本的服务器头为 24 字节，约占有效负载的 1.7%
具有 1460 的 MSS 和 TLS 标头。 即使没有额外的包裹，
更大的数据包更有可能需要完全重新发送
当连接不良时（如偏远地区的蜂窝网络）。

在新的 HTTPS 连接上，握手和证书
交换使大部分有效载荷和小东西可以
忽略。 对于使用保持活动、冗余的小型重复请求
标头成为请求/响应的更大部分。

这对于更关心客户的人来说也很重要
性能（延迟大于吞吐量）而不是成本。

对于这个用例，最有用的选项是能够
完全删除标题，而不是简单地删除值
或版本部分。

此评论主要限于添加相关的参考/规范/RFC 信息，并且（希望）主要是没有意见的解释/评论。

RFC7231 超文本传输​​协议 (HTTP/1.1)：语义和内容https://tools.ietf.org/html/rfc7231#section -7.4.2

...原始服务器可以在其响应中生成一个服务器字段。

源服务器不应该生成包含不必要的细粒度细节的服务器字段，并且应该限制第三方添加子产品。 过长和详细的服务器字段值会增加响应延迟，并可能会泄露内部实现细节，这可能使攻击者（稍微）更容易找到和利用已知的安全漏洞。

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

9.6. 产品信息披露
User-Agent（第 5.5.3 节）、Via（[RFC7230] 的第 5.7.1 节）和服务器（第 7.4.2 节）标头字段通常会显示有关相应发送方的软件系统的信息。 理论上，这可以让攻击者更容易利用已知的安全漏洞； 实际上，攻击者往往会尝试所有潜在的漏洞，而不管使用的明显软件版本如何。 通过网络防火墙充当门户的代理应该对可能识别防火墙后面主机的标头信息的传输采取特殊的预防措施。 Via 头字段允许中介用假名替换敏感的机器名称。

来自（已弃用）RFC2616：

15.1.2 敏感信息的传输
与任何通用数据传输协议一样，HTTP 无法调节传输数据的内容，也没有任何先验方法可以确定任何给定请求上下文中任何特定信息的敏感性。 因此，应用程序应该向该信息的提供者提供对该信息的尽可能多的控制。 在这种情况下，有四个头字段值得特别提及：Server、Via、Referer 和 From。
揭示服务器的特定软件版本可能会使服务器机器更容易受到针对已知包含安全漏洞的软件的攻击。 实现者应该使服务器头字段成为一个可配置的选项。

PEP3333 Python Web 服务器网关接口 v1.0.1 https://www.python.org/dev/peps/pep-3333/#the -start-response-callable

通常，服务器或网关负责确保向客户端发送正确的标头：如果应用程序省略了 HTTP（或其他有效的相关规范）要求的标头，则服务器或网关必须添加它。 例如，HTTP Date: 和 Server: 标头通常由服务器或网关提供。

• 根据 HTTP 1.1，服务器响应标头是可选的
• RFC 认识到过于详细的服务器字段可以更容易地扫描站点以查找易受攻击的服务器。 显然，这是一个更难的、默默无闻的规定，而且细节太多是间接的。
• 已弃用的 HTTP 1.1 RFC2616 在隐藏服务器标头的价值方面更大胆一些。
• PEP3333 在必需或正常标头的上下文中提及服务器标头时似乎略有过分。

对此有很多意见，例如在 Apache HTTPD ServerTokens ： https :

不建议将 ServerTokens 设置为小于 minimum，因为它会使调试互操作问题变得更加困难。 另请注意，禁用 Server: 标头根本不会使您的服务器更安全。 “通过默默无闻的安全”的想法是一个神话，会导致错误的安全感。

将服务器标头更改为仅表示gunicorn是一个实用的解决方案，我认为我们应该这样做，无需配置。

像@kmichel-sereema 这样想要优化每次传输大小的人，我认为这不是进行这种微优化的地方。 如果 HTTP 标头的开销太大，HTTP 1.x 不是理想的协议，我认为我们不应该添加额外的配置来允许更改或禁用服务器标头。

@tilgovi的建议对我

在许多环境中，这甚至可能没有实际意义。 gunicorn部署文档推荐gunicorn前面有nginx之类的代理服务器。 nginx 在到达客户端之前自动从代理服务器中

按照我的建议和@tilgovi和@jamadden 的评论，我正在关闭这个对#2233 的支持。 感谢大家的代码和评论！