没有会话或数据库的安全 CSRF 保护？
Secure CSRF protection without sessions or database?
我正在尝试对 HTML 登录表单实施安全的 CSRF 保护，
我知道实现 CSRF 保护的最佳方法是在会话中随机存储 csrf_key，
但我想将 CSRF 添加到我的登录和注册表格中...我不想为任何匿名未注册用户存储许多会话...
所以我想在不使用会话或数据库的情况下创建最好的安全方案，仅使用表单隐藏字段/& cookie，登录后我将使用会话 csrf 保护。
我的安全想法 user_storage 只有 csrf:
csrf_token= AES(ip+用户代理+时间戳+random_data, csrf_aes_site_key)
当 csrf_aes_site_key 硬编码在配置文件中时。
在每个 login/register 之后，我将解密 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 保护的安全方法吗？
将 CSRF 令牌存储在 cookie 中的方法被广泛使用 (AngularJS, Django)，但它的工作方式有点不同。服务器在cookie中发送令牌，客户端使用JavaScript读取cookie并反射令牌在HTTP header。服务器应该只验证来自 HTTP header 的值，即使 cookie 也会自动发送。
实际的 cookie 和 header 名称并不重要，只要 JavaScript 前端和后端都知道它们。
这可以防止 CSRF，因为只有来自真实来源的 JavaScript 运行 才能读取 cookie（请参阅维基百科上的 detailed discussion）。令牌可以是 session cookie 的 HMAC，这样就无需在服务器端记住令牌状态。
主要优点是这种方法（与在表单字段中使用令牌的方法不同）适用于基于 single-page、JavaScript 的应用程序，您不会在其中生成 HTML服务器并不能真正将 CSRF 令牌嵌入到他们的代码中。
它适用于大多数客户端 - 但在客户端通过负载平衡代理（您看到的客户端 IP 发生变化）访问您的站点时会严重失败。更正确的解决方案是使用来自 whois 记录或 ASN 编号的组织数据，但查找这些数据会产生费用——具体取决于流量，仅使用 (IPV4) 地址的前 16 位可能就足够了。
您也可能 运行 遇到问题，具体取决于您存储了多少用户代理（Google Chrome 可以动态更新）。
我看起来很没有安全感。不要使用这个。登录表单和注册表单需要全面的 CSRF 保护；使用任何类型的降低保护都是不可接受的。
您的设置似乎很容易受到同一 NAT 后面的任何人（并因此共享 IP 地址）的攻击，这在人们的家中甚至许多工作场所都很常见。这是一个示例场景：
- 恶意同事（MC）在网站上注册了一个新帐户
- MC 计算出受害者的用户代理，这很容易做到
- MC 在发送受害者的用户代理时从网站获取 CSRF 令牌
- MC 制作了一个恶意网站，其中包含：
- 加载时自动提交的隐藏登录表单
- 上面的 CSRF 令牌
- 一个有趣的猫表情包
- MC 发送 link 给受害者说“哈哈，看看这个”
- 受害者喜欢模因，但现在在他们不知情的情况下登录网站
- MC 说服受害者开始使用该网站，在登录帐户上生成数据或元数据
- MC 可以查看所有这些数据，因为他们可以访问同一个帐户
步骤 3 到 6 可以在 5 分钟内轻松完成。
我正在尝试对 HTML 登录表单实施安全的 CSRF 保护， 我知道实现 CSRF 保护的最佳方法是在会话中随机存储 csrf_key， 但我想将 CSRF 添加到我的登录和注册表格中...我不想为任何匿名未注册用户存储许多会话...
所以我想在不使用会话或数据库的情况下创建最好的安全方案，仅使用表单隐藏字段/& cookie，登录后我将使用会话 csrf 保护。
我的安全想法 user_storage 只有 csrf:
csrf_token= AES(ip+用户代理+时间戳+random_data, csrf_aes_site_key)
当 csrf_aes_site_key 硬编码在配置文件中时。 在每个 login/register 之后，我将解密 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 保护的安全方法吗？
将 CSRF 令牌存储在 cookie 中的方法被广泛使用 (AngularJS, Django)，但它的工作方式有点不同。服务器在cookie中发送令牌，客户端使用JavaScript读取cookie并反射令牌在HTTP header。服务器应该只验证来自 HTTP header 的值，即使 cookie 也会自动发送。
实际的 cookie 和 header 名称并不重要，只要 JavaScript 前端和后端都知道它们。
这可以防止 CSRF，因为只有来自真实来源的 JavaScript 运行 才能读取 cookie（请参阅维基百科上的 detailed discussion）。令牌可以是 session cookie 的 HMAC，这样就无需在服务器端记住令牌状态。
主要优点是这种方法（与在表单字段中使用令牌的方法不同）适用于基于 single-page、JavaScript 的应用程序，您不会在其中生成 HTML服务器并不能真正将 CSRF 令牌嵌入到他们的代码中。
它适用于大多数客户端 - 但在客户端通过负载平衡代理（您看到的客户端 IP 发生变化）访问您的站点时会严重失败。更正确的解决方案是使用来自 whois 记录或 ASN 编号的组织数据，但查找这些数据会产生费用——具体取决于流量，仅使用 (IPV4) 地址的前 16 位可能就足够了。
您也可能 运行 遇到问题，具体取决于您存储了多少用户代理（Google Chrome 可以动态更新）。
我看起来很没有安全感。不要使用这个。登录表单和注册表单需要全面的 CSRF 保护；使用任何类型的降低保护都是不可接受的。
您的设置似乎很容易受到同一 NAT 后面的任何人（并因此共享 IP 地址）的攻击，这在人们的家中甚至许多工作场所都很常见。这是一个示例场景：
- 恶意同事（MC）在网站上注册了一个新帐户
- MC 计算出受害者的用户代理，这很容易做到
- MC 在发送受害者的用户代理时从网站获取 CSRF 令牌
- MC 制作了一个恶意网站，其中包含：
- 加载时自动提交的隐藏登录表单
- 上面的 CSRF 令牌
- 一个有趣的猫表情包
- MC 发送 link 给受害者说“哈哈，看看这个”
- 受害者喜欢模因，但现在在他们不知情的情况下登录网站
- MC 说服受害者开始使用该网站，在登录帐户上生成数据或元数据
- MC 可以查看所有这些数据，因为他们可以访问同一个帐户
步骤 3 到 6 可以在 5 分钟内轻松完成。