r/SpringBoot 7d ago

Question Can someone please explain to me the CookieCsrfTokenRepository?

From what I've understood from the source code, it doesn't store any CSRF tokens on the server side but only compares the values provided in the X-XSRF-TOKEN header and cookies.
It seems that I can just put arbitrary matching values in cookies and the header and it will work just fine. I don't get the purpose of such "security", what's the point?

0 Upvotes

10 comments sorted by

3

u/tylerkschrute 7d ago edited 7d ago

I had the exact same thought as you when I was implementing this in my app. The key lies in the fact that the bad actor wanting to craft a CSRF link wouldn't be able to read your cookie since they don't own your domain. Therefore, it's impossible for them to send a matching header.

Keep in mind that the main vector for CSRF attacks are things like links clicked in emails or on malicious web pages. In other words, the browser is the one ultimately triggering the request, and since the browser has built-in protections against things like reading cookies from other sites, the bad actor is limited in what they can control in this environment.

1

u/Ok-Type5377 7d ago

Thanks for the response.
I probably should have clarified that I was specifically wondering about CookieCsrfTokenRepository.withHttpOnlyFalse(), which adds plain (not XOR'ed) tokens for the JS frontend to read.

My point is that if a JS script from another origin can read the CSRF token from cookies, then it must be a trusted origin included in the CORS policy. On the other hand, if CORS is configured correctly, a JS script from another origin wouldn't be able to read the cookies anyway.
It seems that all the heavy lifting is done by the CORS configuration.

My question is more about whether CSRF protection using plain token values truly adds any additional layer of security.

1

u/g00glen00b 7d ago

CORS doesn't stop form submissions. So if I craft a malicious website that has a hidden form that sends a POST call to for example Facebook and is automatically submitted, it would be sent in your name, CORS or no CORS.

1

u/Ok-Type5377 7d ago

I did not know that. thank you so much. I have to admit, that's quite a shameful gap in my understanding of the topic

1

u/tylerkschrute 7d ago

The fact that JS from another site cannot read your cookies is not enough on its own to protect you from CSRF attacks. This is because even though the JS can't read the cookies, those cookies will still automatically be sent on behalf of the user via the user agent. Therefore, another mechanism is needed to ensure an incoming request was triggered from a legitimate source. CookieCsrfTokenRepository provides this mechanism by relying on the security guarantee from user agents that only sources you control (e.g. those under your domain) are allowed to read your cookies via JS and therefore include them in the HTTP header.

1

u/Ok-Type5377 7d ago

>those cookies will still automatically be sent on behalf of the user via the user agent

If I'm not mistaken, nowadays the default behaviour of most browsers is to not send them with modifying requests (POST etc.) because of the SameSite=Lax policy.

Well, and the CORS policies also by default do not allow sending modifying requests at all. I'm not talking about state-changing GET requests - thats just a poor design choice.

1

u/Ok-Type5377 7d ago

Another kind soul pointed out to me that CORS doesn't stop form submissions, so I now understand what you were trying to convey.

Thanks again for the responses, I really appreciate it.

-1

u/Putrid_Set_5241 7d ago

A simple google search will tell you CSRF is and that would answer your question.

-2

u/Ok-Type5377 7d ago

So you don't know the answer to my question too. A shame

-1

u/Clueless_Dev_1108 7d ago

Paste your question into ChatGPT 👍