具有CORS Origin标头和CSRF令牌的CSRF保护

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

具体来说，它是：通过Origin标头（CORS）进行的保护是否与通过CSRF令牌进行的保护一样好？

例：

• 爱丽丝使用她的浏览器（使用cookie）登录到“ https://example.com ”。我认为她使用的是现代浏览器。
• 爱丽丝访问“ https://evil.com ”，evil.com的客户端代码对“ https://example.com ” 执行某种请求（经典CSRF场景）。

所以：

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

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

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

注意：我不是在说

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

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

最终，您必须“信任”客户端浏览器，以安全地存储用户数据并保护会话的客户端。如果您不信任客户端浏览器，那么除了静态内容外，您应该完全停止使用网络。即使使用CSRF令牌，您也可以信任客户端浏览器以正确遵守Same Origin Policy。

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

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

的Origin报头通常只用于发送XHR跨域请求。图片请求不包含标题。

注意：我不是在说

• 本机应用程序

• 操纵的浏览器

• example.com页面上的跨站点脚本错误，

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

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

因此，检查Origin报头在阻止攻击方面与使用CSRF令牌一样好。

依赖于此的主要问题是它是否允许所有合法请求正常工作。询问者知道此问题，并已设置问题以排除主要情况（没有旧的浏览器，仅HTTPS）。

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