Skip to content
Advertisement

CSRF protection with CORS Origin header vs. CSRF token

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.example, and evil.example’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.example’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.example’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,
  • …

Advertisement

Answer

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.

Advertisement