Php 登录表单是否需要令牌来抵御CSRF攻击？

据我目前所知，令牌的用途是防止攻击者伪造表单提交

例如，如果一个网站有一个表单，该表单将添加的项目输入到您的购物车中，那么攻击者可能会向您的购物车发送垃圾邮件，其中包含您不想要的项目

这很有意义，因为购物车表单可能有多个有效输入，攻击者只需知道网站正在销售的商品

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

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

由于用户名和密码是非常唯一的，攻击者必须知道这两个信息才能进行登录伪造（即使您没有设置令牌），如果攻击者已经知道，他可以自己登录网站。更不用说，让用户自己登录的CSRF攻击也没有任何实际用途

---

我对CSRF攻击和令牌的理解是否正确？正如我所怀疑的那样，它们对用户登录表单毫无用处吗？

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

---

最终，攻击者唯一能做的事情就是向失败的登录发送垃圾邮件，给用户带来不便，因为安全系统可能会将用户锁定一段时间。

是的。一般来说，您需要像其他任何人一样保护您的登录表单免受CSRF攻击

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

该漏洞的表现如下：

攻击者在受信任域上创建主机帐户

攻击者使用此主机帐户的凭据在受害者的浏览器中伪造登录请求

攻击者诱使受害者使用受信任的站点，他们可能不会注意到他们是通过主机帐户登录的

攻击者现在可以访问受害者在使用主机帐户登录浏览器时“创建”（有意或无意）的任何数据或元数据

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

其中有一些讨论暗示它“只能”用于类似的隐私侵犯。也许吧，但引用以下章节：

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

---

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

CSRF验证预登录在IMHO中没有太多意义

感谢@squiddle提供的链接：，我们可以在第一页阅读：

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.

如果您尝试在登录前进行CSRF验证，则可能会让攻击者有机会窃取您网站的有效代码！然后，他/她将能够重新张贴违背目的的代币

---

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

是，因此其他网站无法模仿您的登录形式！就这么简单

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

• 第一：你不会允许的
• 第二：即使是非常简单的故障情况，如：
  • 可以避免由于密码不正确而阻塞用户的次数
  • Flase黑客警报是可以防止的。等等

OWASP在其CSRF文档中有一个地址，用于处理登录CSRF以及为什么/如何防止它。 要点：

---

登录CSRF的危险程度： 如果攻击者使用CSRF对购物网站上的受害者进行身份验证 网站使用攻击者的帐户，然后受害者输入他们的帐户 信用卡信息，攻击者可以购买物品 使用受害者存储的卡详细信息

如何解决这个问题： 登录CSRF可以通过创建预会话（之前的会话）来缓解 用户经过身份验证）并以登录形式包含令牌

最后： 请记住，预会话不能转换为实际会话 一旦用户通过身份验证，会话就应该被销毁，并且 应该做一个新的

---

请注意，这种缓解方法还可以防止会话固定漏洞，因为登录后重新生成会话是这种方法的一部分。

Wow Super-fast reply！非常感谢！现在我可以自信地继续建立我的网站了。登录CSRF仍然可以用来攻击用户@squiddle的隐私：这是一篇非常有趣的文章，谢谢你的链接。但它依赖于使用攻击者控制下的帐户登录用户，并假设用户不会意识到某些错误，并假设用户将生成敏感信息，然后这些信息将存储在服务器上。所以我觉得它没有“经典”那么严重