Closed muthu-cs closed 8 years ago
I'll explain a little bit here.
So client-session
works by encrypting the contents of a cookie with a known secret. That ensures that the client cannot mutate the contents of the cookie since they cannot decrypt the payload. So that gives you a way to store secure data in an insecure environment, and validate the contents the next time it comes around.
This, by itself, is susceptible to csrf.
So you still need a secret and a token. You could store the secret inside the "client-session" and use that for generation and validation but there's a problem there, too. This is now susceptible to replay.
So now you'd probably want to invalidate the secret in the space between validation and new token generation or, at least leverage time-based invalidation.
Said another way: we cannot simply say, "use a session or, in place of that, cookies," as cookies are inherently insecure. If, however, there is some mechanism for securing them (like client-session), that's fine, however the data needs to be accessed through that secure interface.
In short, if you leverage the cookieName
configuration of client-session to make it look like a traditional express session, you'll be good to go*. app.use(require('client-session')({ cookieName: 'session' })
. Just be sure to add sane expiration as well.
* - there is a caveat here. Express sessions actually expose a number of methods. If anything in your pipeline expects those methods to be there, you'll have some trouble. You may end up having to build an API compatible session object.
Thanks!! agree with your points. However our apps uses different session names and we don't have req.session available. Hence, before calling lusca, copying actual session object to req.session, and that does the trick for me.
// lusca needs req.session to be present, before issuing _csrf cookie app.use( function(req, res, next ){ var session_name = getConfigValue('session_name'); req.session = req.session || req[session_name] || {}; next(); });
Closing as insufficient. Cookies are user provided. We cannot use them as a means of trusted storage of things such as the secret used to generate csrf tokens.