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


161

根据到目前为止的了解,令牌的目的是防止攻击者伪造表单提交。

例如,如果某个网站的表单向您的购物车中输入了添加的商品,那么攻击者可能会向您的购物车中发送您不想要的商品。

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

我了解令牌在这种情况下的工作原理并增加了安全性,因为它们可确保用户实际上已填写并为添加到购物车中的每个商品按下了表单的“提交”按钮。

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

由于用户名和密码非常独特,攻击者必须知道两者才能使登录伪造正常工作(即使您没有设置令牌),并且如果攻击者已经知道,则可以登录网站他自己。更不用说,使用户登录自己的CSRF攻击也没有任何实际用途。

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


他们可以劫持您的路由器,因为您可能在该路由器上使用默认密码,并且该密码不受CSRF保护,无法登录。
AbiusX 2014年

是的,因此其他网站无法模仿您的登录表单。他们可以做到这一点吗?首先,您不想这么做。第二:非常容易的失败案例,例如由于密码错误而阻止用户。的时间,是可以避免的。
mayankcpdixit

Answers:


126

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

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

该漏洞的播放方式如下:

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

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

此注释线程中进行了一些讨论,暗示它可以“仅”用于此类侵犯隐私的行为。也许吧,但引用Wikipedia的CSRF文章中的部分:

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

强调“新式攻击”。想象一下网络钓鱼攻击对您的用户的影响,然后想象一下,网络钓鱼攻击是通过用户自己的可信任书签到达您的站点的!前面提到的评论主题中链接的论文提供了一些简单的隐私攻击之外的示例。


6
CSRF保护有何帮助?是否有什么阻止攻击者要求自己的CSRF令牌并随其提交的?由于不存在经过身份验证的会话,因此Web服务器没有理由偏爱一个令牌而不是另一个令牌。
A. Wilson

2
“有什么阻止攻击者索要自己的CSRF令牌并随其提交吗?” 是的!这就是CSRF预防逻辑背后的全部假设。浏览器曾经/确实允许表单提交以另一个来源为目标,但是他们从未[有意]允许JS 跨站点读取数据,除非现在是通过选择加入的CORS。除非您将CORS设置错误,否则攻击者可以触发表单提交(可能在cookie中包含现有的CSRF令牌),无法知道令牌以发送所需的第二份副本(例如,在正文/标题中)。因此CSRF代码将被拒绝。
natevw 2014年

7
我认为您的最后一条评论是错误的(您误解了A. Wilson在说什么)。我们说的是,攻击者可以加载http://good.com/login.html一个客户端,解析嵌套的CSRF令牌,然后发布http://bad.com/login.html,其中包含修改后的表单,该表单将提交他的用户名,密码和令牌,无论受害者键入什么内容。CORS不适用,因为您我们有两个单独的客户:攻击者和受害者。因此,我们要重申一个问题:CSRF保护真的适用于登录表单吗?
吉利2014年

8
是的,CSRF将保护登录表单免受跨站点请求伪造的侵害。每次生成正确的CSRF令牌时,其密码都是唯一的。当然,攻击者可以自己获取令牌,但它仍不会匹配受害者在其浏览器中拥有的[可能未设置] cookie,并且攻击者无法在不损害良好域上的页面的情况下设置所述cookie。(不过,您的示例似乎在CSRF和某种奇怪的网络钓鱼攻击之间有些混淆,所以我不确定是否在回答您的实际问题……)
natevw 2014年

3
我可能是错的,但是如果用户不小心执行与购买商品相关的任何操作,那么似乎存在很大的威胁。例如,攻击者诱使用户登录到网站,然后用户继续购买商品,却没有意识到它们在另一个帐户中(例如亚马逊或类似帐户)。现在,攻击者能够访问保存支付信息,可以重定向购买等
you786

14

您的理解是正确的-CSRF的全部目的是攻击者可以事先伪造看起来合法的请求。但是,除非攻击者知道受害者的用户名和密码,否则无法使用登录表单来完成,在这种情况下,存在更有效的攻击方法(自己登录)。

最终,攻击者唯一能做的就是通过向失败的用户发送垃圾邮件来给用户带来不便,而此时安全系统可能会将用户锁定一段时间。


2
哇,超快回复!非常感谢!现在,我可以继续自信地建立我的网站了。
php_learner 2011年

21
登录CSRF仍可用于攻击用户的隐私seclab.stanford.edu/websec/csrf/csrf.pdf
squiddle

6
@squiddle:这是一个非常有趣的论文,感谢您的链接。但这取决于在攻击者的控制下使用帐户登录用户,假定用户不会意识到不正确的事情,假定用户将产生敏感信息,然后将其存储在服务器上。因此,恕我直言,它比“经典” CSRF严重得多。
2012年

6
@Jon是的,它可以不那么严重,但最终它不仅仅可以带来不便,即侵犯隐私。每个服务必须自行定义其威胁模型并进行相应处理。为此,您至少需要了解可能的威胁。这就是为什么我加了2美分。
squiddle

1
请您扩展一下他们的方式:“最终,攻击者唯一能做的就是在安全系统可能锁定用户一段时间后,通过向失败的登录内容发送垃圾邮件来给用户带来不便。”
samthebest 2014年

0

是的,因此其他网站无法模仿您的登录表单!就如此容易。

他们可以做到这一点吗?

  • 第一:您不想允许。
  • 第二:即使是非常简单的失败案例,例如:
    • 由于密码错误,阻止了用户n。的时间,是可以避免的。
    • 可以防止散乱的黑客警报。等等等

这些要点大多数都不正确。攻击者可以创建登录表单,获取用户的凭据以加载登录表单(带有csrf令牌),并将三部分信息发布到目标。CSRF不会阻止这种情况。
Snapey

@Snapey浏览器通常不允许JS读取CSRF数据。使用JS,您无法模仿真正的表单提交请求。
mayankcpdixit

通常将csrf令牌传递给客户端,以供javascript使用。我不是在谈论cors,我只是在要求攻击者登录表单和填充凭据。@mayankcpdxit。您似乎暗示csrf会阻止凭据填充,而事实并非如此。
Snapey

从理论上讲,是的,这是无法避免的。但是,如果您停止在iframe中加载CSRF表单并停止允许跨域请求,则不可能在CSRF之后自动执行凭据填充。
mayankcpdixit

-1

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

感谢@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 users session,
preventing CSRF by forcing the attacker to guess the
sessions token.

如果您尝试登录前进行CSRF验证,那么可能的攻击者就有机会抓取您网站的有效代码!然后,他/她将能够重新发布令牌而无法达到目的。

然后,攻击者可能会尝试猜测您网站的用户名。我所做的,如果IP地址试图猜测说10个用户名没有成功,我只是将其列入黑名单。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.