18

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?

15

Simply put

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.

  • On the other hand, for an existing application, the CSRF token way is backward-incompatible: all the clients would have to be updated, or they will instantly break the moment the server starts blocking the requests without token. It might be a stopper for certain scenarios (or, one could do a gradual roll-out: first implement the token exchange between the server and clients, but not enforce token validation on server only after high enough percentage of clients have been updated). By clients, I mean clients of the API; for instance, hybrid mobile apps. – jakub.g Sep 28 '15 at 7:32
  • Does it make sense, when it comes to web security, to consider that "browser can be old"? Non-last-version of browsers should be discarded from security plans. In other words, if we don't consider "old browser" as an issue (it's user/client's responsibility), then is there a reason to not use HTTP: Origin as anti-CSRF mechanism? – Xenos Sep 26 '18 at 8:14
  • @Xenos That is a good point. However, at the time of writing there exists bugs in current implementation of the origin header in that e.g. Firefox does not send this header with POST requests. My answer updated. – SilverlightFox Oct 26 '18 at 11:48
  • @SilverlightFox It's still irrelevant IMO since the bug is actually fixed, and even if it's not, then it's a browser bug, so you must fix it in the browser, not in every single web application. – Xenos Oct 26 '18 at 13:30
  • @Xenos I don't think it is irrelevant because this makes it impossible to have an application that is secure against CSRF, even at this moment in time. Why wait for some future bug fix in a browser when you can secure your application now? For now use tokens until this is fixed. – SilverlightFox Oct 26 '18 at 15:15
3

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.

  • 3
    Note that some browsers don't send the Origin header for same origin requests. This will make the logic cumbersome and you won't have any protection against CSRF for pre-CORS browsers. Also, __EVENTVALIDATION is not a CSRF prevention measure - it is a way of validating page state before triggering an event. __VIEWSTATE could be considered CSRF prevention, but only if it is encrypted with a session specific value (e.g. the actual Session ID). – SilverlightFox Jun 9 '15 at 12:38
  • @SilverlightFox - Thanks... wasn't aware of that issue with same origin requests. Sounds like that makes the Origin checking approach pretty much invalid - perhaps you should post your own answer to the question to expand on that. BTW, you may be right about VIEWSTATE/EVENTVALIDATION, but that's going a bit on a tangent; I've edited my answer to speak about .Net more generally. – paj28 Jun 9 '15 at 13:10
0

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.

  • Any XSS flaw on the external domain would allow the synchronizer token pattern to work too (and most other mechanisms except for CSRF protection via reauthentication). XSS almost always trumps CSRF - you've already lost if there's an XSS flaw (usually). – SilverlightFox Jun 9 '15 at 11:26
  • @SilverlightFox Are you saying, any XSS flaw on the ext. domain would allow forging the token? – Aatif Shahdad Jun 9 '15 at 11:43
  • 1
    Well, yes. If you are allowing another domain to POST to yours, you must allow them access via some means, although likely via Access-Control-Allow-Origin so that the domain can read the CSRF token. If an attacker has control of the external domain they can modify any forms or AJAX scripts to POST data of the attacker's choosing whichever way they work. – SilverlightFox Jun 9 '15 at 12:07
  • @SilverlightFox I got your point, edited. Thank you again. – Aatif Shahdad Jun 9 '15 at 12:07
  • Ha - sorry. I know that I picked a hole in another post you made yesterday. ;) – SilverlightFox Jun 9 '15 at 12:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.