CSRF semantics questions

[GregJohnStewart]

Hey guys, I'm taking a stab at the CSRF extension, and came up with some questions...

1. How is the process protected, given cookies are client-side? Could not one circumvent by simply replacing the value from the form?
2. The guide only mentions protectingPOST requests, does it cover any other methods? It appears to not? To be clear, it seems that if a token is passed, it verifies but not if it's not included? Would be a security gap?
3. How does one verify the request via their own code when using token-signature-key? Is there an easy way to do it, or do I need to roll my own HMAC verification?
4. I'm noticing that even when I don't include a X-CSRF-TOKEN header to my json web request, it still passes the check. However, if I set that header's value to foo, it fails. what's going on?

I'll note my setup is possibly non-standard; loading webpages and doing GET/POST/etc with ajax calls. But still feels close to what I need, just a bit quirky

[sberyozkin]

Hi @GregJohnStewart

How is the process protected, given cookies are client-side? Could not one circumvent by simply replacing the value from the form?

You can't get access to the cookie from Java Script unless specifically requested

The guide only mentions protecting POST requests, does it cover any other methods? It appears to not?

All non idempotent verbs are checked.

To be clear, it seems that if a token is passed, it verifies but not if it's not included? Would be a security gap?

Are you talking about GET ? If it is get the absence of the cookie is tolerated because it is an idempotent method.
Can you give me a favor and create a reproducer ?

How does one verify the request via their own code when using token-signature-key? Is there an easy way to do it, or do I need to roll my own HMAC verification?

Yes, if you prefer to do it manually, as opposed to the CSRF extension doing it, then you'd need to have your own code doing it.

I'm noticing that even when I don't include a X-CSRF-TOKEN header to my json web request, it still passes the check. However, if I set that header's value to foo, it fails. what's going on?

I don't know... In general the CSRF extension is about having a token, possibly signed, matched against the cookie. Since you are talking about the manual verification, perhaps you disabled the token verification ?

In any case, please create a reproducer for us to have a more specific conversation.

Thanks

[sberyozkin]

Hi @GregJohnStewart, thanks for your thoughts. CSRF can be complemented with CORS as well, we've had a case where a CSRF solution was advised but CORS one was implemented instead.

But indeed, signing is recommended, as it makes it less naive as per the OWASP qualification of a double submit pattern, by the way, if you'd like to compare it in your own code, see https://github.com/quarkusio/quarkus/blob/main/extensions/resteasy-reactive/rest-csrf/runtime/src/main/java/io/quarkus/csrf/reactive/runtime/CsrfRequestResponseReactiveFilter.java#L176, you can call CsrfTokenUtils to check signatures.
REST CSRF extension is generic, it is not aware of the actual session cookies that might be created by Form, OIDC, or some other mechanisms, so it cryptographically binds the token to its own generated cookie.

I might recommend though that Quarkus defaults to generating it's own HMAC secret (and provide the option to supply your own),

This would cause similar issues to when OIDC session encryption key is generated by default, for example, after a restart, it won't be possible to verify the signed token the the client is submitting, or in a multi-pod setup.

Please keep experimenting and reach out with new improvement ideas or even bug requests (in the latter case, consider posting to [email protected])

Thanks

[GregJohnStewart]

This would cause similar issues to when OIDC session encryption key is generated by default, for example, after a restart

Good point on the restart, but yeah hence why I suggested the option to supply your own.

I just submitted a quick clarification to the docs; #50747

Unsure if I have thy other suggestions, after getting my brain around it it seems like a pretty good implementation, ended up being pretty drop-in, even with my slightly less standard setup. I might have a suggestion where the different extensions might respect a centralized cookie configuration? Example being the OIDC has its own set of cookie path/domain/etc so would be nice to have one place to set such settings. That's a bigger and out of scope topic to this though.

[GregJohnStewart]

Actually... did end up finding something, passing an email to security, thanks.

[sberyozkin]

@GregJohnStewart Synchronizing the cookie management is worth pursuing indeed

[sberyozkin]

We have a github issue, it can be rather tricky though to sync with for example how the oidc session is managed, refreshed, and given that oidc works with resteasy, rest, vertx routes, while this extension is quarkus rest specific.
We are probably talking about optional oidc centric csrf feature etc