有没有人看到做以下事情以防止CSRF的任何缺点？

Question

我想知道以下方法是否完全阻止CSRF，并与所有用户兼容。

这是：

在表单中只包含一个额外的参数：encrypted(user's userID + request time)。服务器端只是解密并确保它是正确的用户ID，并且请求时间是合理的近期。

除了嗅探用户流量或破坏加密的人之外，这是否完全安全？有没有缺点？

Answer 1

虽然您的方法是安全的，但它不是标准的。防止CSRF攻击的标准方法是生成包含在隐藏字段和cookie中的伪随机数，然后在服务器端验证两个值是否匹配。看一下这个post。

Answer 2

一个主要的缺点是，如果用户在发布表单之前打开浏览器的时间长于您认为合理的时间范围，那么您的页面将“超时”。我更喜欢网站不要急于让用户做出他们的行动，除非这个动作本身就是时间敏感的。

Answer 3

它并不完全安全，因为攻击网站可能会猜出用户ID 如果您使用每会话加密密钥，则它是安全的。 （但是你需要做的就是发送原始密钥，而且它已经安全了）

另外，请记住时区和不准确的时钟。

Answer 4

应该有用，是的。虽然我建议您在创建新用户时使用随机数作为UserID，而不是简单的递增数字（显然，确保在创建用户时它是唯一的）。这样，攻击者很难“猜测”。

Answer 5

具有UserID和DateTime是一个开始，但是您还希望在金丝雀令牌中另外优选具有高熵的伪随机数值。基本上，您需要降低给定上下文中页面中令牌的可预测性。理论上只有UserID和DateTime可能会在一段时间后中断，因为它不是“随机的”。话虽如此，CSRF攻击通常是编写脚本而不是直接监控，因此根据您的应用程序的暴露程度，它可能就足够了。

此外，请确保使用更安全的加密算法，例如Rijndael/AES，其密钥位足以保证应用程序的安全性和伪随机初始化向量。

Answer 6

您提出的安全系统容易受到攻击。

像AES这样的分组密码通常用作非常安全的随机数生成器。它们被称为CSPRNGs。但是，像任何随机数生成器一样，您必须担心要为该算法播种的内容。在这种情况下，您使用的是user's userID + request time攻击者都可以知道的，您的实现没有密钥或IV，所以我认为它们是NULL。攻击者正在构建请求，因此他将始终知道request time。 userId可能是主键，如果您有100个用户，则攻击者可以伪造100个请求，其中一个将起作用。但攻击者可能只想强制管理员更改密码，管理员通常拥有1的主键。

不要重新发明风团，已经构建了非常好的随机数生成器，并且还有反csrf库。