CSRF Double Submit Cookie is basically "not Secure"

Question

From OWASP page : A CSRF attack works because browser requests automatically include all cookies including session cookies.

To prevent it, we can use double-submit cookie hash.
In some sample codes I found, basically this algorithm is found.

Victim access app:

1. Backend : generate login cookie AND hash string related to login cookie
2. Frontend : store the hash string into second cookie (say : CSRF-token cookie)
3. Frontend (secured) : send request with login cookie and CSRF HTTP header, where the header value is extracted from CSRF-token cookie.

Attacker :

1. Use some kind of social media engineering to make users click malicious link, where this malicious link use session cookie.
2. The attacker then steal this session cookie to logged in as victim

Double submit cookie should prevent this attack since attacker also need to provide valid CSRF token in the HTTP header.

I still don't get this: If browser requests automatically include all cookies, that means on clicking malicious link, both login cookie AND CSRF-token cookie will also included, and attacker steal both of them.
So the attacker is just need to extract value from CSRF-token cookie, and create his own API access, using login cookie that he steal, and CSRF HTTP header with extracted value?

Am I missing something?

Thanks

Answer 1

A few things appear to be mixed up here.

So in the original synchronizer token pattern, you would generate a random token, store it server-side for the user session, and also send that to the client. The client would then send the token back as a form value or request header, but not as a cookie, so it doesn't get sent automatically - that's the whole point. (And the server would of course compare the token from the request to the one in the session.)

In double posting, the token doesn't even need to be generated server-side, the client can also do it (or the server can send it, doesn't matter that much if we accept that crypto is good enough in Javascript).

The token will be sent as a cookie, and also as something else (form value, request header, anything not sent automatically). If the server sent it as a cookie (obviously without httpOnly), the client can read it from that and include as a non-cookie too in a request. The server will again just compare the two.

The point is that an attacker on attacker.com will not be able to access the cookie (neither read nor write) for the application domain. So if the client can read the cookie and include it as something else in the request, that client must be running on the application origin (if we are talking about unmodified browsers only), so no CSRF is being performed. The client can also create the whole token itself, because attacker.com will still not be able to create a cookie for the application domain.

So based on the above, if everything is just in cookies, the implementation is wrong, and does not protect against CSRF.

Answer 2

CSRF protection with double submit cookie is not secure. Therefore, in the OWASP documentation, the double submit cookie is classified as one of defense in depth.

The reason is that cookies can be set by a third party with MITM attack.

HTTPS requests and responses cannot be eavesdropped or modified. However, MITM attack can modify the HTTP response(plain text). An attacker could direct the victim to http://example.com/ (Target site) to send a plaintext http request. Then, in response, the attacker can use MITM to return a Set-Cookie header.

HTTP / 1.1 200 OK
Set-Cookie: CSRFTOKEN=XXXXXXXXXXXXXXXXXXXXXXX;

This CSRFTOKEN is set in the victim's browser. Next, the attacker sets up a CSRF trap page below.

<form action="https://example.com/target" method="POST">
<input type="hidden" name="mail" value="[email protected]">
<input type="hidden" name="token" value="XXXXXXXXXXXXXXXXXXXXXXX">
<input type="submit">
</form>

The destination of the above form is a https page, but the cookie set by http response is also valid on https requests. So the cookie and hidden parameter will be sent the same value, bypassing CSRF protection.