Why is the synchronizer token pattern preferred over the origin header check to prevent CSRF

Question

I am well aware of the concept of CSRF, and I think I am also aware of the possible protection possibilities, as described by OWASP. However, I'm not sure why the synchronizer pattern seems to be preferred, if we could just as easily check the origin header of the request. The latter could be done server-wide, which would make it much easier to implement than the synchronizer token pattern. The only downside to me is that no POSTs from a different domain could be made then, but even then we could foresee some white-list filter.

What are other reasons to prefer the synchronizer token pattern over the origin header check?

Answer 1

Simply put

• The Origin header is not sent for same-origin requests by all browsers.
• Current bugs in popular browsers mean that the Origin header is not sent for POST requests, which makes this approach less-than-useless since state changing requests should always use POST above GET.

This would make for complex logic when implementing CSRF protection.

That is:

Lack of Origin header = Old browser/bug OR
Lack of Origin header = Same Origin
Origin header matches domain = Same Origin
Origin header does not match = CSRF attack

As you can see, it is not possible to distinguish between old or buggy browsers possibly making CSRF attacks and legitimate current browser requests. You could add browser detection, but then the logic gets more messy. Complexity tends to reduce security.

This of course, could be patched in a browser update. However, then your application would be incompatible with older versions of the browser.

Much simpler would be to generate a token and send that with each request outside of the cookie mechanism.

Answer 2

It's mostly due to history. People have been aware of CSRF since the early 2000's, before the Origin header had been invented. The concept of "token in a hidden field" provided sites an immediate way to fix the flaw, without waiting for browsers to update. While the mechanism is a little messy, it turns out it is possible for frameworks to provide this functionality automatically, with little input from application developers. Notably, .Net included this from the start with EVENTVALIDATION/VIEWSTATE, and it is relatively rare for .Net applications to have CSRF flaws.

When CSRF was first taken seriously, some people proposed checking the Referer header to fix the flaw. It is widely known that the Referer header is easy to spoof, but this idea is not as silly as it seems. When an attacker makes a direct connection to a web server, it is easy to spoof the Referer header. However, in a CSRF attack, the attacker is not making a direct connection; the victim's web browser is making the connection, and the attacker cannot readily control the Referer header. However, this approach turns out still to be flawed. Older versions of Flash allowed an attacker free control of the Referer header in a CSRF attack scenario. Also, some users disable the Referer header for privacy reasons, which a web site would mistake for a CSRF attack.

The Origin header has been developed as a more secure replacement for the Referer header. In many ways, it is a much neater solution to CSRF, and it avoids the overhead of managing the tokens. Some applications - particularly single page applications - use the Origin header as the only CSRF protection and are completely secure. However, this is the exception rather than the rule. The synchroniser pattern is well understood, widely supported by frameworks, and has no known weaknesses.

Edit - Silverlightfox informs me that the following is not true. See his answer for more info.

Ultimately I think OWASP are being a little backward in their advice. In 2015 they should be advising Origin header checks as the primary control, with the synchroniser pattern as a legacy alternative.

Answer 3

Any browser flaw for example where it allows Origin header being set client-side(highly unlikely with modern day browsers) will now enable CSRF attacks against your application.

Additionally, from https://security.stackexchange.com/a/74526/66075

You can't currently depend on the Origin header, because it is not implemented in all browsers which are in active use. Apart from that, Origin is not sent in all cases relevant to CSRF.

Also, from SilverlightFox's answer to a similar question at https://stackoverflow.com/a/24692474/4399898,

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.

and

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.