google-chrome - 如何在使用 SameSite=Strict 的 OAUTH2 后重定向并仍然获取我的 cookie？

Question

你好!进一步到40781534 ，接受的答案是设置 SameSite=Lax:

如何在重定向到我自己时设置 SameSite=Strict Cookie，以便我可以从 Chrome 56.0.2924.87 取回 Cookie，即使用户的请求本身是从我的 OAUTH2 提供商上的登录页面进行的重定向？

完整的请求链是:

• POST https://provider.com/callback → 302 FOUND 包含:

  Location: https://me/login?code=xxx&state=yyy
  

• 获取 https://example.com/login?code=xxx&state=yyy → 302 FOUND 或 303 SEE OTHER (似乎并不重要):

  Location: https://example.com/destination
  Set-Cookie: sid=zzzz; Secure; HttpOnly; SameSite=Strict; Path=/
  

• GET https://example.com/destination → 401 离开我的草坪，因为浏览器未显示 sid cookie

• GET https://example.com/destination → 200 OK 如果我刷新，因为这样站点是相同的，并且我的浏览器会显示 sid cookie

对于用户最后加载的页面不在 example.com 上的一般情况，我很欣赏将 sid 呈现给 /destination 的 CSRF 潜力>，但是我只是从 /login 设置它，而我现在重定向到 /destination。

当然，我可以设置 SameSite=Lax，但是如果有人能够找到某种方法通过恶意方式从我的网站触发他们选择的重定向，那么是否存在点击劫持的可能性？形成一个 URL？

Answer 1

出于安全原因，我认为不能这样做。 SameSite=Strict 意味着如果用户已被重定向或只是单击了指向您网站的链接(从其他主机)，则不应发送 cookie。重定向就像“链接”请求。因此，如果您的服务器重定向到另一个服务器，并且该服务器立即使用 3xx 代码重定向回来，则将发送 cookie，因为您的服务器位于该链的“顶部”。

但是，如果您重定向到 oauth 提供商并且用户必须允许您访问他的帐户，则意味着此“链”已损坏，并且即使您的网站设置了 cookie，也将不再发送 cookie(已设置但未设置)发送)。您的重定向只是单击的“允许”链接的“扩展”。

如果您想防止其他人点击劫持您的网站，只需在链接中使用随机数(如果您认为必须防止这种行为)，否则可能会很危险。但请注意，大多数提供商正在为您检查重定向网址是否已被您的应用先前定义并允许。

以下是其他解决方案(仅当您知道自己在做什么并且能够承担 100% 的责任时才使用)。

• 准备带有“继续访问网站”链接的网站(点击链接后当然会发送 cookie)
• 使用 JavaScript 重新加载窗口
• 使用 JavaScript 准备网站以重定向用户
• 将第一种方法和第三种方法结合起来以获得更简洁的解决方案，并且无需浏览器中的 JavaScript 支持即可工作。

我在开发时使用了第二个，现在我正在使用同一个站点 lax(这是 Hapi 中默认的，可能到 15 版本，所以它还不错)。