Why doesn't this module store the raw session ID in the cookie directly?

[bookercodes]

I am posting in relation to this Information Security question that reads:

I am learning about session middleware.

You have to supply a secret or the middleware complains:

app.use(session({
 secret: "abc",
 resave: false,
 saveUninitialized: false,
 store: new MongoStore({
   mongooseConnection: mongoose.connection
 })
}));

I did some investigation and the actual session ID is

eKeYlF1DR6AtVkeFZK9vEIHSZT8e0jqZ

But according to the cookie, the session ID is

s%3AeKeYlF1DR6AtVkeFZK9vEIHSZT8e0jqZ.on5ifVE079C4ctKNdkNiJSh8NkQMckjd5fn%2FsxIQWCk

I am confused. Why is it insecure to store the session ID in the cookie directly?

As I understand it, if an attacker can attain this cookie, maybe via XSS or social engineering, the attacker can still hijack the session. I am not sure what the point of the secret is.

An authoritative member commented on this question:

Hi, welcome to Information Security. I'm not sure what makes you think that it is at all insecure to store the user's sessionid in his cookie (as long as you do it right). From what I can tell, you found that some halfbaked js library does something unintuitive. That doesn't mean it is insecure, or that that is the reason for it. You shouldn't be surprised if this is a halfbaked idea...

There is even more context in the comments of this answer.

Can someone here please shed some light on the issue?

Many thanks.

[dougwilson]

Too many people use an auto incrementing number as their session ID. You don't need to social engineer anything to guess another user's ID.

It also protects against leakage of a session ID outside of the cookie, for example if you were in a chat room and the app had a flaw exposing all the connected users' session IDs in the server communications--with only the session ID you cannot use it still, because it would have to be signed by an unknown secret to turn it into a valid cookie.

In the end, this lib was made a long time ago, extracted to it's own module and lives here being maintained. If a security expert would like to help us, that would be great. Signing cookies have many benefits, including you can change the secret and they all expire instantly, you are assured the cookie came from your server and was not guessed, and many others.

[dougwilson]

P.S. I am not the author of this module; you can fine the author of modules in the https://github.com/expressjs/session/blob/master/package.json

[dougwilson]

I would also like to reiterate that I stepped in to save this module from dying and simply maintain it's status quo. I can see from that stack exchange that the "security folks" are only interested in bashing this module, rather than perhaps coming over here, audited this code to even tell us if removing the signing is OK or not, or do we also have to so something else to be able to remove it?

I can only explain on what I believe are the reasons it was added before I took over this module. I am open to removing it if a security expert can assist in auditing the module and making sure it is the right thing to do, and none of the comments on that exchange are at all constructive as of this writing, mostly just "lol, it's unnecessary". Removing it would require a major version bump, which last happened 2-3 years ago, so we don't make decisions rashly, which is why I would like to see constructive thought before removing it.

[dougwilson]

So, I'm trying to figure out when the secret became required in this module (and sorry it's full history is not in this repo; it is a straight extract from Connect 2.x). I see that it is at least there in https://github.com/senchalabs/connect/blob/80b2d9ed70cae1bd51609dd41c1d69d9634a9ede/lib/connect/middleware/session.jsfrom January, 2011.

The other major Express.JS frameowork, hapi.js, also uses cookie signing for the session ID. Their module is https://github.com/hapijs/hapi-auth-cookie It may also be useful to ask this same question there, @alexbooker , so see what the reasoning it (they call the option password instead of secret, and as far as I can tell, it's required just like ours).

Edit: actually, the hapi-auth-cookie module may be more similar to https://github.com/expressjs/cookie-session than this module, so it may not be a valid comparison, sorry! The https://github.com/hapijs/yar module is probably the most similar to this module.

[bookercodes]

All good. I posted an issue there.

I appreciate your efforts in researching this issue. Thank you.

[dougwilson]

No problem. I am completely open to changing this, but it would be nice to understand what risks that would open, if any. I know this module has been the main Node.js session module for a long time and has passed much, much scrutiny prior. I mean, at worst, it's just unnecessary, but not actually harmful (or is it harmful? let me know), and at best it provides automatic protection for users who are using autoincrementing session IDs.

[gabeio]

It also protects against leakage of a session ID outside of the cookie, for example if you were in a chat room and the app had a flaw exposing all the connected users' session IDs in the server communications--with only the session ID you cannot use it still, because it would have to be signed by an unknown secret to turn it into a valid cookie.

Sadly, the author of the post that @alexbooker mentioned is correct if there was a way to retrieve cookies from other users, signing is zero defense as it would pass the exact cookie signed and all. The only thing this prevents is changing of the sessionID which is still something significant, in the event that there is NO way to steal other user's cookies the only way left to attempt to attempt to take over another user account is to tamper with the sessionID.

[dougwilson]

My main problem here is that the main answer on that stack exchange thread is an attack at this module's author and not constructive, which makes that person loose all credibility to me, so as far as I'm concerned there isn't even an answer to your question on stack exchange. I hope you understand that being hostile and berating people directly is not how things ever move forward in a community.

[dougwilson]

@gabeio this is correct, signing is not a defense at all from stealing cookie values.

This module also never claims anywhere that it is a defense, nor does this module suggest anywhere that storing the session ID in the cookie is actually insecure, which to me, makes the actual original question "Why is it insecure to store the session ID in the cookie directly?" weird, because we never said it was insecure to do so. To me, the question should be "Why doesn't this module store the raw session ID in the cookie directly?"

[dougwilson]

@alexbooker I was reading though OWASP to see if they had any guidelines, but I didn't see anything specific. I did find this section, though, which seems to be at least a reason why you'd want to HMAC the cookie value, which is what we are doing: https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Detecting_Session_ID_Anomalies

@alexbooker , thoughts?

[dougwilson]

Hey @evilpacket , do you have an opinion on this? What are your thoughts?