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

php*_*ner 144 php csrf token

从我到目前为止所学到的,令牌的目的是防止攻击者伪造表单提交.

例如,如果某个网站的表单中添加了添加到购物车中的商品,并且攻击者可能会使用您不想要的商品向您的购物车发送垃圾邮件.

这是有道理的,因为购物车表单可能有多个有效输入,攻击者必须做的就是知道网站正在销售的项目.

我理解令牌如何工作并在这种情况下增加安全性,因为它们确保用户实际填写并按下表格中的"提交"按钮以添加到购物车中的每个项目.

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

由于用户名和密码非常独特,攻击者必须知道这两种情况才能使登录伪造工作(即使你没有设置令牌),如果攻击者已经知道这一点,他就可以登录网站本人.更不用说,使用户登录的CSRF攻击无论如何都没有任何实际意义.

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

nat*_*evw 113

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

否则,您的网站很容易受到某种"受信任的域名网上诱骗"攻击.简而言之,CSRF易受攻击的登录页面使攻击者能够与受害者共享用户帐户.

漏洞就像这样:

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

作为一个相关的例子,考虑YouTube.YouTube允许用户查看"他们自己的"观看记录的记录,他们的登录表单是CSRF易受攻击的!因此,作为一个结果,攻击者就可以设置了密码的帐户,他们知道,使用登录受害人到YouTube的那个盯梢的受害者在看什么视频-帐户.

这个评论主题中有一些讨论暗示它可以"仅"用于那样的隐私侵犯.也许,但引用维基百科的CSRF文章中的部分:

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

强调"小说攻击".想象一下网络钓鱼攻击对用户造成的影响,然后想象一下网络钓鱼攻击通过用户自己的可信书签进入您的网站!在前面提到的评论主题中链接的论文给出了一些超越简单隐私攻击的例子.

  • 是的,CSRF将保护登录表单*免受跨站点请求伪造*.适当的CSRF令牌在每次生成时都是加密唯一的.当然,攻击者可以自己获得一个*令牌*,但它仍然不会与受害者在浏览器中的[可能未设置]*cookie*匹配,并且攻击者无法在不损害好域名页面的情况下设置所述cookie .(你的例子似乎在CSRF和某种奇怪的网络钓鱼攻击之间有点混淆,所以我不确定我是否回答你的实际问题...) (8认同)
  • 我认为你最后的评论是错误的(你误解了A. Wilson所说的).我们说攻击者可以在一个客户端加载`http:// good.com/login.html`,解析嵌套的CSRF令牌,然后发布包含的http:// bad.com/login.html`一个修改过的表单,无论受害者输入什么内容,都会提交**他的**用户名,密码和令牌.CORS不适用,因为你有两个独立的客户端:攻击者和受害者.所以重申一个问题:CSRF保护是否真的适用于登录表单? (4认同)
  • CSRF保护如何提供帮助?有没有什么可以防止攻击者要求他自己的CSRF令牌,只是提交?由于不存在经过身份验证的会话,因此Web服务器没有理由更喜欢一个令牌而不是另一个令牌. (3认同)
  • 我可能错了,但如果用户意外地做了与购买物品相关的任何事情,那么似乎存在*重大*威胁.例如,攻击者欺骗用户登录到网站,并且用户继续购买物品而不会意识到他们在另一个帐户中(想想亚马逊或类似的).现在,攻击者可以访问已保存的付款信息,可以重定向购买等. (3认同)
  • "有什么东西阻止攻击者要求他自己的CSRF令牌,只是提交它吗?" - 是的!这是CSRF预防逻辑背后的整个假设.浏览器确实/允许表单提交以定位另一个来源,但他们从未[故意]允许JS跨站点_read_数据,除非现在通过选择加入CORS.除非您设置CORS错误,否则攻击者可以触发表单提交(可能包括*cookies*中的现有CSRF令牌)_but_无法*知道*令牌以发送所需的第二个副本(例如在正文/标题中) ).所以CSRF代码会拒绝. (2认同)

Jon*_*Jon 13

您的理解是正确的 - CSRF的重点在于攻击者可以事先伪造一个看似合法的请求.但是这不能通过登录表单来完成,除非攻击者知道受害者的用户名和密码,在这种情况下有更有效的攻击方式(登录自己).

最终,攻击者可以做的唯一事情是,当安全系统可能将用户锁定一段时间时,通过垃圾邮件发送失败登录会给您的用户带来不便.

  • 登录CSRF仍可用于攻击用户的隐私http://seclab.stanford.edu/websec/csrf/csrf.pdf (17认同)
  • @Jon是的,它可能不那么严重,但最终它不仅仅是不方便,即隐私侵犯.每项服务都必须自己定义威胁模型并进行相应处理.要做到这一点,您至少需要了解可能的威胁.这就是我加2美分的原因. (6认同)
  • @squiddle:这是一篇非常有趣的论文,感谢链接.但它取决于使用攻击者控制下的帐户登录用户*并且*假设用户不会意识到某些东西不正确*并且*假设用户将生成敏感信息,然后将其存储在服务器.所以恕我直言,它比"经典"CSRF严重得多. (5认同)
  • 哇超级快回复!非常感谢!现在我可以自信地继续建立我的网站。 (2认同)
  • 请您扩展一下他们将如何“最终,攻击者唯一能做的就是通过向您的用户发送失败的登录信息给您的用户带来不便,因为安全系统可能会将用户锁定一段时间。” (2认同)

jav*_*301 10

OWASP 在其 CSRF 文档中有一个专门的部分,介绍登录 CSRF 以及为什么/如何防止它。

基本上,在登录 CSRF 中,用户尝试以自己的身份登录网站,但实际上他们是以攻击者的身份登录的。然后,攻击者可以访问用户认为他们可能在其帐户中私下输入/更改的任何数据。

文章要点:


登录 CSRF 有多危险:

如果攻击者使用 CSRF 在购物网站上使用攻击者的帐户对受害者进行身份验证,然后受害者输入信用卡信息,则攻击者可能能够使用受害者存储的卡详细信息购买商品

如何解决:

可以通过创建预会话(用户经过身份验证之前的会话)并在登录表单中包含令牌来缓解登录 CSRF。

最后:

请记住,一旦用户通过身份验证,预会话就无法转换为真实会话 - 应销毁该会话并创建一个新会话

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

  • 这如何真正保护任何东西?攻击者可以独立获取有效的 CSRF 令牌并提交它,因为在这种情况下他已经拥有所需的一切。预会话同样毫无用处,因为攻击者只能利用他自己的预会话。 (2认同)