2

I did just learn about the details of CSRF-prevention. In our application, all "writing" requests are done using XHR. Not a single form is actually submitted in the whole page, everything is done via XHR.

For this scenario, Wikipedia suggests Cookie-to-Header Token. There, some random value is stored in a cookie during login (or at some other point in time). When making an XHR-request, this value is then copied to a custom http-header (e.g. "X-csrf-token="), which is then checked by the server.

Now I am wondering, if the random value is actually necessary at all in this scenario. I think it should be enough to just set a custom header like "X-anti-csrf=true". Seems a lot more stable than dragging a random value around. But does this open any security issues?

Andreas
  • 1,997
  • 21
  • 35
  • But then the attacker could connect to your website to obtain the not-random header and reuse it on malicious requests. – Touffy Mar 25 '15 at 08:38

1 Answers1

1

It depends on how many risky assumptions you want to make.

  1. you have properly configured your CORS headers,
  2. and the user's browser respects them,
  3. so there is no way a malicious site can send an XHR to your domain,
  4. which is the only way to send custom headers with a request

If you believe in all that, sure, a fixed custom header will work. If you remove any of the assumptions, then your method fails.

If you make the header impossible to guess, then you don't need to make those assumptions. You're still relying on the assumption that the value of that header can't be intercepted and duplicated by a third party (there's TLS for that).

Touffy
  • 6,309
  • 22
  • 28
  • 1
    Thank you. These are enough reasons to drag this token around inside the application. – Andreas Mar 25 '15 at 13:06
  • 1
    @Andreas: Yes you have to trust the client to uphold their half of the security bargain. [Setting custom headers is a valid way to protect against CSRF](http://stackoverflow.com/a/22533680/413180). – SilverlightFox Mar 26 '15 at 11:15