是否应该对所有发布请求进行 CSRF 检查？

Question

据我了解，应该对任何更改状态的请求进行 CSRF 检查。

如果是这种情况，不是所有的 POST 请求都有 CSRF 检查吗？

如果不是这样，还有什么例外？

这个问题的起源来自关于使用 Firebase 管理会话 Cookie 的教程，他们在初始登录步骤中使用 CSRF 检查，但以后不用于发布请求

https://firebase.google.com/docs/auth/admin/manage-cookies#node.js_2

Answer 1

TL;DR:

1. 无论使用何种 HTTP 方法，都应在任何状态更改请求上实施 CSRF 保护（尽管 PUT 和 DELETE 请求本质上可以缓解 CSRF）
2. 要防止 CSRF，请使用下面编号列表中描述的方法之一。

详情：

如您所述，在 CSRF 攻击中，攻击者希望执行状态更改操作，例如修改个人资料的电子邮件地址、转账等。

应验证触发服务器上任何操作的任何身份验证后请求。 在登录屏幕上实施 CSRF 保护是没有意义的，因为攻击者需要知道用户的密码，如果他知道用户密码，那么 CSRF 攻击是多余的。 （免责声明 - 在某些边缘情况下，例如与 self-XSS 链接，登录屏幕上的 CSRF 可能会帮助攻击者）

仅返回数据但不执行任何操作的请求不需要 CSRF 保护，因为在 CSRF 攻击中，攻击者将无权访问服务器的响应。

CSRF 攻击之所以成为可能，是因为浏览器会自动将 cookie 发送到相应的域，而无需任何编程触发或用户交互。这也意味着将 CSRF 令牌放入 cookie 是没有意义的，也不会真正缓解 CSRF。

缓解措施：

也就是说，缓解 CSRF 攻击的方法不止一种：

1. 使用反 CSRF 令牌 - 一个唯一的随机值，通常存储为隐藏字段，作为发送请求的 HTML 表单的一部分。每个页面或至少每个用户会话的值应该​​是唯一的，并且在每个状态更改请求上由服务器验证。
2. 使用存储在 Web 存储 (sessionStorage/localStorage) 中的会话令牌，而不是 cookie。由于这些值需要以编程方式发送，通常是通过一些 SPA 框架并且不会自动发送，因此默认情况下会破坏 CSRF。
3. 在会话 cookie 上实现 "sameSite" flag。