How does Double Submit Cookie Pattern Prevent against CSRF attacks?

Question

I tried the Double Submit Cookie Pattern but I still managed to forge the request by opening the legitimate transaction website in example which has the csurf set cookie and by copying the value of the _csurf HTML tag and embedding it into attacker website then doing a post request to the legitimate transaction website. Since the cookie is still matched with the _csurf token and no other request has been made on the legitimate website that would change the original token then the request will still be forged.

So this is my setup:

When a user visits the legitimate site (let's say localhost:3000):

1. The server sets a CSRF cookie (e.g., csrfToken=hashedabc123)

2. The page includes a matching hidden form field ( _csrf=abc123)

3. The attacker manages to copy that hidden CSRF token value from the legitimate site

Now, when the user visits the attacker's site:

3. The attacker's form points to http://localhost:3000/transaction with his copied _csrf token and the legitimate website csrfToken cookie is still attached and no new cookie value has been set because the user did not do any action that would reset the token/cookie

=> the request has been forged.

Do I understand something incorrectly or how is it supposed to work?

Answer 1

The attacker only controls his own website. He does not control the client browser, nor does he have access to the user session (because in either case he would not need CSRF and would have better options).

Also it's important to note that the CSRF token is bound and unique to the user session (by which I mean the user's current "logged in state", whatever way that is maintained).

But then the attacker cannot just visit the legit website himself and copy the token (because that's a different token for him). The attacker would have to be able to grab the CSRF token via the victim user who is visiting the malicious website. However, that is not possible, the same origin policy (SOP) in browsers will prevent cross-origin access, ie. even if a victim user visits the malicious site, javascript running there will not receive information from the legitimate website (the response will be prevented from reaching the malicious website by the browser according to the SOP). The attacker will not be able to read the token from the hidden field, nor will he be able to access (read or write) cookies for the legit website.

So in the end, from the attacker's perspective the real token value in the victim user's cookie is unknown, he will not be able to match that in his own request to the victim site.

That is, unless there is cross-site scripting for example. If the attacker can exploit XSS in the context of a user's session, then he can also technically exploit CSRF, but there is no need to, because with XSS he can do whatever he could with CSRF and more.