3

It is enough presently to check Referer or X-Requested-With HTTP headers to protect against CSRF ?

Reda LM
  • 367
  • 3
  • 11

2 Answers2

3

All CSRF protections that only relies on putting a predictable value in a HTTP header has the same basic problems:

  • If you enable CORS with Access-Control-Allow-Headers, you may suddenly be allowing the X-Requested-With header to be set cross origin. Off course, you can solve this by just not setting a bad CORS policy. (The Referer header is "forbidden", and can't be set no matter your CORS policy.)

  • There have been Flash exploits (and if history is any guide, there will be more) that allows headers to be set in cross origin requests. Sure, Flash is dying, but it's not dead yet.

  • The Referer header might be blank for loads of legitimate reasons (e.g. stripped away by a proxy). To make this check secure you would have to block requests with a blank header, but that would on the same time block many legitimate requests.

So I'm afraid you still need to rely on setting a header (or some other variable) to a value that an attacker can not predict. In practice, this leaves you with a couple of options, such as a classical token, double submit cookie, or using a bearer token in the auth header.

As always, reading OWASP gives a lot of guidance.

Anders
  • 65,052
  • 24
  • 180
  • 218
  • So if CORS is not used, and I checked the `Referer` header properly (using white-list), am I protected against CSRF ? As far as I know the Flash trick can forge only the `Content-Type` header. – Reda LM Mar 27 '18 at 08:55
  • @Jessie There is not only one Flash trick. There are many. Some known, some unknown. But yes, if (a) no Flash bugs, and (b) you block empty referers, then you are protected. Problem here is that (a) is not necesarily true, and (b) means that you block many legit requests. – Anders Mar 27 '18 at 09:11
  • Sorry for this silly question but how did you know that there is some unkown Flash tricks ? – Reda LM Mar 27 '18 at 09:33
  • @Jessie I dont have access to any secret info. All Im saying is that there are more known flash vulnerabilities than the one I linked to, and given their poor track record I would not be surprised if there pops up new ones. – Anders Mar 27 '18 at 10:17
2

OWASP has recommendations on this topic. In short, you should have two-pronged checks:

  1. Ensure that the source origin is same as target origin. Use either the 'Origin' or the 'Referer' header, in that order of preference. And if neither is present, reject.
  2. Make use of CSRF token

BTW, you might also want to check out Same site cookie as a means of protecting against CSRF.

Anders
  • 65,052
  • 24
  • 180
  • 218
Sunil Agrawal
  • 147
  • 3