这个问题仅涉及防止跨站点请求伪造攻击。
它具体涉及：通过 Origin 标头 (CORS) 提供的保护是否与通过 CSRF 令牌提供的保护一样好？
Example:
- Alice 使用她的浏览器登录（使用 cookie）
https://example.com。我假设她使用现代浏览器。
- 爱丽丝来访
https://evil.example，evil.example 的客户端代码执行某种请求https://example.com（经典的 CSRF 场景）。
So:
- 如果我们不检查 Origin 标头（服务器端），并且没有 CSRF 令牌，则会出现 CSRF 安全漏洞。
- 如果我们检查 CSRF 令牌，我们就安全了（但这有点乏味）。
- 如果我们确实检查 Origin 标头，则来自邪恶.example 的客户端代码的请求应该像使用 CSRF 令牌时一样被阻止 - 除非邪恶.example 的代码可以以某种方式设置 Origin 标头。
我知道，这对于 XHR 来说是不可能的（参见例如跨域资源共享的安全性 https://stackoverflow.com/questions/13242049/security-for-cross-origin-resource-sharing），至少不会，如果我们相信 W3C 规范能够在所有现代浏览器中正确实现（我们可以吗？）
但是其他类型的请求呢？表单提交？正在加载 script/img/... 标签？或者页面可以使用任何其他方式（合法）创建请求？或者也许是一些已知的 JS hack？
注意：我不是在谈论
- 本机应用程序，
- 被操纵的浏览器，
- example.com 页面中的跨站点脚本错误，
- ...
知道，这对于 XHR 来说是不可能的（例如，参见跨域资源共享的安全性），至少不可能，如果我们相信 W3C 规范能够在所有现代浏览器中正确实现（我们可以吗？）
归根结底，您必须“信任”客户端浏览器来安全地存储用户数据并保护会话的客户端。如果您不信任客户端浏览器，那么您应该停止使用网络来获取静态内容以外的任何内容。即使使用 CSRF 令牌，您也相信客户端浏览器能够正确遵守同源政策 https://www.w3.org/Security/wiki/Same_Origin_Policy.
虽然以前存在浏览器漏洞，例如浏览器5.5/6.0 http://www.securityfocus.com/bid/3721/discuss如果攻击者有可能绕过同源策略并执行攻击，您通常可以预期一旦发现这些问题就会立即修补，并且随着大多数浏览器自动更新，这种风险将大大减轻。
但是其他类型的请求呢？表单提交？正在加载 script/img/... 标签？或者页面可以使用任何其他方式（合法）创建请求？或者也许是一些已知的 JS hack？
The Originheader 通常只针对 XHR 跨域请求发送。图像请求不包含标头。
注意：我不是在谈论
-
本机应用程序，
-
被操纵的浏览器，
-
example.com 页面中的跨站点脚本错误，
我不确定这是否属于受操纵的浏览器，但是旧版本的 Flash http://ha.ckers.org/blog/20060725/forging-http-request-headers-with-flash/允许设置任意标头，这将使攻击者能够发送带有欺骗性的请求referer来自受害者机器的标头以执行攻击。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
