security - 服务器端是否需要生成anti-XSRF/CSRF token？

Question

几乎所有关于反 CSRF 机制的文档都指出应该在服务器端生成 CSRF token 。不过，我想知道是否有必要。

我想在这些步骤中实现反 CSRF:

没有服务器端生成的 CSRF token ；

在浏览器端，在每次 AJAX 或表单提交时，我们的 JavaScript 都会生成一个随机字符串作为 token 。这个 token 被写入cookie csrf 在实际的 AJAX 或表单提交发生之前；并将 token 添加到参数 _csrf .

在服务器端，每个请求都应该有 cookie csrf 并提交论据 _csrf .比较这两个值。如果它们不同，则表示是 CSRF 攻击。

服务端不需要签发CSRF token，做校验即可；并且 token 完全在浏览器端生成。当然，这只是针对反CSRF。服务器端应该有身份验证过程来验证用户 ID。

这听起来是 CSRF 的有效解决方案，但我不确定为什么没有关于这种方法的文档。

这个反CSRF机制有什么问题吗？

Answer 1

据我了解，您要做的是在客户端创建您的反CSRF，将其存储在cookie中并将其添加为请求参数，因此当服务器读取您的请求时，只需验证您的CSRF token cookie 和参数匹配，它决定它是否是一个有效的请求。

在服务器端生成防伪 token 的原因是服务器会创建该 token 并​​且只有服务器知道正确的值，因此如果该参数在客户端被稍微篡改，它将与存储在服务器中的一个，这足以将请求标记为跨站点请求伪造攻击。
任何客户端生成的数据都可能被攻击者篡改，因此，您不能依赖该信息，例如，在您的方法中，您在客户端创建一个随机值并将该值分配给您的 CSRF cookie 和您的 _csrf 参数，假设您的值为“h246drvhd4t2cd98”，但由于您只是验证来自客户端的 2 个变量是否具有相同的值，因此攻击者可以轻松地创建他的 CSRF cookie 和变量它们都带有“I'mByPassingThis”之类的值，您的服务器会将其标记为有效请求，因此您根本无法获得安全性。
另一方面，如果 token 是在服务器中生成的，则攻击者无法知道预期值，并且每次请求时该值都会不同，因此攻击者最好的方法就是尝试猜测它，即应该几乎不可能，除非您在服务器端使用可预测的随机数生成器。

此外，如果您想创建自己的防伪 token 机制，则需要考虑使用加密安全的伪随机数生成器，但老实说，您不应该为此烦恼，因为当前的服务器生成过程只是你需要什么(假设你的框架有一个内置的机制，如果没有，那么你仍然需要确保你使用加密安全的伪随机数生成器来生成你的防伪 token )。

切记永远不要相信用户提交的信息。因为它总是可以被篡改，所以你总是需要在服务器端进行双重检查，在这种情况下，在服务器中生成你的防伪 token 可以让你双重检查以验证其完整性提交的防伪 token 。