Generate CSRF cookie in case of failures

[sberyozkin]

Fixes #30594

We've agreed with Steph that I'll create a PR alternative to #30672. I'll add tests here if we agree this is the way to go.

Both PRs have the same goal, fix #30594.

#30672 fixes by not generating CSRF cookie if the request CSRF filter did not run due to the exceptions: i.e - if no CSRF token bytes were generated which will be injected in the form then do not return the cookie as well.

This PR takes a different approach - generate the cookie with or without the exceptions. So if for example HTTP GET fails with the authentication error, the cookie will be returned and on subsequent GET it will be returned and will save CSRF request filter from generating the token.

I have to admit, I'm only opening this draft PR because I promised Steph to open it for Paulo also to have a look, I'm also adding Stuart.

IMHO, #30672 is simpler. Returning the cookie in non-successful responses appears to be strange to me, even though I do get what Steph is saying. It just seems unnecessary. It might open some scenarios where a DOS attack is attempted on the secured Quarkus site, deliberately failing the authentication, with the secondary goal of mining the signed cookies and trying to mint the key. Theoretical, may be, but all in all, my preference goes to #30672.

@pmlopes @stuartwdouglas We will appreciate your help with the reviews.

[FroMage]

I like this version better, because it's more regular for users: any GET method will get you a CSRF token cookie, even 404 or other types of non-200 failures.

[sberyozkin]

@FroMage Hi, I've just arrived here to close this PR :-).

I just can't get out my head that this is not what CSRF feature has to do. I feel it should not be designed to meet for example the test expectations that any GET method will return the cookie, because it is only successful GET request returning an HTML form data should have this cookie in the response. This cookie's function is about supporting secure HTML form submission, a situation where a browser is getting this cookie without HTML form being returned now or earlier makes little sense to me now.
The fact this cookie is returned back to Quarkus after unsuccessful responses and save on generating the bytes is of minor optimization concernm the equivalent saving can be achived by not generating the cookie if no form payload is returned due to non-200 status.

But I also think the following does not work: POST HTML form with the csrf token and the cookie, the request fails due to the earlier filter detecting an invalid form parameter not related to CSRF because the user entered the wrong value in the form (ex, dob), now CSRF cookie is still generated, next POST with the fixed form input fails because its hidden csrf token was not synced with the newly generated cookie.

[sberyozkin]

Ignore that POST scenario though the earlier comment still make sense

[stuartwdouglas]

deliberately failing the authentication, with the secondary goal of mining the signed cookies and trying to mint the key. Theoretical, may be, but all in all, my preference goes to #30672.'

This is not a 'signed' cookie, it is a completely random string generated by SecureRandom, and there is no key.

[sberyozkin]

@stuartwdouglas It can be signed as well if requested via the configuration.

But I'm more concerned right now that returning it without HTML forms does not give any actual CSRF protection...only a minor optimization with the user returning with the cookie next time

[sberyozkin]

@FroMage Steph, I see you approved both PRs. Now it is really difficult because you are too kind. Oh dear :-). I'll wait for a bit for more comments, we might need to schedule a dedicated f2f to find the most optimal solution.

[sberyozkin]

Closing now, thanks Steph, Stuart