Use header instead of cookie for CSRF double submit cookies?

Question

Double submit cookies are vulnerable to cookie injection from the same domain. What if I use a custom header instead of a cookie?

Example HTTP request:

header X-CSRF-PROTECTION = 5a445s66gg54s45a54
POST   X-CSRF-PROTECTION = 5a445s66gg54s45a54, param1=aaa....

Isn't that safer?

Edit: ok, I was confused, thanks to Anders now I have a more clear idea.

I'd like to avoid to put an hidden form fields, but I want provide a decent protection.

• I always use json ajax based interaction

• I always check that content-type is 'application/json"

So, what I proposed before doesn't add security.

I could:

• store at login time a random token in SESSION and as COOKIE

• every ajax request, should read the cookie and set it as request header

• the server can compare the header with session value

What do you think about?

Answer 1

The reason to use double submit (instead of a synchronizer token) is that you do not want to have to do a lookup on the server for every request. So as long as the value of the cookie matches that of the request parameter the request will be passed through.

That works because evil.com can neither read cookies from example.com (and thereby send a matching request parameter), nor set them (and thereby set both to some arbitrary constant).

You are correct to point out that this fails for subdomains. It is possible for evil.example.com to set a coockie that will be used for example.com, and thereby bypassing the test. So if you do not trust your subdomains, do not use this solution for CSRF protrection!

Now, does your proposal solve the problem? No. It actually makes it worse. Since you do not need to read or modify any cookie value anymore, it comes down to being able to modify request headers. So this is the same as just relying on a single header with a constant value, e.g. the commonly used:

X-Requested-With: XMLHttpRequest

You have two problems here:

1. You are still vulnerable to an attack from evil.example.com since a subdomain can modify request parameters to its parents by using document.domain.
2. You might also be vulnerable to attacks from evil.com since there have been multiple Flash exploits allowing you to set headers for cross domain requests.

Answer 2

It's not clear what you are trying to accomplish, so it is difficult to provide specific information, but some basic guidelines about preventing CSRF atacks can be found on OWasp's CSRF Prevention Cheat Sheet. Hopefully, that will help steer you down an effective path toward your security goals.