在实现 Facebook 服务器端登录时，文档说我们的服务器应该提供一个状态字符串，Facebook 将在回调期间将其发回给我们。然后我们可以检查字符串是否匹配，以防止 CSRF 攻击。
由于 Rails 已经有一个在一个会话期间未更改的 CSRF 令牌，在 Facebook 或任何第 3 方授权过程中重复使用它是否存在安全风险？
我认为这可能没问题，因为第 3 方没有用户的 cookie，因此令牌将无用。
问问题
202 次
1 回答
2
我建议不要与第 3 方提供者共享 CSRF 令牌，因为由于第 3 方提供者的实施，您无法知道外部攻击者是否可以看到 CSRF 令牌。请注意，即使您能够验证 CSRF 令牌现在不可见，它也可能在 3rd 方提供者更改其实现后在未来可见。
（如果由于第三方实现，外部攻击者可以看到 CSRF 令牌，则攻击者可以获得访问者 cookie 的匹配 CSRF 令牌，并对您的站点发起 CSRF 攻击。当然，这样的攻击会比没有 CRSF 更难完全保护，但您问这是否存在安全风险。）
如果您不想为服务器存储额外的状态，您可以通过使用静态 3rd 方可配置机密并使用真正的 Rails CSRF 令牌和该机密执行 HMAC-SHA1 来创建特定于 3rd 方的 CSRF 值。使用生成的哈希作为第 3 方 CRSF 值。如果您支持许多第三方提供商，则稍微偏执的版本可以为每个 3rd 方提供者使用加盐和单独的秘密。这个想法是即使对第 3 方也隐藏真正的 CSRF 令牌。
我不知道在使用 Rails 的 3rd 方登录过程中使用自定义 CSRF 验证会有多难...
于 2013-06-04T08:17:23.660 回答