@Tgr, could you please add some more information to help us make a decision to prioritize this task? For example, what is the cost of not doing this? Thank you.

Session leaks (such as {T256395} or {T264369} or {T274514}) happen when MediaWiki emits authentication cookies and some mishap with caching-related HTTP headers or reverse proxy configuration causes the response to be reused for another user. Usually this happens when session cookies are emitted uncontrollably (meaning not on a request where it's clear that would happen, like login, but on an arbitrary request) - these are hard to argue about, because the response which has the cookies could have any kind of caching headers, it could be a redirect which gets special handling from the reverse proxy, it might be the output from a fatal error where some of the header handling logic we'd expect to run doesn't, etc. Hopefully we have weeded out the last of those bugs with the recent Varnish VCL change, but minimizing cookies sent by MediaWiki in the first place would be good defense in depth.

There are three situations in which session cookies are emitted uncontrollably (where SessionManager will set the cookies right in Setup.php): session renewal (cf T264794: SessionManager should not emit Set-Cookies on session renewal), session creation based on a valid user token cookie, and local session creation based on a valid central session cookie (this issue).

As for impact: as it is now, a session leak happening CentralAuth creates a local session would result in the recipient of the leak being logged into the victim's account on all language editions of a project. If this were fixed, only the login for the specific wiki would leak.

Tagging the Security-Team to chime in on priority

CentralAuth needs a central session to be present for performance reasons. It's used like a cache. We could potentially fix that, or make CentralAuth cookies be local to the 3LD, at the cost of requiring a re-authentication handshake every time someone goes from one wiki to another. But I'm not convinced this is necessary. Surely it should be possible, at least in principle, to stop caching Set-Cookie headers?

The scenario considered in this task is where the request contains a valid set of central (second-level) cookies but no local cookies (the user visits a language version they haven't used for a while). CentralAuth authenticates the user by matching the central cookies to the central session, and creates a local session; it needs to output the local cookies matching that session, but it actually outputs both local and central cookies - always outputting every relevant cookie made the session provider code more convenient to write, I guess. Changing that might be easy (although I haven't looked at the code) and does not affect functionality in any significant way. Admittedly it is something of a security micro-optimization.

In T264798#6863050, @tstarling wrote:

Surely it should be possible, at least in principle, to stop caching Set-Cookie headers?

See https://gerrit.wikimedia.org/r/c/operations/puppet/+/663845 and https://gerrit.wikimedia.org/r/c/mediawiki/core/+/663914. This task was filed before we figured out the exact mechanism for session leaks (assuming that was the only mechanism), but it might still be good for defense in depth.

In T264798#6859999, @daniel wrote:

Tagging the Security-Team to chime in on priority

We chatted about this in the Security-Team clinic today. Since we're currently not aware of any active exploitation of leaky SUL sessions by malicious actors, and it was conceded this is likely a security micro-optimization which may have been solved in some of the aforementioned change sets, we'd rate this low risk for now and encourage the ongoing performance vs. security discussion that seems to be taking place. Just given the purpose and implicit bias of the Security-Team, we'd probably favor optimizing in favor of security, but there are obviously trade-offs in this case.