Set-Cookie HTTP header 和 CSRF 的松散与严格
Lax vs Strict for Set-Cookie HTTP header and CSRF
我刚刚在看书 https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie:
Lax: The cookie is not sent on cross-site requests, such as calls to
load images or frames, but is sent when a user is navigating to the
origin site from an external site (e.g. if following a link). This is
the default behavior if the SameSite attribute is not specified.
如果这是默认设置，那么这是否意味着 CSRF 攻击不会发生？
如果有人加载一个在后台运行 Javascript 的恶意网站，向受害者当前登录的网站发出简单的 POST 请求，则默认行为是不会发送 cookie，对吗？
此外，为什么有人会选择使用 Strict 而不是 Lax？
为什么你会想要阻止用户的浏览器在导航到该网站时向源网站发送 cookie，而这正是 Strict 所做的？
当 SameSite 为 Lax 时，CSRF 攻击仍然可能发生。它可以防止您提到的跨站点 POST 攻击，但是如果网站通过 GET 请求触发不安全操作，那么它仍然是可能的。例如，许多站点当前使用 GET 请求触发注销，因此攻击者将用户从会话中注销是微不足道的。
标准addresses this直接：
Lax enforcement provides reasonable defense in depth against CSRF
attacks that rely on unsafe HTTP methods (like "POST"), but does not
offer a robust defense against CSRF as a general category of attack:
Attackers can still pop up new windows or trigger top-level
navigations in order to create a "same-site" request (as
described in section 5.2.1), which is only a speedbump along the
road to exploitation.
Features like <link rel='prerender'> can be
exploited to create "same-site" requests without the risk of user
detection.
鉴于此，有人会使用 Strict 的原因很简单：它可以防止更广泛的 class CSRF 攻击。当然，这是一种权衡，因为它会阻止某些使用您网站的方式，但如果这些用例对您不重要，那么权衡可能是合理的。
我刚刚在看书 https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie:
Lax: The cookie is not sent on cross-site requests, such as calls to load images or frames, but is sent when a user is navigating to the origin site from an external site (e.g. if following a link). This is the default behavior if the SameSite attribute is not specified.
如果这是默认设置，那么这是否意味着 CSRF 攻击不会发生？ 如果有人加载一个在后台运行 Javascript 的恶意网站，向受害者当前登录的网站发出简单的 POST 请求，则默认行为是不会发送 cookie，对吗？
此外，为什么有人会选择使用 Strict 而不是 Lax？ 为什么你会想要阻止用户的浏览器在导航到该网站时向源网站发送 cookie，而这正是 Strict 所做的？
当 SameSite 为 Lax 时，CSRF 攻击仍然可能发生。它可以防止您提到的跨站点 POST 攻击，但是如果网站通过 GET 请求触发不安全操作，那么它仍然是可能的。例如，许多站点当前使用 GET 请求触发注销，因此攻击者将用户从会话中注销是微不足道的。
标准addresses this直接：
Lax enforcement provides reasonable defense in depth against CSRF attacks that rely on unsafe HTTP methods (like "POST"), but does not offer a robust defense against CSRF as a general category of attack:
Attackers can still pop up new windows or trigger top-level navigations in order to create a "same-site" request (as described in section 5.2.1), which is only a speedbump along the road to exploitation.
Features like
<link rel='prerender'>can be exploited to create "same-site" requests without the risk of user detection.
鉴于此，有人会使用 Strict 的原因很简单：它可以防止更广泛的 class CSRF 攻击。当然，这是一种权衡，因为它会阻止某些使用您网站的方式，但如果这些用例对您不重要，那么权衡可能是合理的。