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

我正在考虑登录表格: 就其本质而言,登录表单会阻止对任意输入的操作 - 如果没有有效的用户名和密码,您只会被退回。有没有理由为什么这些甚至需要添加
authenticity_token
或类似的跨站点请求伪造保护呢? 我很好奇登录表单是CSRF甚至可能通常不受欢迎的一个例子: 给定一个匿名客户端,应该允许与站点的第一个联系点是POST有效的登录凭据。 CSRF通过首先要求客户端执行GET来建立匿名会话cookie来防止这种直接交互,该cookie用作其authenticity_token的基础。然后必须使用登录凭据回发令牌。当这里的实际目标是验证没有会话到达并且试图提供其凭据的用户时,额外的前期步骤似乎毫无意义。 我在这种情况下是否缺少一些安全考虑因素?     
已邀请:
如果没有XSRF保护,攻击者可以将用户登录到恶意帐户,他们可以使用它来跟踪他们的活动。这在Robust Defenses for Cross-Site Request Forgery中进行了讨论。 我不明白为什么客户端应该能够将登录凭据作为第一联系人。对于Web界面,在大多数实际情况中,客户端必须获取登录页面才能检索表单。     
真棒的问题!它让我挠了一会儿。 如果攻击者已经通过其他方式获取了受害者的密码,但是自己无法访问该网站,那么该怎么办?他欺骗受害者前往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攻击无需对实际在系统上拥有帐户的用户执行,只需对具有该站点的网络访问权限的用户执行。     

要回复问题请先登录注册