CSRF validation through websocket?

[JohnMKuhn]

I have a separate express server setup for websocket connections for my Next.js application. My authorization policy for this web socket is to just use the JWT session token and CSRF token that next-auth provided for the session and are available as a request cookie. I specified my own encryptionKey and signingKey in the jwt config object in [...nextAuth].js so it seems verifying the JWT on the websocket side is as easy as taking these same keys and supplying them to the verify function provided by a library like jsonwebtoken on my express server.

My questions are:

• How can I verify the correctness of the CSRF token from this express server? It's not clear to me what secret information is used for generating/validating the CSRF.
• Does this sound like a solid approach for web socket authorization or are there better design patterns here?

Thanks!

[balazsorban44]

Nice! I see a lot of people not totally understanding how to use next-auth tokens in their API, but you seemed to crack the code! 😊 (If you are interested, I would be very happy if you created a small tutorial for people, and we could put it in the documentation https://github.com/nextauthjs/next-auth/tree/main/www/docs/tutorials https://next-auth.js.org/tutorials)

I don't think you should need the CSRF token on your separate API. Its purpose is to ensure a secure communication between the app's frontend/backend, not third-party APIs. If you already encrypt the JWT in addition to the signing, it is pretty much all you can do to protect your API, in addition to using short-lived tokens.

A JWT is self-contained, meaning once issued, it cannot be revoked (it could be blocklisted if you are made aware that a token has been compromised, but it might not be easy in practice).

See also: https://owasp.org/www-community/attacks/csrf
And read more about JWT here: https://next-auth.js.org/faq#json-web-tokens

[JMKJR]

Thanks for the response! (Posting from personal Github account now. JohnMKuhn is my work handle).

Would be happy to supply a tutorial within a couple of weeks providing the PR will get sufficiently reviewed as I am not a security expert. :)

I don't think you should need the CSRF token on your separate API. Its purpose is to ensure a secure communication between the app's frontend/backend, not third-party APIs. If you already encrypt the JWT in addition to the signing, it is pretty much all you can do to protect your API, in addition to using short-lived tokens.

Reading the owasp reference you linked helped improve my understanding of CSRF, thanks! Let me clarify that my separate server is not a "separate API" but is only used for accepting websocket connections. You are correct that if it were a REST API that didn't use cookie based authentication then a JWT is sufficient and a CSRF is not needed. However, I do believe a CSRF token is needed since in the design pattern I described in my first post, the websocket authorization is handled via parsing the cookies from the request header. Therefore, an attacker could initiate a websocket request and properly authorize by tricking the victim's browser into submitting its JWT from the cookie submit if there's no CSRF token protection.

Which brings me back to my original question since I have the CSRF token via the cookie request header but I don't know how to verify it on my websocket server

How can I verify the correctness of the CSRF token from this express server? It's not clear to me what secret information is used for generating/validating the CSRF.

I believe with my improved understanding of CSRF, I may have the answer to this question but I'd like confirmation. It seems like I can use the "double cookie submit" method. When the CSRF token is generated initially serverside on my Next.js app, I can place it hidden on the page and have it sent to the websocket when the connection request is initiated. This way, the express server handling the incoming socket request can validate the hidden CSRF that was sent matches the CSRF token supplied in the cookie. This way, the attacker can force a cookie submit but won't be able to forge/supply the CSRF needed in the request payload to match. Sound good?

[balazsorban44]

I'm actually not sure you will be able to decode it, as we create it specifically for next-auth.

I haven't really touched the original implementation though, so for reference, here is the source code if that helps: https://github.com/nextauthjs/next-auth/blob/main/src/server/lib/csrf-token-handler.js

I still don't see the reason for CSRF in your API though: https://stackoverflow.com/a/10741650

[JMKJR]

I'm actually not sure you will be able to decode it, as we create it specifically for next-auth.
I haven't really touched the original implementation though, so for reference, here is the source code if that helps: https://github.com/nextauthjs/next-auth/blob/main/src/server/lib/csrf-token-handler.js

In this implementation, the server is validating that it did indeed generate the original CSRF it issued by using a salt. However, I don't understand how this is a necessary step if the implementation is attempting to follow the double cookie submit method it references on line 15.

From owasp: "When a user visits (even before authenticating to prevent login CSRF), the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine separate from the session identifier. The site then requires that every transaction request include this pseudorandom value as a hidden form value (or other request parameter/header). If both of them match at server side, the server accepts it as legitimate request and if they don't, it would reject the request."

Therefore, isn't it sufficient enough for CSRF validation to just perform the assertion on line 29 and not even need to use a secret at all? You just need to make sure the token from the cookie matches the token from the post body because an attacker can trick you into submitting your cookies but he can't computationally feasibly provide a correct CSRF in the post body.

If this is indeed the case, then I feel the below quoted logic is correct from my previous comment but would like confirmation.

It seems like I can use the "double cookie submit" method. When the CSRF token is generated initially serverside on my Next.js app, I can place it hidden on the page and have it sent to the websocket when the connection request is initiated. This way, the express server handling the incoming socket request can validate the hidden CSRF that was sent matches the CSRF token supplied in the cookie. This way, the attacker can force a cookie submit but won't be able to forge/supply the CSRF needed in the request payload to match. Sound good?

I still don't see the reason for CSRF in your API though: https://stackoverflow.com/a/10741650

That's because it's not for a RESTful API, it's for a web socket.