什么是“Upgrade-Insecure-Requests”HTTP 标头？

Posted 2023-02-23

【中文标题】什么是“Upgrade-Insecure-Requests”HTTP 标头？

【英文标题】：What is the "Upgrade-Insecure-Requests" HTTP header?

【发布时间】：2015-11-04 04:36:45

【问题描述】：

我向 HTTP（非 HTTPS）站点发出 POST 请求，在 Chrome 的开发者工具中检查了该请求，发现它在将其发送到服务器之前添加了自己的标头：

Upgrade-Insecure-Requests: 1

在Upgrade-Insecure-Requests上搜索后，我只能找到information关于服务器发送this标头：

Content-Security-Policy: upgrade-insecure-requests

这似乎是相关的，但仍然非常不同，因为在我的情况下，客户端在 Request 中发送标头，而我发现的所有信息都是关于服务器发送相关标头的一个响应。

---

那么为什么 Chrome (44.0.2403.130 m) 会在我的请求中添加 Upgrade-Insecure-Requests，它有什么作用？

---

2016 年 8 月 24 日更新：

此标头已添加为W3C Candidate Recommendation，现在已得到官方认可。

对于那些刚刚遇到这个问题并且感到困惑的人，Simon East 的excellent answer 很好地解释了它。

Upgrade-Insecure-Requests: 1 标头曾经是 HTTPS: 1 in the previous W3C Working Draft，在正式接受更改之前，Chrome 已悄悄地重命名。

（在此过渡期间，当没有关于此标头的官方文档且 Chrome 是唯一发送此标头的浏览器时，提出了此问题。）

【问题讨论】：

Firefox 也可以。

必须是新的；我首先在 Firefox 上进行开发，这个标头肯定不是去年从 Firefox 发送的。

【参考方案1】：

简短回答：它与Content-Security-Policy: upgrade-insecure-requests响应头密切相关，表明浏览器支持它（实际上更喜欢它）。

我花了 30 分钟的谷歌搜索，但我终于发现它隐藏在 W3 规范中。

之所以出现混淆，是因为规范中的标头是 HTTPS: 1，这就是 Chromium 实现它的方式，但在此之后 broke lots of websites that were poorly coded（尤其是 WordPress 和 WooCommerce），Chromium 团队道歉：

“我为损坏道歉；根据开发和测试期间的反馈，我显然低估了影响。” — Mike West，Chrome Issue 501842

他们的解决方法是将其重命名为 Upgrade-Insecure-Requests: 1，此后规范已更新以匹配。

不管怎样，这是来自the W3 spec (as it appeared at the time)的解释...

HTTPS HTTP 请求标头字段向服务器发送一个信号表示客户端的偏好，以获得加密和经过身份验证的响应，并且 它可以成功处理升级不安全请求指令，以便尽可能无缝地提供该偏好。

...

当服务器在 HTTP 请求的标头中遇到此偏好时，它应该将用户重定向到所请求资源的潜在安全表示。

当服务器在 HTTPS 请求的标头中遇到此首选项时，如果请求的主机是 HSTS 安全或有条件的 HSTS 安全 [RFC6797]，它应该在响应中包含 Strict-Transport-Security 标头。

【讨论】：

我看不懂。我是a.com 并将您重定向到b.com，同时将此标头提供给b.com 并发送一些信息。如果您不在b.com 的安全通道下，则可能已经发生嗅探攻击，因为我已将数据连同我的请求一起发送到b.com。您能否指导我们了解它如何使用户的连接更加安全的简单场景？

@SaeedNamati 从非常严格的角度来看，它不会让任何事情变得更安全。如果您有正常的安全要求，那么您必须确保首先通过 HTTPS 连接，而不是依赖于此。话虽如此，我将在“Trust on First Use”这个概念的背景下描述这一点，它确实被动地提供了帮助。

我认为这更多是客户的愿望，而不是安全工具。就像“DNT”头，服务器可以忽略它，但它表达了客户端的意愿。

我的回答实际上可以改进，以正确解释客户端和服务器如何协商这一点。如果您愿意，请随时提出改进建议。

【参考方案2】：

这解释了整个事情：

HTTP 内容安全策略 (CSP) 升级不安全请求 指令指示用户代理处理站点的所有不安全 URL （那些通过 HTTP 服务的）好像它们已被替换为安全的 URL（通过 HTTPS 提供的）。该指令适用于网络 具有大量不安全遗留 URL 的站点需要 重写。

upgrade-insecure-requests 指令在之前被评估 block-all-mixed-content ，如果设置了，后者实际上是 无操作。建议设置一个指令或另一个，但不要 两者都有。

upgrade-insecure-requests 指令不会确保用户 通过第三方网站上的链接访问您的网站将升级为 HTTPS 用于***导航，因此不会取代 Strict-Transport-Security (HSTS) 标头，仍应设置 具有适当的 max-age 以确保用户不受 SSL 剥离攻击。

来源：https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests