没有会话或数据库的安全 CSRF 保护？

Question

我正在尝试对 HTML 登录表单实施安全的 CSRF 保护， 我知道实现 CSRF 保护的最佳方法是在会话中存储随机 csrf_key， 但我想将 CSRF 添加到我的登录和注册表单中......而且我不想为任何匿名未注册用户存储许多会话......

所以我想在不使用会话或数据库的情况下创建最好的安全可能，仅使用表单隐藏字段/& cookie，登录后我将使用会话 csrf 保护。

我的安全 user_storage only csrf 的想法：

csrf_token= AES(ip+useragent+timestamp+random_data, csrf_aes_site_key)

当 csrf_aes_site_key 在配置文件中硬编码时。 并且在每次登录/注册后，我将解密 AES 字符串 + 验证 ip&ua 是否与请求 ip&ua 匹配，并且时间戳不太匹配，比如说 5 分钟（如果 csrf_timestamp + 18000>=current_ts），并且 random_data 只是随机性（并确保同一用户在同一 ts 中多次请求时不会得到相同的 csrf_token）...

所以......它是否足够安全，这是一个好的解决方案吗？ 如果没有，还有其他解决这个困境的建议吗？ 谢谢！

编辑： 我刚刚创建的实现，它运行良好，但它是否足够好？

完整示例： https://github.com/itaiarbel/aes_based_csrf_protection

问题 1： 用户可以获取 csrf_token 并在接下来的 5 分钟内使用相同的令牌成功提交到表单 漏洞？如果用户提交多次，我关心什么？只要不是csrf攻击...

问题 2： 如果页面保持打开 5 分钟，用户将无法登录， （每 5 分钟自动刷新登录页面？可能改成 1 小时？）

您能发现此实施的任何特定安全风险吗？或者我可以假设这是一种安全的 CSRF 保护方式吗？

Answer 1

将 CSRF 令牌存储在 cookie 中的方法被广泛使用（AngularJS、Django），但它的工作方式略有不同。服务器在 cookie 中发送令牌，客户端使用 JavaScript 读取 cookie 并在 HTTP 标头 中反映令牌。服务器应该只验证来自 HTTP 标头的值，即使 cookie 也会自动发送。

实际的 cookie 和标头名称并不重要，只要 JavaScript 前端和后端都知道它们。

这会阻止 CSRF，因为只有从真实来源运行的 JavaScript 才能读取 cookie（参见维基百科上的 detailed discussion）。令牌可以是会话 cookie 的 HMAC，这样就避免了在服务器端记住令牌状态的需要。

主要优点是这种方法（与表单字段中带有标记的方法不同）适用于单页、基于 JavaScript 的应用程序，在这种应用程序中，您不会在服务器上生成 HTML，也不能真正将 CSRF 标记嵌入他们的代码。

Answer 2

它适用于大多数客户端 - 但在客户端通过负载平衡代理（您看到的客户端 IP 发生变化）访问您的站点时会严重失败。更正确的解决方案是使用来自 whois 记录或 ASN 编号的组织数据，但查找这些数据会产生费用 - 取决于流量，仅使用 (IPV4) 地址的前 16 位可能就足够了。

您也可能会遇到问题，具体取决于您存储了多少用户代理（Google Chrome 可以即时更新自身）。

Answer 3

在我看来非常不安全。不要使用这个。登录表单和注册表单需要完整的 CSRF 保护；使用任何类型的减少保护都是不可接受的。

您的设置似乎很容易被同一 NAT 后面的任何人攻击（因此共享 IP 地址），这在人们的家中甚至许多工作场所都很常见。这是一个示例场景：

1. 恶意同事 (MC) 在网站上注册了一个新帐户
2. MC 找出受害者的用户代理，这很容易做到
3. MC 在发送受害者的用户代理时从网站获取 CSRF 令牌
4. MC 制作了一个恶意网站，其中包含：
   • 加载时自动提交的隐藏登录表单
   • 上面的 CSRF 令牌
   • 一个有趣的猫模因
5. MC 向受害者发送链接说“大声笑，看看这个”
6. 受害者喜欢 meme，但现在在他们不知情的情况下登录了网站
7. MC 说服受害者开始使用网站，在登录的帐户上生成数据或元数据
8. MC 可以查看所有这些数据，因为他们可以访问同一个帐户

步骤 3 到 6 很容易在 5 分钟内完成。