如何在OAuth2之后使用SameSite = Strict重定向并仍然获取我的Cookie？ [英] How can I redirect after OAUTH2 with SameSite=Strict and still get my cookies?

问题描述

天儿真好！进一步 40781534 ，其中接受的答案是设置 SameSite = Lax ：

如何设置 SameSite = Strict 重定向到我自己的cookie，以便我可以从Chrome 56.0.2924.87 返回cookie，即使用户的请求本身是从我的OAUTH2提供程序的登录页面？

完整的请求链是：

• POST https://provider.com/callback → 302 FOUND with：

   位置：https：// me / login？code = xxx& state = yyy 
    

• GET https://example.com/login?code=xxx&state=yyy → 302 FOUND 或 303查看其他（似乎并不重要）：

   位置：https：//example.com/destination 
   Set-Cookie：sid = zzzz;安全;仅Http; SameSite =严格; Path = / 
    




• GET https://example.com/目的地→ 401 GET OFF MY LAWN 因为浏览器没有显示 sid cookie

如果我刷新，因为那么网站是相同的，我的浏览器显示 sid cookie

我很欣赏将 sid 呈现给 / destination 对于用户上次加载的页面的一般情况，它不在 example.com 上，但是我只是将它设置为，来自 / login ，我现在正在重定向到 / destination 。

<当然，我可以设置 SameSite = Lax ，但是如果有人可以找到某种方式来触发他们选择的重定向，那么就不会有点击的可能性我的网站通过错误的网址？

解决方

我不认为这可能出于安全原因来完成。 SameSite = Strict 表示如果用户已被重定向或只点击链接到您的网站（来自其他主机），则不应发送cookie。重定向就像是链接请求。因此，如果您的服务器重定向到另一个服务器，并且该服务器立即使用3xx代码重定向，则Cookie将被发送，因为您的服务器位于此链上。然而，如果您重定向到oauth提供商并且用户必须允许您访问其帐户，则意味着此链已损坏，并且cookie将不再发送即使您的网站设置了它（但它已设置但未发送）。您的重定向只是点击允许链接的扩展。

如果您想阻止其他人点击您的网站，只需在链接中使用nonce即可，您必须防止这种行为，并且可以如果不这样做会很危险。但考虑到大多数提供商 正在为您检查 ，前提是您的应用已定义并允许重定向网址。 这里有其他的解决方案（只有当你知道自己在做什么，并且可以自己承担100％的责任）时，才能使用。

• '继续访问网站'链接（点击链接后，cookie当然会发送）


• 使用JavaScript重新加载窗口 使用JavaScript重新定向网站用户


• 将第一种和第三种方法结合起来，以获得更清晰的解决方案，并且在浏览器中不支持JavaScript的情况下工作。





我在开发时使用了第二个，现在我使用的是相同的站点宽松（这在Hapi中默认最多可能是15版本，所以它不是那么糟糕）。




G'day! Further to 40781534, for which the accepted answer is to set SameSite=Lax:

How can I set SameSite=Strict cookies on a redirection to myself in such a way that I'll get the cookie back from Chrome 56.0.2924.87, even if the user's request was itself a redirection from a login page on my OAUTH2 provider?

The full request chain is:

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

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

• GET https://example.com/login?code=xxx&state=yyy → 302 FOUND or 303 SEE OTHER (doesn't seem to matter) with:

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

• GET https://example.com/destination → 401 GET OFF MY LAWN because the browser didn't present the sid cookie

• GET https://example.com/destination → 200 OK if I refresh, because then the site is the same and my browser presents the sid cookie

I appreciate the CSRF potential of presenting sid to /destination for the general case of the user's last loaded page not being on example.com, but I only just set it from /login, and I'm the one now redirecting to /destination.

Sure, I could set SameSite=Lax, but then wouldn't there be some potential for click-jacking if someone could find some way to trigger redirection of their choice from my site by mal-forming a URL?

解决方案

I don't think that this can be done for security reasons. SameSite=Strict means that if user has been redirected or just clicked on link to your site (from other host), cookie shouldn't be send. And redirecting is like 'chaining' requests. So if your server redirects to another and this server redirects back immediately with 3xx code, cookie will be sent, because your server is 'on top' of this chain.

However if you redirect to oauth provider and user has to allow there you to access his account it means that this 'chain' is broken, and cookie will no longer be sent even if your site sets it (it is set however not sent). Your redirect is just 'extension' of clicked 'allow' link.

If you want to prevent others from click-jacking your site, just use nonce in link if you think, that you have to prevent that kind of behavior, and it can be dangerous if you don't. But consider that most providers are checking for you if redirect url was previously defined and allowed by your app.

Here are other solutions (use only if you know what you're doing and can get on yourself 100% responsibility).

• Prepare site with 'Continue to site' link (cookie of course will be send after hitting link)
• Reload window with JavaScript
• Prepare site with JavaScript which will redirect user
• Combine first and third method to have cleaner solution, and working without JavaScript support in browser.

I have used second while developing, now I am using same site lax (this was default in Hapi up to maybe 15 ver, so it isn't so bad).

这篇关于如何在OAuth2之后使用SameSite = Strict重定向并仍然获取我的Cookie？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！