有时禁用 CSRF 保护是合理的吗？答案

【问题标题】：Is disabling CSRF protection sometimes justified?有时禁用 CSRF 保护是合理的吗？
【发布时间】：2011-08-01 10:11:11
【问题描述】：

我正在特别考虑登录表单：

就其性质而言，登录表单会阻止对任意输入的操作——如果没有有效的用户名和密码，您就会被退回。为什么这些甚至需要添加authenticity_token 或类似的跨站点请求伪造保护？

我很好奇登录表单是否是 CSRF 通常不受欢迎的一个例子：

给定一个匿名客户端，应该允许与站点的第一个联系点是发布有效的登录凭据。 CSRF 通过首先要求客户端执行 GET 以建立匿名会话 cookie 来防止这种直接交互，该 cookie 用作其authentity_token 的基础。然后必须使用登录凭据发回令牌。当这里的实际目标是验证没有会话到达并试图提供其凭据的用户时，额外的前期步骤似乎毫无意义。

在这种情况下我是否遗漏了一些安全注意事项？

【问题讨论】：

标签： ruby-on-rails security csrf authenticity-token

【解决方案1】：

真棒的问题！这让我摸不着头脑。

攻击者已经通过其他方式获取了受害者的密码，但自己无权访问网站的场景呢？他诱骗受害者访问 www.evil.com，并在初始页面上显示：

<image src="http://portal.internal/login.php?user=root&password=hunter2"/>

这会说服受害者的浏览器对网站的受害者进行身份验证。然后，在 www.evil.com 的另一个页面上，又多了一个图片标签：

<image src="http://portal.internal/deleteEverything.php/>

在这种情况下，攻击者必须使用 CSRF 来访问内部站点，因为他没有其他方法可以访问它。另外，请注意，此 CSRF 攻击不需要对实际在系统上拥有帐户的用户执行，只需对具有网络访问该站点的用户执行。

【讨论】：

这样的操作一开始就不应该被 http GET 请求访问，尤其是破坏性的：在我看来，这是一个比 CSRF 更大的问题。
是的。但话又说回来，假设不存在这样的 GET-able 操作会更糟。
对于遵循标准 Rails 约定的 Rails 应用程序，尤其是 Rails 3 应用程序，这通常是一个不错的假设。

【解决方案2】：

如果没有 XSRF 保护，攻击者可以将用户登录到恶意帐户，他们可以使用该帐户来跟踪他们的活动。这在Robust Defenses for Cross-Site Request Forgery 中进行了讨论。

我不明白为什么客户端应该能够将登录凭据作为第一联系点。对于 Web 界面，在大多数实际情况下，客户端必须 GET 登录页面才能检索表单。

【讨论】：

感谢您的链接，这是很好的阅读。我认为 Web 服务 API 是一个合理的地方，客户端在提交凭据之前不必先获取登录页面。
如果它是一个 Web 服务，并且您只是在响应中为将来的请求发送一个令牌（不设置 cookie），这不应该是一个问题，因为它不会导致任何一方对用户的影响。