我特别在考虑登录表单:
就其性质而言，登录表单会阻止对任意输入的操作——如果没有有效的用户名和密码，您只会被退回。这些甚至需要添加 authenticity_token 是否有原因？或类似的跨站点请求伪造保护？
我很好奇登录表单是否是 CSRF 甚至可能通常不受欢迎的一个例子:
给定一个匿名客户端，应该允许与站点的第一个联系点是发布有效的登录凭据。 CSRF 通过首先要求客户端执行 GET 以建立匿名 session cookie 来防止这种直接交互，该 cookie 用作其真实性_token 的基础。然后必须使用登录凭据回发 token 。当此处的实际目标是验证未通过 session 到达并试图提供其凭据的用户时，额外的前期步骤似乎毫无意义。
在这种情况下，我是否遗漏了一些安全考虑？
最佳答案
很棒的问题!这让我挠了一阵子。
攻击者已经通过其他方式获取了受害者的密码，但自己无法访问网站的情况如何？他欺骗他的受害者进入 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 攻击不需要对实际在系统上拥有帐户的用户执行，只需对具有该站点的网络访问权限的用户执行即可。
关于ruby-on-rails - 有时禁用 CSRF 保护是合理的吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5593934/