sameSite 属性如何保护用户免受信息泄露？
How does sameSite attribute protect the user from information leakage?
据说 sameSite 属性可以保护用户免受信息泄露。
不过我还是不太清楚。例如：
- 一些用户访问了一些没有“sameSite 保护”的站点。
- 网站正在加载，包括位于此处的广告横幅。加载此横幅时，将向广告站点的服务器发出 HTTP 请求。
几乎没有任何cookie可以被盗。我的意思是，任何 cookie 都有自己的 domain 和 path 属性。因此，在此 HTTP 请求期间，似乎只能加载来自位于用户设备上的广告网站的 cookie。
所以，我的问题是：在另一个网站上收集关于自己网站的信息有什么用？我的意思是，该站点还可以“在家”收集有关其自身的统计信息。
有点误会，samesite cookies的目的并不是防止信息泄露给广告商。
samesite属性缓解的安全问题是csrf，cross-site请求伪造。
这里不赘述，问题的根本原因是来自浏览器的请求（任何请求）在默认情况下将包含目标域的 cookie，而不管用户正在查看的页面如何。因此，假设您已登录到您的银行网站并要转账，需要一个 post 请求以使用适当的参数进行 /transfer。这些参数不是秘密，所有用户都会发送相同类型的请求，但在他们自己的会话中。现在，如果您出于任何原因访问 attacker.com，是什么阻止了攻击者创建一个表单（在一个最天真的例子中），当您在 attacker.com 上提交时，将 post 发送到您银行的 /transfer正确的参数，所以攻击者会收到你的钱？并且您的银行会话 cookie 中的会话令牌将被发送，因此请求将有效（因为 cookie 用于银行网站，并且请求将发送到银行网站 - 用户是否在 attacker.com)!
（您可能会争辩说是同源策略阻止了这种情况，但在这个简化的示例中并没有，如果涉及 ajax 也不是。）
有多种策略可以通过双重提交等从同步器令牌中缓解这种情况。所有体面的网站都有针对 csrf 的缓解措施。而在过去几年出现的另一种策略是samesite属性。
如果一个 cookie（通常是应用程序的会话 cookie）被标记为 samesite，如果可见 origin in the browser doesn't have the same site 作为请求的目标 url，它将不会与请求一起发送。这意味着 attacker.com 上的攻击者站点将无法 post 到您的银行。 （事实上它可以post，但不会包含同站点会话cookie，因此请求将无效）。
默认情况下，这仅适用于 non-get 请求 (samesite=lax)，但也可以用于 get 请求 (samesite=strict)，以提高安全性，但代价是用户体验差很多。
请注意，虽然我将会话 cookie 视为最普遍的示例，但这适用于当请求 cross-site.
时您在应用程序中不想接收的任何 cookie
据说 sameSite 属性可以保护用户免受信息泄露。
不过我还是不太清楚。例如：
- 一些用户访问了一些没有“sameSite 保护”的站点。
- 网站正在加载，包括位于此处的广告横幅。加载此横幅时，将向广告站点的服务器发出 HTTP 请求。
几乎没有任何cookie可以被盗。我的意思是，任何 cookie 都有自己的 domain 和 path 属性。因此，在此 HTTP 请求期间，似乎只能加载来自位于用户设备上的广告网站的 cookie。
所以，我的问题是：在另一个网站上收集关于自己网站的信息有什么用？我的意思是，该站点还可以“在家”收集有关其自身的统计信息。
有点误会，samesite cookies的目的并不是防止信息泄露给广告商。
samesite属性缓解的安全问题是csrf，cross-site请求伪造。
这里不赘述，问题的根本原因是来自浏览器的请求（任何请求）在默认情况下将包含目标域的 cookie，而不管用户正在查看的页面如何。因此，假设您已登录到您的银行网站并要转账，需要一个 post 请求以使用适当的参数进行 /transfer。这些参数不是秘密，所有用户都会发送相同类型的请求，但在他们自己的会话中。现在，如果您出于任何原因访问 attacker.com，是什么阻止了攻击者创建一个表单（在一个最天真的例子中），当您在 attacker.com 上提交时，将 post 发送到您银行的 /transfer正确的参数，所以攻击者会收到你的钱？并且您的银行会话 cookie 中的会话令牌将被发送，因此请求将有效（因为 cookie 用于银行网站，并且请求将发送到银行网站 - 用户是否在 attacker.com)!
（您可能会争辩说是同源策略阻止了这种情况，但在这个简化的示例中并没有，如果涉及 ajax 也不是。）
有多种策略可以通过双重提交等从同步器令牌中缓解这种情况。所有体面的网站都有针对 csrf 的缓解措施。而在过去几年出现的另一种策略是samesite属性。
如果一个 cookie（通常是应用程序的会话 cookie）被标记为 samesite，如果可见 origin in the browser doesn't have the same site 作为请求的目标 url，它将不会与请求一起发送。这意味着 attacker.com 上的攻击者站点将无法 post 到您的银行。 （事实上它可以post，但不会包含同站点会话cookie，因此请求将无效）。
默认情况下，这仅适用于 non-get 请求 (samesite=lax)，但也可以用于 get 请求 (samesite=strict)，以提高安全性，但代价是用户体验差很多。
请注意，虽然我将会话 cookie 视为最普遍的示例，但这适用于当请求 cross-site.
时您在应用程序中不想接收的任何 cookie