TIL – CSRF in Node
Today I learned more in-depth about CSRF (Cross-Site Request Forgery) attack and more specifically how to stop it in node.
I’ve been thinking more about CSRF after having some conversations at work about it, as well as taking a (mandatory) security training, and wonder how I would go about implementing CSRF in my node application. Understanding CSRF is a pretty good, quick read on the topic.
At first, I suspected implementing a solution would be rather involved as I’d have to keep track of a time-based token (a unique random value that would last for some time, such as 30 minutes) on the server and validate any form request based on this token.
Turns out, it could be as simple as setting a strong random string as the token in the cookie (if the request does not have it set yet), and then expecting this value in the POST request payload (hidden field). The payload field is then compared against the cookie token to determine whether it’s a valid request.The cookie acts as the maintainer of the state of the CSRF token in this case.
In the hapijs world, this is done with crumb. I’m not familiar with hapi, but when looking into it, I learned about cryptiles, which is a general purpose utility that could create the cryptographically strong random string mentioned above.
In the expressjs world, there’s csurf. It uses csrf under the hood, which took a slightly different approach where instead of a random string, it generates a token using ‘sha1’ salted hash with a secret. The secret is attached to the session (either via cookie or session middleware (httpOnly cookie)). In the csurf’s example, the token is not sent to the client via a cookie, but just rendered to the form directly. It can later be verified by the server using the secret. It is recommended that the token not be sent back in a response body.
For my use case, I am not using an express server-side rendering architecture, so the token will most likely be sent to the client via a cookie, and then read and embedded by the client before POST-ing back to the server. I will update this post when I try this out successfully.
Sidenote: while reading about these implementations, I also learned about timing attacks when doing simple string comparison. So both of the libraries I mentioned above (cryptiles and csrf) use constant time comparison. The former implements its own method, while the latter uses scmp.
Update: upon further thinking, for csurf and csrf, the secret is actually the thing that is comparable to the token in crumb. They’re both created using node’s crypto randomBytes method, which is presumably strong enough to not be guessable. In my limited understanding, I am not sure why the extra step of generating the token is necessary, as the token can be regenerated with the secret, and the salt is stored with the token as well. Perhaps one benefit is to tie the token to a particular session when storing the secret in a session-specific manner (not setting it as a regular cookie).