6

我特别考虑登录表单：

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

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

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

在这种情况下，我是否缺少一些安全考虑？

4

2 回答 2

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 攻击不需要对实际拥有系统帐户的用户执行，只需对具有网络访问该站点的用户执行。

于 2011-04-09T03:29:48.410 回答
1

Without XSRF protection, an attacker could log the user into a malicious account, which they could use to track their activity. This is discussed in Robust Defenses for Cross-Site Request Forgery.

I don't see why the client should be able to POST login credentials as a first point of contact. For a web interface, in most practical cases the client has to GET the login page to retrieve the form.

于 2011-10-02T00:28:01.147 回答