X-CSRF-TOKEN 或 X-XSRF-TOKEN 有什么意义，为什么不使用严格的相同站点 cookie？答案

【问题标题】：What is the point of X-CSRF-TOKEN or X-XSRF-TOKEN, why not just use a strict same site cookie?X-CSRF-TOKEN 或 X-XSRF-TOKEN 有什么意义，为什么不使用严格的相同站点 cookie？
【发布时间】：2022-11-09 17:47:37
【问题描述】：

laravel 等框架要求您将 csrf 令牌放在 HTML 表单中。

然而与此同时，laravel 默认带有 VerifyCsrfToken 中间件，它会在每个响应上自动创建一个带有 csrf 令牌的 X-XSRF-TOKEN cookie。此 cookie 用于 ajax 请求，例如 automatically added 到 axios 的标头。

我想知道为什么需要将 csrf 令牌添加到每个 HTML 表单。为什么不能只使用已经存在的X-XSRF-TOKEN cookie 来验证 csrf 令牌。我知道存在相同站点 cookie 的问题，如果您的 csrf cookie 设置为 lax 或 none，如果他们将 POST 到我的站点，cookie 将从外部站点发送。然而，这个问题可以通过将同一站点设置为strict 来解决，那么就不需要在每个表单上都设置 csrf 令牌，这有点烦人。

关于为什么我们不能使用strict cookie 来验证 csrf 令牌，我是否缺少一些安全问题？

【问题讨论】：

标签： laravel security cookies csrf csrf-token

【解决方案1】：

SameSite cookie 确实提供了针对 CSRF 攻击的重要保护。但最好采取明确的对策——由反 CSRF 令牌提供。

一方面，SameSite 使用“可注册域”的概念，因此它不能保护您免受 subdomain hijacking 的侵害

最后，对于这些主题，我非常推荐一本优秀的书Api Security in Action——它们在第 4 章讨论 CSRF 和相关主题。

【讨论】：

我了解反 CSRF 令牌的好处，但我不明白将它们包含在 ajax 请求的标头中的目的，而不是直接将 cookie 作为同一个站点严格 cookie 发送。这样做有什么安全问题吗？关于子域劫持，也可以使用 ajax 请求中的标头来完成，因此我看不出使用 cookie 与使用标头有太大区别。
因为您想要证明发送请求的是真正的客户端，而不是绕过安全措施的攻击者。如果您使用 cookie，您将很容易受到我上面所说的子域劫持。这是浏览器自动发送 cookie 的问题。为了解决这个问题，我们通常将 HTML 页面内的反 CSRF 令牌呈现为隐藏的输入字段，但是对于通过 API 进行通信的单页面应用程序，您没有 HTML，因此您将其发送到标头中，然后验证客户端是否实际发送了令牌当他们发出 POST 请求时返回。
同样，这一切都在书中进行了讨论——更清晰，更详细。

【解决方案2】：

通过 cookie 验证 csrf 令牌是没有意义的。这就是我们试图解决的问题。如果 csrf 令牌作为 cookie 被发送和验证，它也可以被发送，并在跨站点请求中发送。但是，据我所知，在进行跨站点请求时，攻击者无法使用 js 读取该 cookie 并将其放入表单中，只有我们可以使用 js 访问该 cookie。这就是为什么该 cookie 不仅仅是 http 的原因，也是我们将它包含在表单中的原因。

【讨论】：