几乎所有关于反CSRF机制的文档都声明应该在服务器端生成CSRF令牌 . 但是，我想知道是否有必要 .
我想在这些步骤中实现反CSRF：
-
没有服务器端生成的CSRF令牌;
-
在浏览器方面，在每个AJAX或表单提交上，我们的JavaScript生成一个随机字符串作为标记 . 在实际的AJAX或表单提交发生之前，此令牌将写入cookie csrf ;并将令牌添加到参数 _csrf .
-
在服务器端，每个请求都应该有cookie csrf 并且提交参数 _csrf . 比较这两个值 . 如果它们不同，则表示它是CSRF攻击 .
服务器端不需要发出CSRF令牌，只需进行检查;并且令牌完全在浏览器端生成 . 当然，这仅适用于反CSRF . 服务器端应该有身份验证过程来验证用户ID .
这听起来是CSRF的有效解决方案，但我不确定为什么没有关于这种方法的文档 .
这种反CSRF机制是否有任何错误？
1 回答
据我所知，您要做的是在客户端创建反CSRF，将其存储在cookie中并将其添加为请求参数，因此当服务器读取您的请求时，只需验证您的CSRF令牌cookie和参数匹配，它决定它是否是有效请求 .
在服务器端生成防伪令牌的原因是服务器将创建该令牌，并且只有服务器才知道正确的值，因此如果该参数在客户端被轻微篡改，则它将不同于存储在服务器中的那个，这足以将请求标记为跨站点请求伪造攻击 . 任何客户端生成的数据都可能被攻击者篡改，因此，您不能依赖该信息，例如，在您的方法中，您在客户端创建随机值并将该值分配给CSRF cookie和你的_csrf参数，假设您的值是“h246drvhd4t2cd98”，但由于您只是验证来自客户端的2个变量具有相同的值，攻击者可以轻松地创建他的CSRF cookie和变量像这里的“I'ByPassingThis”这样的值，您的服务器会将其标记为有效请求，因此您根本没有获得安全性 . 另一方面，如果在服务器中生成令牌，则攻击者无法知道预期值，并且该值在每个请求上都会有所不同，因此攻击者的最佳方法就是尝试猜测它，应该几乎不可能，除非你在服务器端使用可预测的随机数生成器 .
此外，如果你想创建自己的防伪令牌机制，你需要考虑使用加密安全的伪随机数生成器，但老实说，你不应该打扰它，因为当前的服务器生成过程只是你需要什么（假设你的框架有一个内置的机制，如果没有，那么你仍然需要确保你使用加密安全的伪随机数生成器来生成你的防伪标记） .
切记永远不要相信用户提交的信息 . 由于它总是可以被篡改，所以你总是需要在服务器端进行一次双重检查，在这种情况下，在服务器中生成防伪令牌是允许你仔细检查以验证其完整性的原因 . 提交了防伪令牌 .