几乎所有关于反CSRF机制的文档都声明应该在服务器端生成CSRF令牌。但是，我想知道是否有必要。
我想在这些步骤中实施反CSRF：
没有服务器端生成的CSRF令牌;
在浏览器方面，在每个AJAX或表单提交时，我们的JavaScript会生成一个随机字符串作为标记。在实际的AJAX或表单提交发生之前，此令牌将写入cookie csrf ;并且令牌作为 _csrf 添加到参数。
在服务器端，每个请求都应该包含cookie csrf 并提交参数 _csrf 。比较这两个值。如果它们不同，则意味着它是CSRF攻击。
服务器端不需要发出CSRF令牌，只需进行检查;并且令牌完全在浏览器端生成。当然，这仅适用于反CSRF。服务器端应该有身份验证过程来验证用户ID。
这听起来是CSRF的有效解决方案，但我不确定为什么没有关于这种方法的文档。
这种反CSRF机制是否有任何错误？
答案 0 :(得分：2)
据我了解，您要做的是在客户端创建反CSRF，将其存储在cookie中并将其添加为请求参数，因此当服务器读取您的请求时，只需验证您的CSRF令牌cookie和参数匹配，并确定它是否是有效请求。
在服务器端生成防伪令牌的原因是服务器将创建该令牌，只有服务器才会知道正确的值，因此如果该参数在客户端略有篡改，则不会与存储在服务器中的那个相同，这足以将请求标记为跨站点请求伪造攻击。 任何客户端生成的数据都可能被攻击者篡改，因此，您无法依赖该信息，例如，在您的方法中，您在客户端创建随机值并将该值分配给你的CSRF cookie和你的_csrf参数，让我们说你的价值是＆＃34; h246drvhd4t2cd98＆＃34;，但是因为你只是验证来自客户端的2个变量具有相同的值，攻击者可以轻松地创建他的CSRF cookie和变量，其价值类似于＆＃34;我＆＃39; mByPassingThis＆＃34;在它们和服务器上都会将其标记为有效请求，因此您根本无法获得安全性。 另一方面，如果令牌是在服务器中生成的，则攻击者无法知道预期值，并且每个请求的值都会有所不同，因此攻击者的最佳方法就是尝试猜测它，这几乎是不可能的，除非您在服务器端使用可预测的随机数生成器。
另外，如果你想创建自己的防伪令牌机制，你需要考虑使用加密安全的伪随机数生成器，但老实说，你不应该为此烦恼，因为当前的服务器生成进程正是你所需要的（假设你的框架有一个内置的机制，如果没有，那么你仍然需要确保你使用加密安全的伪随机数生成器来生成你的防伪令牌）。
切记永远不要相信用户提交的信息。由于它总是可以被篡改，所以你总是需要在服务器端进行仔细检查，在这种情况下，在服务器中生成防伪令牌是允许你仔细检查以验证其完整性的原因。提交了反伪造令牌。
答案 1 :(得分：0)
我建议使用这种方法，因为我已经在大型项目中使用过
自定义请求标题的使用
添加CSRF令牌，双重提交cookie和值，加密令牌或涉及更改UI的其他防御措施通常很复杂，否则会引起问题。特别适合AJAX或API端点的另一种防御方法是使用自定义请求标头。这种防御依赖于同源策略（SOP）限制，即仅JavaScript可以用于添加自定义标头，并且只能在其起源内使用。默认情况下，浏览器不允许JavaScript使用自定义标头进行跨源请求。 如果您的系统是这种情况，则只需验证所有服务器端AJAX端点上此标头和值的存在即可防止CSRF攻击。这种方法具有双重优势，即通常不需要更改UI且不引入任何服务器端状态，这对REST服务特别有吸引力。如果愿意，您总是可以添加自己的自定义标头和值。 该技术显然适用于AJAX调用，您仍然需要使用本文档中介绍的方法（例如令牌）来保护标签。另外，CORS配置还应具有健壮性，以使该解决方案有效运行（因为来自其他域的请求的自定义标头会触发飞行前CORS检查）。
因此，您可以通过请求标头参数存储并发送到服务器，而不是通过请求正文参数发送令牌。