首页 文章

使用CORS Origin头与CSRF令牌进行CSRF保护

提问于
浏览 次
82

此问题仅针对防止跨站点请求伪造攻击 .

具体来说：通过Origin头（CORS）保护和通过CSRF令牌保护一样好吗？

例：

所以：

  • 如果我们不检查Origin标头（服务器端），没有CSRF令牌，我们就有一个CSRF安全漏洞 .

  • 如果我们检查一个CSRF令牌，我们're safe (but it'有点单调乏味） .

  • 如果我们检查Origin标头，则来自evil.com 's client side code should be blocked just as well as it would when using a CSRF token - except, if it is possible somehow for evil.com'代码的请求设置Origin标头 .

我知道，如果我们相信W3C规范在所有现代浏览器中都能正确实现，那么XHR（参见例如Security for cross-origin resource sharing）至少不能实现这一点（我们可以吗？）

但是其他类型的请求呢 - 例如表格提交？加载脚本/ img / ...标签？或者页面可以用来（合法地）创建请求的任何其他方式？或者也许是一些已知的JS黑客攻击？

注意：我不是在谈论

  • 本机应用程序，

  • 操纵浏览器，
    在example.com的页面中

  • 跨站点脚本错误，

  • ......

javascript security cors csrf

2 回答

  • 25

    知道，如果我们相信W3C规范在所有现代浏览器中都能正确实现，那么XHR就不可能实现这一点（参见例如跨源资源共享的安全性），至少不是这样（我们可以吗？）

    在一天结束时，您必须"trust"客户端浏览器安全地存储用户's data and protect the client-side of the session. If you don't信任客户端浏览器，然后您应该停止使用网络除静态内容之外的任何其他内容 . 即使使用CSRF令牌，您也相信客户端浏览器能够正确遵守Same Origin Policy .

    虽然之前存在浏览器漏洞，例如IE 5.5/6.0中攻击者可能绕过同源策略并执行攻击的漏洞，但您通常可以预期这些漏洞会在发现并且大多数浏览器自动更新时被修补，这种风险将大部分减轻 .

    但是其他类型的请求呢 - 例如表格提交？加载脚本/ img / ...标签？或者页面可以用来（合法地）创建请求的任何其他方式？或者也许是一些已知的JS黑客攻击？

    Origin 标头通常仅针对XHR跨域请求发送 . 图像请求不包含标头 .

    注意：我不是在谈论本机应用程序，操纵浏览器，example.com页面中的跨站点脚本错误，

    我不确定这是否属于被操纵的浏览器，但old versions of Flash允许设置任意标头，这将使攻击者能够从受害者的机器发送带有欺骗性 referer 标头的请求以执行攻击 .

    回复于
  • 35

    Web内容甚至可以将自定义标头发送到其他来源 . [1]

    因此，检查Origin头与阻止攻击一样好，就像使用CSRF令牌一样 .

    依赖于此的主要问题是它是否允许所有合法请求工作 . 提问者知道这个问题，并设置了排除主要案例的问题（没有旧浏览器，仅限HTTPS） .

    浏览器供应商遵循这些规则，但插件呢？他们可能没有，但问题无视“被操纵的浏览器” . 如果浏览器中的bug会让攻击者伪造Origin头？可能存在允许CSRF令牌在源头之间泄漏的错误，因此需要更多的工作来争辩一个优于另一个 .

    回复于

相关问题