对于隐私敏感的上下文,是否有任何浏览器将原始标头设置为"null"？

Question

对于隐私敏感的上下文,是否有任何浏览器将原始标头设置为"null"？

在原产地规范指示Origin头可以被设置为"空".这通常在请求来自用户计算机上的文件而不是来自托管网页时完成.该规范还声明,如果请求来自"隐私敏感"上下文,则Origin可以为null.

我的问题:什么是"隐私敏感"环境,是否有任何浏览器表现出这种行为？

以下是Origin规范的全部措辞:

每当用户代理从"隐私敏感"上下文发出HTTP请求时,用户代理必须在Origin头字段中发送值"null".

注意:本文档未定义隐私敏感上下文的概念.生成HTTP请求的应用程序可以将上下文指定为对隐私敏感,以对用户代理如何生成Origin头字段施加限制.

Answer 1

mon*_*sur 50

我终于找到了答案.至少存在一种其他情况,其中Origin标题可以是"空".在CORS请求期间执行重定向时,如果请求被重定向到其他服务器上的URL,则Origin标头将更改为"null".我认为这被认为是"隐私敏感的上下文",因为浏览器不希望将原始源泄露到新服务器,因为客户端可能不打算首先向新服务器发出请求.

没有办法解决这个问题.这使得AJAX-CAS登录成为不可能. (5认同)
我发现你的问题和思考过程与我的如此相似，这几乎令人难以置信。我们的团队在预检 POST 请求以访问 Web 上的 Auth 标头期间遇到了 Web 上的 CORS 问题，而在 Android 上没有遇到任何此类问题。这让我想到为什么 CORS 不适用于 Android。我发现我们的 Android 人员甚至没有听说过 OPTIONS 和 CORS。很奇怪吧？然后我继续阅读规范并找到 ORIGIN 部分和空字符串点，然后搜索是否存在安全漏洞来利用 CORS 中的空字符串。 (2认同)

Answer 2

小智 5

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

来自 strobe@google.com

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

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

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

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

已投票，但请注意，当前规范位于 https://fetch.spec.whatwg.org/，具体相关引用位于 https://fetch.spec.whatwg.org/#http-redirect-fetch 的第 10 步，其内容为*如果设置了 CORS 标志并且实际响应的位置 URL 的来源与请求的当前 url 的来源不同，则将请求的来源设置为唯一的不透明来源*。“唯一的不透明来源”意味着将被序列化为“null”的来源。http://www.w3.org/TR/cors/ 不应再被引用，因为它已被 https://fetch.spec.whatwg.org/ 废弃 (3认同)

归档时间：	11 年，11 月前
查看次数：	10083 次
最近记录：	8 年，10 月前