Set-Cookie HTTP 标头和 CSRF 的 Lax 与 Strict答案

【问题标题】：Lax vs Strict for Set-Cookie HTTP header and CSRFSet-Cookie HTTP 标头和 CSRF 的 Lax 与 Strict
【发布时间】：2021-09-11 04:57:18
【问题描述】：

我只是在阅读https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie：

Lax：cookie 不会在跨站点请求上发送，例如调用加载图像或帧，但在用户导航到来自外部站点的原始站点（例如，如果跟随链接）。这是未指定 SameSite 属性时的默认行为。

如果这是默认设置，那么这是否意味着 CSRF 攻击不会发生？如果有人加载一个在后台运行 Javascript 的恶意网站，向受害者当前登录的网站发出简单的 POST 请求，那么默认行为是不会发送 cookie，对吧？

另外，为什么有人会选择使用 Strict 而不是 Lax？为什么你会想要阻止用户的浏览器在导航到原始网站时向该网站发送 cookie，而这正是 Strict 所做的？

【问题讨论】：

标签： http cookies csrf same-origin-policy setcookie

【解决方案1】：

当SameSite 为Lax 时，CSRF 攻击仍然可能发生。它可以防止您提到的跨站点POST 攻击，但是如果网站通过GET 请求触发了不安全的操作，那么它仍然是可能的。例如，目前许多网站都会通过 GET 请求触发注销，因此攻击者将用户从会话中注销是微不足道的。

标准addresses this直接：

执法不严为 CSRF 提供了合理的纵深防御依赖不安全的 HTTP 方法（如“POST”）的攻击，但不依赖于不安全的 HTTP 方法（如“POST”）提供针对 CSRF 作为一般攻击类别的强大防御：

攻击者仍然可以弹出新窗口或触发顶层导航以创建“同一站点”请求（如在第 5.2.1 节中描述），这只是一个减速带剥削之路。

<link rel='prerender'> 等功能可以被利用来创建“同一站点”请求，而不会给用户带来风险检测。

鉴于此，有人会使用 Strict 的原因很简单：它可以防止更广泛的 CSRF 攻击。当然，这是一个权衡，因为它会阻止某些使用您网站的方式，但如果这些用例对您不重要，那么权衡可能是合理的。

【讨论】：

但是如果应用程序是 ReSTful 的，那么 GET 请求将是安全且幂等的。因此，cookie 与请求一起发送并不重要，因为唯一应该发生的事情是返回数据，由于 Same-Origin-Policy，无法查看该数据。我以前没有听说过使用 GET 提供注销功能的网站吗？我仍然不明白你的最后一点，如果用户的浏览器正在导航到源网站，你怎么能创建 CSRF 攻击？
@DavidKlempfner：但没有要求应用程序必须是“ReSTful”，并且原始 HTTP 规范不要求 GET 方法是安全的。我不明白你的最后一个问题（我没有说关于源服务器的任何内容），但重点很简单：如果Lax 允许一些 CSRF 攻击，并且这些攻击被Strict 阻止，那么原因使用Strict是为了更能抵抗CSRF攻击。
假设您通过单击超链接从“坏”网站导航到一个网站，为什么在该请求中发送 cookie 很重要（使用 Lax）？
@DavidKlempfner：如果该 cookie 识别并授权用户，则恶意站点可以代表用户采取行动。假设一个站点有一个端点，它将删除GET 请求中所有登录用户的数据。如果站点使用Lax，则恶意站点可以成功发起CSRF攻击并删除数据。如果站点使用Strict，则不能。当然，这将是一个糟糕的并且希望不常见的设计，这就是为什么Lax 在大多数情况下足够好（“提供合理的纵深防御”）。