php 登录表单是否需要针对 CSRF 攻击的令牌？

Do login forms need tokens against CSRF attacks?

提问by php_learner

From what I've learned so far, the purpose of tokens is to prevent an attacker from forging a form submission.

从我目前了解到的情况来看，令牌的目的是防止攻击者伪造表单提交。

For example, if a website had a form that input added items to your shopping cart, and an attacker could spam your shopping cart with items you don't want.

例如，如果网站有一个表单将添加的商品输入到您的购物车中，那么攻击者可能会将您不想要的商品发送到您的购物车中。

This makes sense because there could be multiple valid inputs for the shopping cart form, all the attacker would have to do is know an item that the website is selling.

这是有道理的，因为购物车表单可能有多个有效输入，攻击者所要做的就是知道网站正在销售的商品。

I understand how tokens work and add security in this case, because they ensure the user has actually filled in and pressed the "Submit" button of the form for each item added to the cart.

我了解令牌在这种情况下如何工作并增加安全性，因为它们确保用户已实际填写并按下添加到购物车的每个项目的表单的“提交”按钮。

However, do tokens add any security to a user login form, which requires a username and password?

但是，令牌是否为需要用户名和密码的用户登录表单添加了任何安全性？

Since the username and password are very unique the attacker would have to know both in order for the login forgery to work (even if you didn't have tokens setup), and if an attacker already knew that, he could just sign onto the website himself. Not to mention, a CSRF attack that makes the user log himself in wouldn't have any practical purpose anyway.

由于用户名和密码非常独特，攻击者必须知道两者才能使登录伪造生效（即使您没有设置令牌），如果攻击者已经知道这一点，他就可以登录网站他自己。更不用说，使用户自己登录的 CSRF 攻击无论如何都没有任何实际目的。

Is my understanding of CSRF attacks and tokens correct? And are they useless for user login forms as I suspect?

我对 CSRF 攻击和令牌的理解是否正确？我怀疑它们对用户登录表单没有用吗？

回答by natevw

Yes. In general, you need to secure your login forms from CSRF attacks just as any other.

是的。通常，您需要像其他任何方式一样保护您的登录表单免受 CSRF 攻击。

Otherwise your site is vulnerable to a sort of "trusted domain phishing" attack. In short, a CSRF-vulnerable login page enables an attacker to share a user account with the victim.

否则，您的站点很容易受到某种“受信任的域网络钓鱼”攻击。简而言之，CSRF 易受攻击的登录页面使攻击者能够与受害者共享用户帐户。

The vulnerability plays out like this:

该漏洞的表现如下：

1. The attacker creates a host account on the trusted domain
2. The attacker forges a login request in the victim's browser with this host account's credentials
3. The attacker tricks the victim into using the trusted site, where they may not notice they are logged in via the host account
4. The attacker now has access to any data or metadata the victim "created" (intentionally or unintentionally) while their browser was logged in with the host account

1. 攻击者在受信任域上创建主机帐户
2. 攻击者使用此主机帐户的凭据在受害者的浏览器中伪造登录请求
3. 攻击者诱骗受害者使用受信任的站点，他们可能不会注意到他们是通过主机帐户登录的
4. 攻击者现在可以访问受害者在使用主机帐户登录浏览器时“创建”（有意或无意）的任何数据或元数据

As a pertinent example, consider YouTube. YouTube allowed users to see a record of "their own" viewing history, and their login form was CSRF-vulnerable! So as a result, an attacker could set up an account with a password theyknew, log the victim into YouTube using thataccount — stalking what videos the victim was watching.

作为一个相关的例子，考虑YouTube。YouTube 允许用户查看“他们自己”的观看历史记录，并且他们的登录表单存在 CSRF 漏洞！因此，攻击者可以使用他们知道的密码设置一个帐户，使用该帐户将受害者登录到 YouTube - 跟踪受害者正在观看的视频。

There's some discussion in this comment threadthat implies it could "only" be used for privacy violations like that. Perhaps, but to quote the section in Wikipedia's CSRF article:

此评论线程中有一些讨论暗示它可以“仅”用于此类侵犯隐私的行为。也许，但引用维基百科 CSRF 文章中的部分：

Login CSRF makes various novel attacks possible; for instance, an attacker can later log in to the site with his legitimate credentials and view private information like activity history that has been saved in the account.

登录CSRF使各种新颖的攻击成为可能；例如，攻击者稍后可以使用其合法凭据登录该站点，并查看已保存在帐户中的活动历史记录等私人信息。

Emphasis on "novel attacks". Imagine the impact of a phishing attack against your users, and then imagine said phishing attack working via the user's own trusted bookmark to your site! The paper linked in the aforementioned comment thread gives several examples that go beyond simple privacy attacks.

强调“新型攻击”。想象一下网络钓鱼攻击对您的用户的影响，然后想象一下通过用户自己的可信书签对您的站点进行的网络钓鱼攻击！上述评论线程中链接的论文给出了几个超越简单隐私攻击的示例。

回答by Jon

Your understanding is correct -- the whole point of CSRF is that the attacker can forge a legitimate-looking request from beforehand. But this cannot be done with a login form unless the attacker knows the victim's username and password, in which case there are more efficient ways to attack (log in yourself).

您的理解是正确的——CSRF 的全部意义在于攻击者可以事先伪造一个看似合法的请求。但这不能通过登录表单完成，除非攻击者知道受害者的用户名和密码，在这种情况下，有更有效的攻击方式（自己登录）。

Ultimately the only thing that an attacker can do is inconvenience your users by spamming failed logins, when the security system might lock out the user for a period of time.

最终，攻击者唯一能做的就是通过向您的用户发送失败的登录信息给您的用户带来不便，因为安全系统可能会将用户锁定一段时间。

回答by mayankcpdixit

Yes, So other websites can't mimic your login form! As simple as that.

是的，所以其他网站无法模仿您的登录表单！就如此容易。

What can they achieve by doing it?

他们可以通过这样做实现什么？

• First: you don't wanna allow that.
• Second: Even very simple failure cases like:
  • blocking user due to incorrect password nno. of times, can be avoided.
  • Flase hacking alerts can be prevented. etc etc.

• 第一：你不想允许。
• 第二：即使是非常简单的失败案例，例如：
  • 由于密码n不正确而阻止用户。次，是可以避免的。
  • 可以防止 Flase 黑客警报。等等等等

回答by Patrice Gagnon

CSRF validation pre-login doesn't make too much sense IMHO.

恕我直言，CSRF 验证登录前没有太大意义。

Thanks to @squiddle for the link: seclab.stanford.edu/websec/csrf/csrf.pdf, we can read on the very first page:

感谢@squiddle 提供链接：seclab.stanford.edu/websec/csrf/csrf.pdf，我们可以在第一页阅读：

The most popular CSRF defense is to include a secret
token with each request and to validate that the received
token is correctly bound to the user's session,
preventing CSRF by forcing the attacker to guess the
session's token.

If you attempt CSRF validation pre-login, then you give a potential attacker the opportunity to scrape a valid code of your web site! He/she would then be able to re-post the token defeating the purpose.

如果您在登录前尝试 CSRF 验证，那么您就给了潜在的攻击者机会来抓取您网站的有效代码！然后他/她将能够重新发布破坏目的的令牌。

Perhaps an attacker can then try to guess a username of your site. What I've done, if the IP address tries to guess say 10 usernames without success, I simply black list it.

也许攻击者可以尝试猜测您网站的用户名。我所做的，如果 IP 地址尝试猜测说 10 个用户名而没有成功，我只是将其列入黑名单。