【问题标题】:CSRF token protection using cookie使用 cookie 的 CSRF 令牌保护
【发布时间】:2013-07-20 17:33:42
【问题描述】:

将 csrf 令牌保存在 cookie 中是一种好习惯,还是在表单中使用隐藏字段更好?像验证码所做的那样,每次用户请求都重新生成 csrf 令牌是否很好?

谢谢

【问题讨论】:

  • 我不是所有细节方面的专家,但对我来说,将其保存在 cookie 中似乎会适得其反。如果用户最近访问过该站点,则他有正确的 cookie 以绕过检查。如果你把它放在表单中,你就会知道那个表单和其他任何东西都不会生成 cookie。
  • 如何在查询字符串中添加 csrf 令牌而不是隐藏字段,您认为使用 cookie 更好吗?谢谢

标签: csrf csrf-protection


【解决方案1】:

最好将其包含在表单中。 CSRF 令牌背后的想法是它不是被动传递的(例如,如果恶意用户能够诱骗浏览器访问一些做坏事的 URL)。 Cookie 是被动传递的。

【讨论】:

    【解决方案2】:

    可以在 OWASP 网站OWASP CSRF Prevention Cheat Sheet 页面上找到对此问题的最佳解释。

    首先,使用 cookie 作为 CSRF 令牌并没有多大帮助,因为所有 cookie,甚至是秘密的,都会随每个请求一起提交。无论最终用户是否被诱骗提交请求,都将提交所有身份验证令牌。

    其次,应用程序可以在表单中包含隐藏的输入参数,具有通用名称,例如“CSRFToken”。这个令牌的值必须是随机生成的,这样攻击者就无法猜到。

    此外,Challenge-Response 是 CSRF 的另一个防御选项。可以通过以下方式实现:

    1. 验证码
    2. 重新认证(密码)
    3. 一次性令牌

    【讨论】:

      【解决方案3】:

      CSRF cookie 肯定容易受到攻击,但实现安全,因为会话值将始终与存储在请求正文或请求头中的提交令牌值进行检查,因此我看不出反对的理由。 OWASP 网站上概述的双重提交(http only cookie vs post data)或令牌同步器(session vs post data)模式都是很好的做法,并且都使用 cookie。

      前面提到的双重提交将存储移动到客户端,因此被认为是无状态的,但无论哪种方式,两个令牌进行比较,攻击者始终不知道其中一个令牌。

      【讨论】:

        猜你喜欢
        • 2015-08-17
        • 1970-01-01
        • 2014-09-01
        • 2014-01-23
        • 2016-05-19
        • 2017-03-19
        • 2011-09-07
        • 2014-06-24
        • 2012-07-21
        相关资源
        最近更新 更多