sameSite 属性如何保护用户免受信息泄露？

Question

据说sameSite属性可以保护用户不被信息泄露。

但我仍然不完全清楚。例如：

1. 某些用户访问的网站没有“sameSite 保护”。
2. 网站正在加载，包括位于此处的广告横幅。加载此横幅时，会向广告网站的服务器发出 HTTP 请求。

几乎没有任何 cookie 可以被盗。我的意思是，任何 cookie 都有自己的 domain 和 path 属性。因此，在此 HTTP 请求期间，似乎只能加载来自位于用户设备上的广告网站的 cookie。

所以，我的问题是：在另一个站点上收集有关其自己站点的信息有什么用？我的意思是，这个网站也可以“在家”收集关于它自己的统计数据。

Answer 1

这有点误会，同站cookie的目的不是防止信息泄露给广告商。

samesite属性缓解的安全问题是csrf，跨站请求伪造。

这里不赘述，问题的根本原因是默认情况下来自浏览器的请求（任何请求）将包含目标域的 cookie，而不管用户正在查看的页面是什么。因此，假设您已登录到您的银行网站并要转账，需要使用适当的参数向 /transfer 发出 post 请求。这些参数不是秘密，所有用户都将发送相同类型的请求，但在他们自己的会话中。现在，如果您出于某种原因访问attacker.com，是什么阻止了攻击者创建一个表单（在一个最幼稚的示例中），当您在attacker.com 上提交时，该表单将发布到您的银行/transfer 正确的参数，因此攻击者将收到你的钱？并且您的银行会话 cookie 中的会话令牌将被发送，因此请求将是有效的（因为 cookie 用于银行网站，并且请求将发送到银行网站 - 用户是否是攻击者并不重要.com)！

（您可能会争辩说，防止这种情况发生的是同源策略，但在这个简化的示例中没有，而且如果涉及 ajax，也不是真的。）

有多种策略可以通过双重提交等方式从同步器令牌中缓解这种情况。所有体面的网站都有针对 csrf 的缓解措施。而过去几年出现的另一种策略是同站点属性。

如果一个 cookie（通常是应用程序的会话 cookie）被标记为相同站点，如果浏览器中可见的 origin 与请求的目标 url 不具有相同的 site，它将不会与请求一起发送.这意味着attacker.com 上的攻击者站点将无法向您的银行发帖。 （其实可以post，但是不会包含samesite session cookie，所以请求无效）。

默认情况下，这仅适用于非获取请求 (samesite=lax)，但也可以用于获取请求 (samesite=strict)，以提高安全性，但代价是用户体验更差。

请注意，虽然我将会话 cookie 作为最普遍的示例进行了讨论，但这适用于您在应用程序中不希望在跨站点请求时收到的任何 cookie。