使用 CORS 源头与 CSRF 令牌的 CSRF 保护

javascript security cors csrf

2022-08-30 04:18:14

此问题仅涉及防止跨站点请求伪造攻击。

具体内容是：通过 Origin 标头（CORS）进行保护是否与通过 CSRF 令牌进行保护一样好？

例：

Alice 已使用她的浏览器登录（使用 cookie）到。我假设，她使用现代浏览器。https://example.com
Alice 访问，而 evil.example 的客户端代码执行某种请求（经典的 CSRF 场景）。https://evil.examplehttps://example.com

所以：

如果我们不检查Origin标头（服务器端），并且没有CSRF令牌，则我们有一个CSRF安全漏洞。
如果我们检查CSRF令牌，我们是安全的（但这有点乏味）。
如果我们确实检查了 Origin 标头，则来自 evil.example 的客户端代码的请求应该被阻止，就像使用 CSRF 令牌时一样 - 除非 evil.example 的代码有可能以某种方式设置 Origin 标头。

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

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

注意：我不是在谈论

答案 1

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

在一天结束时，您必须“信任”客户端浏览器来安全地存储用户的数据并保护会话的客户端。如果您不信任客户端浏览器，那么您应该停止将Web用于静态内容以外的任何内容。即使使用 CSRF 令牌，您也信任客户端浏览器正确遵守同源策略。

虽然以前存在浏览器漏洞，例如IE 5.5 / 6.0中的漏洞，攻击者可以绕过同源策略并执行攻击，但您通常可以期望这些漏洞在发现后立即进行修补，并且大多数浏览器会自动更新，这种风险将在很大程度上得到缓解。

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

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

注意：我不是在谈论

本机应用程序，

操纵浏览器，

例如，跨站点脚本错误.com的页面，

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

答案 2

Web 内容无法篡改源标头。此外，在同一源策略下，一个源甚至无法将自定义标头发送到其他源。[注1]

因此，检查 Origin 标头与使用 CSRF 令牌一样擅长阻止攻击。

依赖它的主要问题是它是否允许所有合法请求工作。提问者知道这个问题，并设置了这个问题以排除主要情况（没有旧浏览器，只有HTTPS）。

浏览器供应商遵循这些规则，但是插件呢？他们可能不会，但这个问题忽略了“操纵浏览器”。浏览器中让攻击者伪造 Origin 标头的错误怎么办？也可能存在允许CSRF令牌跨来源泄漏的错误，因此需要做更多的工作来论证一个比另一个更好。