【问题标题】:CSRF vulnerability / cookies questionCSRF 漏洞/cookie 问题
【发布时间】:2011-03-07 19:46:48
【问题描述】:

只是想从知道的人那里获得意见。我正在考虑 CSRF 漏洞,以及我所知道的最流行的对抗它的方法。该方法是在返回的 html 中创建一个令牌,并添加一个具有相同值的 cookie。因此,如果脚本尝试发布帖子,他们会have to guess the token thats embedded in the web page 以使其成功。

但是,如果他们针对的是特定网站,为什么他们不能只使用一个脚本

  1. 在页面上调用get(即使脚本无法访问cookie也会返回)
  2. 解析 html 并获取令牌
  3. 调用包含该令牌的帖子(返回的 cookie 将被发回)
  4. 他们在用户不知情的情况下成功提交了表单

脚本不需要知道 cookie 的内容,它只是利用了 cookie 一直来回发送的事实。

我在这里缺少什么?这不可能吗?如果你仔细想想,我觉得这很可怕。

回答问题不需要阅读此行以下内容:)

这个漏洞基于这样一个事实,即身份验证是基于 cookie 完成的,我认为这是当前进行身份验证的主要方式。

我能想到的另一个解决方案是在页面级别进行身份验证。所以 当他们登录时,返回的 html 中将包含该令牌。他们单击的每个链接都包含该令牌,因此当 Web 服务器收到请求时,它可以识别用户/会话。它的问题是,如果他们使用除此之外的任何导航,他们将“未经身份验证”(例如,输入 url),它在 url 中看起来也不好看,因为它可能看起来像这样:

https://www.example.com/SuperSecretPage/1/123j4123jh12pf12g3g4j2h3g4b2k3jh4h5g55j3h3

但我确实明白,如果安全更重要,那么漂亮的 URL 是次要的。

我对 cookie 不是一无所知,但如果用户代理对他们的 cookie 更加小心一点会怎样?

例如,如果发送的 cookie 取决于选项卡怎么办?我们现在都使用标签冲浪,对吧?那么如果 cookie 的范围是选项卡呢?因此,如果我在选项卡 1 上打开我的银行网站并且我在选项卡 2 上冲浪,则任何调用获取/发布的脚本 选项卡 2 只会发送选项卡 2 中累积的 cookie。

或者如果cookies被存储/域。因此,当我在 example.com 上时,任何返回的 cookie 都会进入 example.com cookie 集合。然后当我在 www.mybankingsite.com 上时,所有的 cookie 都会被放入 mybankingsite.com 集合中。因此,如果我访问 example.com 并运行一个调用 get/post 的脚本,用户代理将只发送 example.com cookie。这与发送请求域的 cookie 不同。例如。如果脚本在 example.com 的网页中调用 mybankingsite.com 的获取,则用户代理将不会发送 mybankingsite.com cookie。

我知道我无法控制用户代理的工作,但我只是在探索可能性

【问题讨论】:

    标签: javascript cookies security csrf session-cookies


    【解决方案1】:

    每个会话的 CSRF 令牌必须是唯一的。如果恶意服务器请求相同的页面,他们将获得不同的令牌。如果他们试图通过客户端机器上的 JavaScript 请求页面的内容,同源策略将阻止他们。

    【讨论】:

      【解决方案2】:

      所以我认为这里的问题在于攻击者试图获取页面内容。要获取经过身份验证的用户的页面,攻击者需要能够代表他们发送请求并读取内容。 AJAX 不会发送跨域请求,iframe 不会让您读取响应。我正在努力思考攻击者首先获取内容的其他方式。

      更有可能是使用clickjacking 让用户提交表单。这种技术似乎不太可能。 (警告:这是安全性,我们总是会出错。)

      【讨论】:

        【解决方案3】:

        有没有人愿意分享一些关于这个问题的代码,因为我刚刚用 CSRF 入侵了我自己的网站(未投入生产)。我所要做的就是以下

        在:www.badguy.com/写下面的html

        img src="www.goodguy.com/secure/user/delete/5">

        这是做什么的 所以管理员去 www.badguy.com/ 并且图像请求 www.goodguy.com/secure/user/delete/5 来自用户浏览器,因此管理员在不知不觉中删除了一个用户。如果你创建一个循环,你会遇到麻烦。希望我永远不会删除数据,只是更改其状态:) 但我仍然不喜欢这个外观。

        【讨论】:

        • 你可以通过只接受对该 url 的 post Http 操作来避免这种情况,但它确实打开了一个脚本可以访问它的 DOM 的事实,如果一个元素可以从另一个站点获取信息,那么你可能会受到损害
        猜你喜欢
        • 2017-11-23
        • 2014-09-02
        • 2016-12-09
        • 2017-05-12
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2018-11-24
        • 2011-06-10
        相关资源
        最近更新 更多