禁用CSRF保护有时是否合理?

时间:2011-04-08 10:42:17

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

我正在考虑登录表单:

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

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

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

在这种情况下,我是否遗漏了一些安全考虑因素?

2 个答案:

答案 0 :(得分:2)

很棒的问题!让我挠了一下头。

攻击者已经通过其他方式获取受害者密码,但无法访问该网站的情况怎么样?他欺骗他的受害者前往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攻击无需对实际在系统上拥有帐户的用户执行,只需对具有该网站网络访问权限的用户执行。

答案 1 :(得分:1)

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

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