我特别考虑登录表单：
由于其本质，登录表单会阻止任意输入的操作——如果没有有效的用户名和密码，您将被弹回。这些表单是否需要添加authenticity_token或类似的跨站请求伪造保护呢？
我想知道登录表单是否是CSRF甚至普遍不受欢迎的一个例子：
对于匿名客户端，应该允许第一次与站点接触就POST有效的登录凭据。CSRF通过首先要求客户端执行GET以建立匿名会话cookie来防止这种直接交互，该cookie用作其authenticity_token的基础。然后必须使用登录凭据再次提交令牌。当实际目标是对试图提供凭据而没有会话的用户进行身份验证时，额外的前置步骤似乎毫无意义。
在这种情况下，我是否忽略了某些安全考虑？
非常棒的问题！让我想了好一阵子。
如果攻击者已经通过其他途径获取了受害者的密码，但无法访问网站，该怎么办？他会欺骗受害者进入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攻击不一定要针对实际上在系统中拥有帐户的用户进行，只需要对具有对该网站的网络访问权限的用户进行即可。
没有XSRF保护，攻击者可以将用户登录到恶意账户，从而跟踪他们的活动。这在Robust Defenses for Cross-Site Request Forgery中有所讨论。
我不明白为什么客户端应该能够POST登录凭据作为第一点联系。对于Web界面，在大多数实际情况下，客户端必须GET登录页面以检索表单。