javascript - 使用 CORS Origin header 与 CSRF token 的 CSRF 保护

Question

此问题仅与防止跨站点请求伪造攻击有关。

它具体是关于:通过 Origin header (CORS) 进行的保护是否与通过 CSRF token 进行的保护一样好？

例子:

• Alice 使用她的浏览器登录(使用 cookie)到 https://example.com。我假设她使用的是现代浏览器。
• Alice 访问 https://evil.example，evil.example 的客户端代码向 https://example.com 执行某种请求(经典的 CSRF情景)。

所以:

• 如果我们不检查 Origin header (服务器端)并且没有 CSRF token ，那么我们就有了 CSRF 安全漏洞。
• 如果我们检查 CSRF token ，我们是安全的(但有点乏味)。
• 如果我们确实检查了 Origin header ，来自 evil.example 客户端代码的请求应该被阻止，就像使用 CSRF token 时一样 - 除非，如果 evil.example 的代码可能以某种方式设置原始 header 。

我知道，如果我们相信 W3C 规范在所有现代浏览器中都能正确实现(我们可以吗？)，这在 XHR 中是不可能的(参见例如 Security for cross-origin resource sharing )

但是其他类型的请求呢？表单提交？加载脚本/img/...标签？或者页面可以用来(合法)创建请求的任何其他方式？或者可能是一些已知的 JS hack？

注意:我不是在说

• native 应用程序，
• 操纵浏览器，
• example.com 页面中的跨站点脚本错误，
• ...

Answer 1

know, that this should not be possible with XHR (see e.g. Security for cross-origin resource sharing), at least not, if we trust the W3C spec to be implemented correctly in all modern browsers (can we?)

归根结底，您必须“信任”客户端浏览器来安全地存储用户数据并保护 session 的客户端。如果您不信任客户端浏览器，那么除了静态内容之外，您应该完全停止使用网络。即使使用 CSRF token ，您也相信客户端浏览器会正确遵守 Same Origin Policy .

虽然以前存在浏览器漏洞，例如 IE 5.5/6.0 中的漏洞在攻击者有可能绕过同源策略并执行攻击的地方，您通常可以预期这些会在发现后立即修补，并且大多数浏览器会自动更新，这种风险将大大降低。

But what about other kinds of requests - e.g. form submit? Loading a script/img/... tag? Or any other way a page can use to (legally) create a request? Or maybe some known JS hack?

Origin header 通常只针对 XHR 跨域请求发送。图片请求不包含 header 。

Note: I am not talking about

• native applications,

• manipulated browsers,

• cross site scripting bugs in example.com's page,

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