Signing Double Submit Cookies, where the value is a pseudo random string and a signature of it. Is this more secure?

Question

I'm not sure if I am describing something that has already been proposed. If not, I would like to coin this "Signed Double Submit Cookies" as a method to improve the Double Submit Cookies technique that attempts to prevent CSRF attacks.

Here is the concept:

1. Before outputting a web page, the server sets a cookie in the header where the value includes two values:

   • token value generated from a strong random number, and

   • signature value which is the signature of the token (or maybe simply a hash of it that has been salted).

2. When the client makes subsequent requests, it reads the cookie and includes the token+signature in the POST or GET requests (along with the cookie being automatically in the request headers).

3. When the server receives the request, it authenticates by:

   • checking if the token+signature included in the POST or GET requests matches the cookie value in the request header, and

   • taking the (cookie/query string) token value and signs it again and compares if the resulting signature matches the (cookie/query string) signature value. If matches, it proves that the cookie has not been blindly written by a subdomain or something else.

For the sake of argument, let's assume that XSS attack preventions have been properly implemented and SSL only is true.

Has this method been used before? Does it properly prevent the attack where a subdomain writes cookies to the parent domain?

[EDIT: Originally I had the token and signature in two separate cookies, but to simplify as suggested by @SteffenUllrich, I have edited the question to reflect both the token and signature in one cookie.]

Answer 1

I don't believe this would provide any more protection then the normal double submit cookies.

If an attacker can overwrite one cookie using an unsecured (https) subdomain, they could just as easily overwrite 2 cookies.

The attacker in the senario would get a legitimate token and signed token value, they would embed both of those in the request, and write those two cookies to the browsers cache using the subdomain vulnerability.

Answer 2

The problem with naive double submit is that if the attacker could insert an attacker controlled cookie he could also set the CSRF token to this cookie and this way defeat the CSRF protection - because token and cookie match.

This can be defeated if the attacker is not able to create a CSRF token and guess the matching verification cookie. This can be achieved by having some server side secret which is used in creating the verification cookie from the CSRF token, i.e. some signature using a server side private key, a hash of secret+token or similar. In this case it does not matter if the signature is a separate cookie, is included in the verification cookie or if you only use the signature as the verification cookie.

Thus in this case I think your solution might help against the problems with native double submit but is unnecessary complex: you don't need two cookies but you could simply use the signature as the verification cookie. For verification just try to sign the CSRF token and if it matches the signature everything is fine. And the attacker is not able to create a token and a matching signature because he does not know the server side secret needed for the signature.
EDIT: Note that the signature should also include information regarding the current user, e.g. the session id. Otherwise it would be possible for some other user to obtain a valid token+signature pair and reuse it.

Note that none of this helps if the attacker gets access to both the CSRF token and the verification cookie because in this case this could be used for reusing this pair. But this is not the attack scenario double submit cares about, i.e. it assumes that reading the cookie is protected by using httpOnly cookies and a protected connection (https) and no way for XSS either.