使用CORS Origin标头与CSRF标记的CSRF保护 [英] CSRF protection with CORS Origin header vs. CSRF token
问题描述
这个问题是关于仅针对跨站点请求伪造攻击的保护。
具体关于：通过Origin标头（CORS）通过CSRF令牌？
示例：
- Alice已登录一个cookie）与她的浏览器 https://example.com 。我假设她使用的是现代浏览器。
- Alice访问 https://evil.com ，而evil.com的客户端代码会对 https://example.com （传统CSRF场景）执行某种请求。
所以：
- 如果我们检查一个CSRF令牌，我们是安全的（但它有点乏味）
- 如果我们检查Origin头，来自evil.com的客户端代码的请求应该像使用CSRF令牌时一样被阻止 - 除非可能
我知道，这不应该是XHR可能的（见例如< a href =http://stackoverflow.com/questions/13242049/security-for-cross-origin-resource-sharing>跨源资源共享安全性），至少没有，如果我们信任W3C规范在所有现代浏览器中正确实现（我们可以吗？）
但是其他类型的请求 - 例如表单提交？加载脚本/ img / ...标签？或者页面可以用来（合法地）创建请求的任何其他方式？
注意：我不是在说
- >原生应用程序
- 操纵浏览器，
- example.com网页中的跨网站脚本错误，
- ...
如果我们相信W3C规范在所有现代浏览器中正确实现，我们可以使用XHR（例如跨源资源共享的安全性），至少没有。
在一天结束时，你必须信任客户端浏览器安全地存储用户的数据和保护会话的客户端。如果您不信任客户端浏览器，则应停止使用静态内容以外的任何内容。即使使用CSRF令牌，您仍然信任客户端浏览器正确遵守同源政策。
虽然之前存在浏览器漏洞，例如 IE 5.5 / 6.0 <攻击者可能绕过同源策略并执行攻击，通常可以预期这些攻击会在发现后立即修补，并且大多数浏览器会自动更新，这种风险将大大减轻。
但是其他类型的请求 - 例如表单提交？加载脚本/ img / ...标签？或者页面可以用来（合法地）创建请求的任何其他方式？或者可能有一些已知的JS hack？
Origin 用于XHR跨域请求。图片请求不包含标头。
注意：我不在说
原生应用程式，
操控浏览器
example.com网页中的跨网站指令码错误
不确定是否属于受操纵的浏览器，但旧版本的Flash 允许设置任意头，这将使攻击者能够发送带有受害者机器中的欺骗性 referer 头的请求，以便执行攻击。 / p>
This question is about protecting against Cross Site Request Forgery attacks only.
It is specifically about: Is protection via the Origin header (CORS) as good as the protection via a CSRF token?
Example:
- Alice is logged in (using a cookie) with her browser to "https://example.com". I assume, that she uses a modern browser.
- Alice visits "https://evil.com", and evil.com's client side code performs some kind of request to "https://example.com" (classic CSRF scenario).
So:
- If we don't check the Origin header (server-side), and no CSRF token, we have a CSRF security hole.
- If we check a CSRF token, we're safe (but it's a bit tedious).
- If we do check the Origin header, the request from 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's code to set the Origin header.
I 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?)
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?
Note: I am not talking about
- native applications,
- manipulated browsers,
- cross site scripting bugs in example.com's page,
- ...
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?)
At the end of the day you have to "trust" the client browser to safely store user's data and protect the client-side of the session. If you don't trust the client browser, then you should stop using the web at all for anything other than static content. Even with using CSRF tokens, you are trusting the client browser to correctly obey the Same Origin Policy.
While there have been previous browser vulnerabilities such as those in IE 5.5/6.0 where it has been possible for attackers to bypass the Same Origin Policy and execute attacks, you can typically expect these to be patched as soon as discovered and with most browsers automatically updating, this risk will be mostly mitigated.
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?
The Origin header is normally only sent for XHR cross-domain requests. Image requests do not contain the header.
Note: I am not talking about
native applications,
manipulated browsers,
cross site scripting bugs in example.com's page,
I'm not sure whether this falls under manipulated browsers or not, but old versions of Flash allowed arbitrary headers to be set which would enable an attacker to send a request with a spoofed referer header from the victim's machine in order to execute an attack.
这篇关于使用CORS Origin标头与CSRF标记的CSRF保护的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
