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

发布于 2024-10-31 04:40:12 字数 362 浏览 4 评论 0原文

我特别想到登录表单:

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

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

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

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

I'm thinking of login forms in particular:

By their nature, login forms block action on arbitrary input — without a valid username and password, you just get bounced. Is there a reason why these even need the addition of authenticity_token or similar cross-site request forgery protection at all?

I'm curious if login forms are one example where CSRF might even be generally undesirable:

Given an anonymous client, it should be allowed that the first point of contact with a site is to POST valid login credentials. CSRF prevents this direct interaction by first requiring that the client perform a GET to establish an anonymous session cookie, which is used as the basis for their authenticity_token. The token must then be posted back with the login credentials. The extra up-front step seems pointless when the actual goal here is to authenticate a user who arrives without a session and is trying to give their credentials.

Am I missing some security consideration in this scenario?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

绿光 2024-11-07 04:40:12

很棒的问题!这让我挠头一阵子。

那么如果攻击者已经通过其他方式获取了受害者的密码,但自己无法访问该网站呢?他欺骗受害者访问 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 攻击不需要对实际拥有系统帐户的用户执行,只需对具有该站点网络访问权限的用户执行即可。

Awesome question! It had me scratching my head for a while.

What about the scenario where the attacker has already acquired the victim's password by other means, but doesn't have access to the website himself? He tricks his victim into going to www.evil.com and has this on the initial page:

<image src="http://portal.internal/login.php?user=root&password=hunter2"/>

This convinces the victim's browser to authenticate the victim to the site. Then, on another page of www.evil.com, there is another image tag:

<image src="http://portal.internal/deleteEverything.php/>

In this case, the attacker must use CSRF to gain access the internal site, since he has no other way to access it. Also, note that this CSRF attack need not be executed on a user who actually has an account on the system, only a user who has network access to the site.

相思碎 2024-11-07 04:40:12

如果没有 XSRF 保护,攻击者可以将用户登录到恶意帐户,并使用该帐户来跟踪他们的活动。 针对跨站点请求伪造的强大防御。

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

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文