Cookies' names should be customizable

[rassie]

Currrently, at least sessionID conflicts severely with many web frameworks' own session cookie. It's desirable to either change that generic name to something more Etherpad-specific or make the cookie name configurable.

[jhollinger]

+1. I would vote for something more specific, like EtherpadSessionID or EPSessionID. As long as it's EP specific, I don't see any advantage to being able to customize it.

As far as implementation goes, this may be related to issue #322.

[fourplusone]

@jhollinger changing the sessionID would break all setups using them when they're updated.

[jhollinger]

@fourplusone Depends on how it's done. We would need a long transition period where the contents of sessionID would be transferred to the new cookie. Ugly for now, but I think it's a much better decision long-term.

[JohnMcLear]

Aren't cookies stored within the site namespace? I don't really see how this is a problem..

[rugk]

Any news on this?
BTW I do not even have a cookie called sessionID. I have this one: express_sid

[hanwenbo]

@rugk SessionID need you through the API interface generated, but how to set etherpad sessionID in other domain name, I haven't solved, is currently a manual change

[JohnMcLear]

Can someone provide an example scenario where this is a problem? So I can setup an environment etc to replicate the bug.

[rugk]

What scenario? The scenario is very simple: change the session cookie name. The environment is just a web server and etherpad, nothing special, nothing to setup.

But since you've asked, maybe you'd want to use cookie prefixes like __Host_ to make the cookies more secure.
Actually good you've asked, because you could obviously also do this by default.

The OP, however had another use case: The cookie name conflicts with other frameworks…

[JohnMcLear]

Is this only if Etherpad is in a subfolder ie

http//room.com/Etherpad/p/mypad

?

[JohnMcLear]

Okay this is worth addressing IMHO but it will be 1.9 release as it will be a breaking change.. @muxator please input

• Update DOCS: Document cookie usage in Etherpad - Waiting on Final Edits #3563 @muxator I guess this goes into the wiki so when/if this merged just update all cookies to have key name with prefix of ep_
• Include a prefix probably ep_ - PR = Namespace for cookies - Ready for review - 1.9? Breaking change. #3981
• Enable secure if SSL is enabled
• Test auto for delivering secure cookies over SSL is working - admin must set trustProxy to true in settings.json. Even with that set Observatory reports secure is not being applied to all cookies. Looking dev tools I can see that express_sid is httpOnly and !secure -- @muxator you worked on this in Secure flag is not set for cookies in HTTPS #3561 but it does not appear to be fully functional. -- Interesting, setting secure value in webaccess.js to true causes pad access to break. So TLDR unless you do Cert pinning (IE have the certs installed on both nginx and express this will fail. Which is totally fine IMHO :D But still @muxator do you wanna setup the nginx environment and confirm that with the example config we have that cookies arne't delivered secure?
• Ensure we have completed everything from the Express guide:

Use cookies securely

To ensure cookies don’t open your app to exploits, don’t use the default session cookie name and set cookie security options appropriately.

There are two main middleware cookie session modules:

express-session that replaces express.session middleware built-in to Express 3.x.
cookie-session that replaces express.cookieSession middleware built-in to Express 3.x.

The main difference between these two modules is how they save cookie session data. The express-session middleware stores session data on the server; it only saves the session ID in the cookie itself, not session data. By default, it uses in-memory storage and is not designed for a production environment. In production, you’ll need to set up a scalable session-store; see the list of compatible session stores.

In contrast, cookie-session middleware implements cookie-backed storage: it serializes the entire session to the cookie, rather than just a session key. Only use it when session data is relatively small and easily encoded as primitive values (rather than objects). Although browsers are supposed to support at least 4096 bytes per cookie, to ensure you don’t exceed the limit, don’t exceed a size of 4093 bytes per domain. Also, be aware that the cookie data will be visible to the client, so if there is any reason to keep it secure or obscure, then express-session may be a better choice.
Don’t use the default session cookie name

Using the default session cookie name can open your app to attacks. The security issue posed is similar to X-Powered-By: a potential attacker can use it to fingerprint the server and target attacks accordingly.

To avoid this problem, use generic cookie names; for example using express-session middleware:

var session = require('express-session')
app.set('trust proxy', 1) // trust first proxy
app.use(session({
  secret: 's3Cur3',
  name: 'sessionId'
}))

Set cookie security options

Set the following cookie options to enhance security:

secure - Ensures the browser only sends the cookie over HTTPS.
httpOnly - Ensures the cookie is sent only over HTTP(S), not client JavaScript, helping to protect against cross-site scripting attacks.
domain - indicates the domain of the cookie; use it to compare against the domain of the server in which the URL is being requested. If they match, then check the path attribute next.
path - indicates the path of the cookie; use it to compare against the request path. If this and domain match, then send the cookie in the request.
expires - use to set expiration date for persistent cookies.

Here is an example using cookie-session middleware:

var session = require('cookie-session')
var express = require('express')
var app = express()

var expiryDate = new Date(Date.now() + 60 * 60 * 1000) // 1 hour
app.use(session({
  name: 'session',
  keys: ['key1', 'key2'],
  cookie: {
    secure: true,
    httpOnly: true,
    domain: 'example.com',
    path: 'foo/bar',
    expires: expiryDate
  }
}))

[JohnMcLear]

Okay I'm done here, @muxator can handle final bits as it's bits he's already been heavily involved with :)