为点击的链接阻止 cookie 有什么好处？（SameSite=严格）答案

【问题标题】：What is the benefit of blocking cookie for clicked link? (SameSite=strict)为点击的链接阻止 cookie 有什么好处？（SameSite=严格）
【发布时间】：2017-06-10 01:26:36
【问题描述】：

因此，对于 Google Chrome 和 Opera，cookie 具有 SameSite 属性，该属性可以是以下两个值之一：strict 或 lax。

它们之间的一些区别之一是SameSite=strict 会在我们单击指向另一个域的链接时阻止发送 cookie。

我知道SameSite 还不是 W3C 推荐，但是这种行为的潜在好处是什么？我觉得这很烦人，因为当我们刷新或单击当前域上的另一个链接时，无论如何都会发送 cookie。这导致了相当奇怪的用户体验 - 例如：我们退出，然后我们点击一些国内链接或刷新，我们突然被认证。

我知道它的设计目的不是为了提供最佳的用户体验，而是为了安全。但在安全性方面，我们实际上赢得了什么？

【问题讨论】：

标签： google-chrome http security cookies browser

【解决方案1】：

使用strict 而不是lax 的好处是有限的。我可以看到两个：

通过GET 请求防止CSRF 攻击。这种攻击通常是不可能的，因为它们依赖于实现具有副作用的GET 端点的服务器（不正确并且违反了RFC 7231 指定的语义）。您在 cmets 中给出了一个示例：

假设我们有一个非常糟糕的设计，我们所有的操作都是在 GET 方法上执行的。攻击者放置了“拯救小狗”的链接，链接到http://oursite.com/users/2981/delete。这是我能想到的唯一用例——当我们通过 GET 方法完成一些操作时，而它不应该这样做。

防止定时攻击。有一类攻击 - 已经发现 back in 2000，但 Mathias Bynens 最近已探索和普及 - 涉及使用 JavaScript 向另一个域上的页面发起请求的恶意网页，然后测量需要多长时间，并从所花费的时间推断有关用户的事情。 Mathias 发明的一个示例是使用 restricted audience 向 Facebook 页面发起请求，这样它就只能由例如 Examplestan 中的人访问。然后恶意网页计算响应返回所需的时间。当您尝试访问无法访问的帖子时，Facebook 会提供错误页面，其速度比提供实际帖子的速度快，因此如果恶意网页得到快速响应，它可以推断用户不在 Examplestan 中；如果它得到一个慢响应，那么用户很可能是Examplestani。

由于浏览器在您进行顶级导航时不会停止在页面上执行 JavaScript，直到它们收到来自被导航到的 URL 的响应，不幸的是，这些定时攻击完全可以通过顶级导航进行；你的邪恶页面可以通过location=whatever 导航用户离开，然后通过在循环中重复记录当前时间戳到localStorage 来计算另一个页面加载所需的时间。然后在随后的访问中，邪恶页面可以检查页面开始卸载所用的时间，并推断出正在计时的页面的响应时间。

托管目标页面的域（例如 facebook.com，在 Mathias 的示例中）可以通过使用 samesite=strict cookie 来保护其用户免受此类攻击。

显然，这些有限的好处是以严重的用户体验折衷为代价的，因此与samesite=lax 提供的已经相当不错的保护相比通常不值得！

【讨论】：

【解决方案2】：

这里应该有答案，所以我只是重复一下cmets中已经说过的话。

您应该始终使用samesite=lax，除非您可以为用户提供糟糕的用户体验。 lax 足够安全，因为只有在从不同域引用时，才会为 Safe Methods（即 GET）发送 cookie。如果你用GET 请求做危险的事情，那么你有更大的问题。

【讨论】：