对于隐私敏感的上下文，是不是有任何浏览器将原始标头设置为“null”？

Posted 2023-02-22

【中文标题】对于隐私敏感的上下文，是不是有任何浏览器将原始标头设置为“null”？

【英文标题】：Are there any browsers that set the origin header to "null" for privacy-sensitive contexts?对于隐私敏感的上下文，是否有任何浏览器将原始标头设置为“null”？

【发布时间】：2014-04-19 06:37:55

【问题描述】：

Origin spec 表示Origin 标头可以设置为“null”。这通常在请求来自用户计算机上的文件而不是来自托管网页时完成。该规范还指出，如果请求来自“隐私敏感”上下文，则 Origin 可能为空。

我的问题：什么是“隐私敏感”上下文，是否有任何浏览器表现出这种行为？

以下是 Origin 规范的完整措辞：

每当用户代理从 “隐私敏感”上下文，用户代理必须发送值“null” 在 Origin 标头字段中。

注意：本文档没有定义隐私敏感的概念 语境。生成 HTTP 请求的应用程序可以指定 对隐私敏感的上下文对用户如何施加限制 代理生成 Origin 标头字段。

【参考方案1】：

还有一些与iframe 相关的其他情况可能导致null origin: https://webdbg.com/test/sandbox/frames.htm

【讨论】：

参见***.com/a/42242802/441757了解相关规范要求的详细信息

【参考方案2】：

在这里查看：https://bugs.chromium.org/p/chromium/issues/detail?id=154967

通过 [e-mail]

这种行为实际上在规范 [1] 中。 参见第 7.1.7 节步骤 6.

不幸的是，传输字符串“null”的约定使它看起来像是一个错误；我自己也是这么想的，直到我找到了这个:)

我们可能会在检查器中更好地解释这一点：

http://www.w3.org/TR/cors/#generic-cross-origin-request-algorithms

【讨论】：

赞成，但请注意，当前规范位于 fetch.spec.whatwg.org，具体相关引用是 fetch.spec.whatwg.org/#http-redirect-fetch 的第 10 步，其内容为 如果设置了 CORS 标志并且实际响应的位置 URL 的来源是与请求的当前 url 的来源不同，然后将请求的来源设置为唯一的不透明来源。 “唯一不透明原点”表示将被序列化为“空”的原点。 w3.org/TR/cors 不应再被引用，因为它已被 fetch.spec.whatwg.org 淘汰

【参考方案3】：

我有类似的情况，在 ajax 中从域 A->B 进行重定向，最后返回到 A。由于原点为空，CORS 失败。

在域 A 上我设置了 Access-Control-Allow-Origin: null，这似乎有效，需要进行更多测试。

【讨论】：

这违背了 Access-Control-Allow-Origin 的目的，请不要这样做

【参考方案4】：

我终于找到了答案。至少还有另一种情况，Origin 标头可能为“null”。在 CORS 请求期间跟随重定向时，如果请求被重定向到不同服务器上的 URL，Origin 标头将更改为“null”。我想这被认为是“隐私敏感上下文”，因为浏览器不想将原始来源泄露给新服务器，因为客户端可能一开始并不打算向新服务器发出请求。

【讨论】：

没有办法解决这个问题。这使得 AJAX-CAS 登录成为不可能。

我发现你的问题和思考过程与我的相似程度几乎令人难以置信。我们的团队在预检 POST 请求以访问 Web 上的 Auth 标头时遇到了 Web 上的 CORS 问题，而在 android 上没有遇到任何此类问题。这让我想到了为什么 CORS 不适用于 Android。我发现我们的 Android 人员甚至没有听说过 OPTIONS 和 CORS。很奇怪，对吧？然后我继续阅读规范并找到 ORIGIN 部​​分和空字符串点，然后搜索是否存在利用 CORS 中的空字符串的安全漏洞。

这在“Edge”浏览器中没有发生，它实际上发送了发起请求的实际“客户端”URL。理想情况下它应该是'null'。一个类似的问题在微软开发者网站中被提交为错误，该网站仍然开放。参考：developer.microsoft.com/en-us/microsoft-edge/platform/issues/…