Is ensuring that a random string in a cookie and a header are the same enough to protect against XSRF?

Question

In a cookie-to-header scheme of sending the xsrf/csrf tokens, the server sets a cryptographically secure pseudo-random number as a cookie in the client's machine. The java script code on the client machine is expected to read this code from the cookie thus ensuring vis-a-vis the same origin policy of the browser that the script is from the same page as the token. The script then takes the token and adds it to the http request header by the name xsrf-token or something like that.

Meanwhile the server is supposed to keep a persistent record of the issued xsrf token. When the request arrives, it takes the token from the header, matches it against the one on record, if it's matches, we're in!

Now here's where my confusion starts. Since we are storing the information in the cookie it will inevitably be send with each request to the server when the http request is made. So, on the server end we have not only one but two copies of the same information. Why can't we just match one with the other and accept the validity of the request? Isn't this whole exercise worthwhile only because we trust the browser to perform its cross origin checks. Do we not trust cookies? To my naive self at least this seems like something that could work. I could be egregiously wrong of course, and I'd rely on you to call me out in case I am missing out on some basic.

I am assuming I am missing something. So here's the scheme I am currently implementing for my site. I am using JWT tokens to establish and secure user identity in an httponly cookie. What I am proposing is, I issue a separate JWT token (containing only a pseudo random number) signed by a completely different key and store it in a session cookie. The client side code reads it, sends it in the header. The server reads the cookie and header field and sees that they are the same. Then the server authenticates the JWT token and sees that it was indeed signed by the key in the server.

My question to you is, can this work? By this I don't mean only the one involving the JWT tokens. I also mean the one without any sort of check to verify that the server was the issuer i.e. the one with only a pseudo-random number and only single check to match with the cookie. Any constructive suggestion is welcome, including informing me on how I am being an outright idiot. What are some vulnerabilities that are in this scheme? Is there potential to further investigate this? Is this a sufficiently good scheme to protect against CSRF?

Answer 1

Yes, the system you describe - just comparing a cookie value with a header value - is a fully functional CSRF defence. In fact, it even has a name: double submit cookie. It's a great way to do anti-CSRF when you don't want to keep server state. Note that you don't need a JWT for this. Any cryptographically secure random number will do.

So why not always do this? Why ever bother with saving a random token in a session, when you can just have the client do all the heavy lifting? Perhaps double submit cookies are somewhat more prone to implementation errors (e.g. what happends if both are empty, loose typing issues, etc.). But I think the main reasone is that the ordinary token is just simpler to understand. The server keeps a secret that the attacker does not know. The workings of the double submit is conceptually more difficult to understand.