从服务器到另一个域中的XHR客户端的Set-Cookie，将域设置为客户端的域，是否可以工作？

Question

tl; dr，域A中的XHR客户端正在向域B中的服务器发送请求，服务器以Set-Cookie的{​​{1}}响应（客户端的域，即XHR的{ {1}}），正确设置了所有CORS标头，是否可以正常工作？

众所周知，不能将Cookie设置到另一个域。 （How to set a cookie for another domain

但是，在以下情况下：

---

演员：

客户在域 A （基于网络的客户）

域 B 中的

服务器，使用允许A作为来源的CORS标头进行设置，包括将Domain=A设置为 true

通信流1（基准）：

1. 客户端正在向服务器发出简单的GET请求
2. 服务器以cookie响应，并将Domain属性设置为服务器的（Domain = B ）
3. 客户端正在发送另一个HXR请求，并且有Origin
4. 该Cookie被发送回服务器，没有任何问题

  

注意：步骤1中发送的Cookie不会显示在document.cookies中，即使未将其设置为httpOnly（因为它没有   属于客户的域）。也尝试从Access-Control-Allow-Credentials获取它   通过查看“ Set-Cookie”标题，您将被设计阻止：   https://fetch.spec.whatwg.org/#forbidden-response-header-name它将   甚至不会在“网络”标签下的Chrome开发者工具中显示！但这会   仍被发送）

通信流2（我的问题）：

1. 客户端正在向服务器发出简单的GET请求
2. 服务器以cookie响应，但将Domain属性设置为客户端（Domain = A ）的
3. 客户端正在发送HXR请求，并且有withCredentials=true
4. 该cookie不会被发送回，并且似乎没有存储在任何地方

为什么我有点惊讶？由于XHR的来源是 A ，并且它请求将Cookie设置为域 A 的某些内容（如果我查看邮递员，我会清楚地看到xhr标头与withCredentials=true与请求的Set-Cookie相同，而我为此设置了最宽松的CORS设置，为何不让我这样做呢？ （我原以为它会失败，但仍然让我感到奇怪）

---

问题

1. spec / RFC中最好的位置是哪里，它阐明了cookie Domain等于Origin

的XHR也无法使用>

2. 如果从理论上讲，浏览器 did 允许并且仅当Domain与cookie { {1}}，CORS原点允许该原点。

3. 还有另一种方法可以使它起作用吗？也许可以，但是我的POC设置不正确？

附录：推理

我正在寻找一种使用Cookie to header token method之类的跨源CSRF的方法，但是由于跨源问题，看来这是不可能的。我想到的唯一解决方法是从服务器发送CSRF令牌作为标头，然后客户端可以将其另存为cookie，以便以后可以访问，还有其他方法吗？这算安全吗？

Answer 1

资源只能为其主机的可注册域设置cookie。如果Facebook使用Google字体，而Google可以使用它来覆盖Facebook Cookie，那将是灾难性的。

关于定义位置，https://tools.ietf.org/html/rfc6265#section-5.3的第5和第6步对此进行了处理。 （在解释响应中的Set-Cookie标头时，Fetch在很大程度上遵循此RFC。）