Sounds like a good idea, and it looks like browser adoption is edging towards ubiquity. Just to clarify, assuming we're ignoring centralauth_Session for now, the session cookies I typically see being set on production wikis are:

1. GeoIP
2. {wikiID}wikiSession
3. metawikiSession - oddly appears as an enwiki cookie, but not on other projects.
4. PHP_ENGINE - showing up on some mw hosts?
5. thanks-thanked

And I assume a few others. Do we need to worry about these individually or would the envisioned implementation simply be to prepend __Host- to the name value for any cookie without a specified expiration within all relevant setCookie() calls?

I think the {wikiid}session are the ones to really focus on. At first glance i dont see meaningful attacks for the others (although i have no idea what PHP_ENGINE is, or why metawikisession would be set on enwiki). Although i suppose applying it to other cookies can't hurt, and better to be secure by default.

In T242661#5807489, @sbassett wrote:

1. GeoIP

It seems this one is set with a domain. Also I think it's set by the Varnish layer rather than MediaWik, although I see a few things in PHP trying to read it.

3. metawikiSession - oddly appears as an enwiki cookie, but not on other projects.

That's weird, and shouldn't happen. Someone should probably track that down.

4. PHP_ENGINE - showing up on some mw hosts?

Looks like it used to be set at the server level for the HHVM→PHP7 migration. It also looks like it was supposed to have been removed in rOPUP299a091b9067: mediawiki: remove the PHP/HHVM conditionals from the code and rOPUP2907741f3e5e: role::debug_proxy: remove old/unused aliases, depool mwdebug1002?

or would the envisioned implementation simply be to prepend __Host- to the name value for any cookie without a specified expiration within all relevant setCookie() calls?

You probably can't have setCookie() do it, since getCookie() wouldn't know whether to look for the prefixed vs unprefixed version.

Hmm, the PHP_ENGINE cookie seems to have vanished after some cache-clearing and a few re-authentications on my end. The metawikiSession cookie is strange - it seems like Chrome thinks enwiki should have access to it, while Firefox does not. And Chrome's Developer Tools console has it under a different domain (meta.wikimedia.org) than Chris Pederick's Web Developer toolbar (en.wikipedia.org), which erratically lists it. Perhaps this is just an issue with Chrome or with the various developer tools within Chrome.

You probably can't have setCookie() do it, since getCookie() wouldn't know whether to look for the prefixed vs unprefixed version.

Ah, yes. I'm guessing it would require a full name change for the cookie wherever it's set or gotten.

For Wikimedia wikis, this probably wouldn't make much difference since CentralAuth cookies work on the second-level domain and thus can't use it, and they are sufficient for the attacker. (Although that's not the case on wikimedia.org subdomain wikis.) We coult set __Secure- which is the less restrictive version, and prevents setting via HTTP - that would be useful.

For non-Wikimedia wikis, __Host- seems like a sane option. Although you can set it via $wgCookiePrefix, not sure if any explicit support is needed there.

@Bawolff pointed out that we could also use this for CentralAuth wikis which don't use a shared parent domain (e.g. all wikimedia.org wikis) which would be a significant security improvement.