Do not use CSRF cookie as the next token value

[sberyozkin]

Fixes #36848

CSRF filter works like this: it generates a CSRF token, sets it as a routing context property, https://github.com/quarkusio/quarkus/blob/main/extensions/csrf-reactive/runtime/src/main/java/io/quarkus/csrf/reactive/runtime/CsrfRequestResponseReactiveFilter.java#L94

and then this provider helps to copy it into Qute templates which will have it saved as an internal form field, https://github.com/quarkusio/quarkus/blob/main/extensions/csrf-reactive/runtime/src/main/java/io/quarkus/csrf/reactive/runtime/CsrfTokenParameterProvider.java#L39, or it can be returned as a header value (for example in case of HTMX).
And a matching CSRF cookie is created.

Now lets imagine a Form containing a CSRF token POSTs something and it will be accompanied by the CSRF cookie, and the filter will compare it and if values match then all is good.

However, if a response to this POST is another form (as demonstrated in the test, or in similar cases), what happens is that the csrf cookie value, not the crsf token value (contained in the form field or header) which is returned in the next form, because, as soon as the cookie is found, it is set as the next CSRF token value and which will be set in the next form as described above, due to:

https://github.com/quarkusio/quarkus/blob/main/extensions/csrf-reactive/runtime/src/main/java/io/quarkus/csrf/reactive/runtime/CsrfRequestResponseReactiveFilter.java#L69.

It makes no difference when the CSRF token is not signed because both values are identical. When the CSRF token is signed, the cookie contains a signed copy of the token.
So when the Form POST is done, the filter, in order to verify that the cookie and the token match, signs the token and compares it with the cookie. Now, this cookie, which is a signed copy of the token is making its way into the second form as the next token value - but now both the cookie and the token are identical - both are now SHA-256 hashes, and therefore, during the follow up submission, resigning the token and comparing it with the cookie produces a false result.

It took several hours to figure out how to reproduce it in a test, and the fix is straighforward: simply avoid using the existing CSRF cookie value as the next token value, instead, when the cookie and the token already exist, it is the same original token value which has to be used as the next token value once it has been verified.

FYI, the test will fail without the proposed fix, since the token signature is required in that test

[quarkus-bot]

✔️ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

[sberyozkin]

Thanks @gastaldi , @FroMage is on the event so I'll merge, Steph, and also Andy @ia3andy , let me know if you will have some questions