@SniperSister and @HLeithner It would be great if you had a quick check

I think bad idea

@joeforjoomla Thank you for your feedback. Can you tell me why you think that's bad? Can I do something better or do you think the names shouldn't be identifiable?

Looks good to me! :)

from https://owasp.org/www-project-cheat-sheets/cheatsheets/Session_Management_Cheat_Sheet.html

Session ID Name Fingerprinting
The name used by the session ID should not be extremely descriptive nor offer unnecessary details about the purpose and meaning of the ID. The session ID names used by the most common web application development frameworks can be easily fingerprinted, such as PHPSESSID (PHP), JSESSIONID (J2EE), CFID & CFTOKEN (ColdFusion), ASP.NET_SessionId (ASP .NET), etc. Therefore, the session ID name can disclose the technologies and programming languages used by the web application.
It is recommended to change the default session ID name of the web development framework to a generic name, such as id.

prefixing with joomla could enlarge potential attack surface or i'm missing something obvious...
just asking

?

If there is some legal requirement (not someone’s misguided interpretation of a law) that mandates cookie names are crystal clear, then a different strategy for these names should be devised (as said requirement would mandate a cookie name like joomla_admin_app_session), otherwise this is B/C breaking and change for the sake of change.

@astridx apart all possible B/C consequences, now you are asking to clearly show to the entire world that a website is built on Joomla. Now there is a good, anonymous, hashed cookie name. I don't see a reason why there should be 'joomla', hey this is a Joomla website! Come on hacker i'm Joomla!

@joeforjoomla @mbabker Thank you for your opinions.
Can you tell me where a backward compatibility (B/C) problem can arise? I thought about it, but I probably don't have the experience. I do not see it.

@alikon @joeforjoomla I saw the link to https://owasp.org/www-project-cheat-sheets/cheatsheets/Session_Management_Cheat_Sheet.html . I have also seen this post on stackoverflow and share this opinion.

I don’t see a need for this change since browsers can show me for a particular website which cookies are stored for it. Or am I missing something?

The reason is simple, it's for loadbalancers and reverse proxy/caches to be able to filter sessions cookies easily.

....again just asking.... i'm not a security expert nor a webhoster.....
but even in that case should be something like a "sitename_" / "webhostuserid_" and not "joomla_*"

in case a user is logged in we already send a joomla_user_state cookie identify us as joomla site.

Commenting on the "exposing the used CMS" argument:

There are basically two sorts of scenarios for an attack:

1. it's a mass exploit: in those case it's completely irrelevant if the used CMS is exposed or not because attackers simply don't check for this. The reason for that is easy: "Check" & "Attack" are two separate HTTP requests, a simple blind "Attack" is just one. If the attack request fails, they just move on, if it worked it's jackpot time. So, hiding the used technology is pointless.

2. it's a targeted attack: if someone cares enough to specifically target a single site, it's dead easy to identify the used CMS anyway. A cookie name would be just one in a gazilion ways and the benefits weight out that downside by far.

However, there's one issue here that I haven't thought about and that's a deal breaker here:
This PR will break the update process, because a user will be logged out after the new files have been written as the session name changes. So we would have to add some code to take account for this. Considering the amount of effort for that, I would argue that it's probably not worth the pain in the 3.x branch.

Instead I would suggest an optional prefix for 4.x

We definitely don't want to have the pain of the update issue - again.

Instead I would suggest an optional prefix for 4.x

Wont that mean we still have the pain for updating from 3 -> 4 ??

If the session name (and inherently the name used for the cookie) that the system generates on 3.x is not compatible with the session name that the system generates on 4.x then you're going to have upgrade problems (basically you'll get logged out mid upgrade and then the upgrade will be in a partially complete state when you're trying to re-authenticate and well, good luck).

Yes, there is benefit in a predictable name. But I'm not sold that that benefit alone is worth the B/C break introduced by changing the logic in generating session names. Because ultimately for that to be beneficial, you need a predictable and unique cookie name. A prefixed name that still contains the hashed suffix isn't really fixing much.

Also, I'm just going to point a couple of other things out:

1. Changing this in the Session class is massively wrong, this essentially removes the ability for an outside consumer to configure the name.

2. Joomla is already configuring the name, see the CMSApplication class. If you remove the hashing part of the name value in the array, you can already use the shared sessions feature to get a prefixed name without breaking B/C for every Joomla website out there.

So architecturally this pull request needs changes if it's even going to be entertained, which I personally am not convinced it is worth the hassle.

Maybe a new option "Cookie prefix" in global configuration, with default either none or a randomly generated thing like we have it with the db prefix? I could set it then to "grwntzl" and could know (or look up) that it belongs to which of my websites. 3rd party tools or script also could look it up, and with such prefix it would still not be obvious that it's a Joomla site. If someone then sets it to "joomla_" it is his/her own problem.

The reason is simple, it's for loadbalancers and reverse proxy/caches to be able to filter sessions cookies easily.

If that is the reason, then a hard-coded "joomla_" like done with this PR makes me ask myself how shall that load balancer then distinguish between several different Joomla installations on one server, like we often have it for testing?

That's why I suggest to make it configurable e.g. with a global configuration option.

@richard67
During the conversation, I understood that it is basically important to narrow down the session. In conversation, we came to the conclusion that a fixed prefix would be good. That is why I made this PR. But I will now ask whether a configurable prefix would solve the problem.

@richard67
During the conversation, I understood that it is basically important to narrow down the session. In conversation, we came to the conclusion that a fixed prefix would be good. That is why I made this PR. But I will now ask whether a configurable prefix would solve the problem.

Well, it will not solve any problem. It will expose the used CMS in a less obvious way when not using "joomla" as prefix, but as @SniperSister correctly mentioned above, it is still easy to see which CMS is used by other methods. Just see in browser which css and js is loaded, or just inspect html source.

So after having thought about it for a while, I think there is not much benefit in a configuration option, except that I have control on this prefix.

For load balancing tools or other stuff: If they are configured in the right way they should not mix up the cookies from several Joomla installations with same cookie prefix.

And for the most serious problem with session change during updateing it isn't a help at all.

So the more I think about it, the more I think: Forget my idea with the configuration option, there are more urgent things to solve when introducing that cookie prefix.

... web hosts can recognize that the cookie has been set by Joomla.

hm, why the hoster should care about who set the cookies?
if it need for caching or other fancy stuff, just add one more extra cookie with plugin or something

hm, why the hoster should care about who set the cookies?

Hosters care about cookies because they influence the way some caches work. When a session cookie is started, the caching layer thinks that user is logged in and no contents should be cached. In Joomla, every single access starts a session and this makes caching much more difficult and less accurate.

I completely agree that priority is to do not broke compatibility and make the upgrade process as much as easy as possibile but, in some future Joomla releases I would like to se a session_start only when it's needed. In this case even a completely random name would be fine.

@brianteeman We definitely don't want to have the pain of the update issue - again.

You are absolutely right. So it's good that so many people are watching here.
Thank you all.

@AlessioLustri ..... but, in some future Joomla releases I would like to see a session_start only when it's needed. In this case even a completely random name would be fine.

Thank you for your explanation.

If I understand that correctly, then renaming the session was only a workaround and the real problem is that this line is executed with every action, right?

Sounds more like a cache configuration issue than a joomla issue

Sounds more like a cache configuration issue than a joomla issue

Not really, this only happens on Joomla. As far as I know, no other cms starts a session for guests users. Is there a reason for that?

Yes, just because you are a guest does not mean that there are not things that aid the visitors experience by being tracked during their visit.

Yes, just because you are a guest does not mean that there are not things that aid the visitors experience by being tracked during their visit.

We only need this (in core) for XSS token and this is only needed when the user is logged in, so no we normally don't need a session. It's a concept issue in Joomla and should be fixed because creating sessions blindly is a performance problem for site with higher visit load. (But this is another topic).

I have the same problem for my frontend cache, I have troubles caching static content like .css file because the browser sends a session cookie with most of the time use less in this case you can't serve the .css file form the cache because you (as hoster) doesn't know if this is a session cookie or a random cookie and if it's relevant for the current file requests. So you pass the request to the application server and waste cpu cycles and add delay/repsonse time to the request.

We only need this (in core) for XSS token and this is only needed when the user is logged in, so no we normally don't need a session

contact forms?

We only need this (in core) for XSS token and this is only needed when the user is logged in, so no we normally don't need a session

contact forms?

In cases where you need it you have to start the session, that could be done automatically when you request a XSS token.

With PHP 7.3 and samesite option for cookies make the XSS token more or less unneeded (depending on the browser support)

We only need this (in core) for XSS token and this is only needed when the user is logged in, so no we normally don't need a session.

So not a valid statement

With PHP 7.3 and samesite option for cookies make the XSS token more or less unneeded

So not relevant as our browser and php requirements are lower

We only need this (in core) for XSS token and this is only needed when the user is logged in, so no we normally don't need a session.

So not a valid statement

With PHP 7.3 and samesite option for cookies make the XSS token more or less unneeded

So not relevant as our browser and php requirements are lower

I already said in my first reply thats another topic and not really relevant for this issue.

(sorry I missed that)

Sessions are started because of the access check in deciding what plugins are to be loaded. But nobody agreed with me that this was a valid issue to address. So it’s still impossible to even get to onAfterInitialise without a session started and possibly let a plugin adjust session related behaviors (which is still high risk at that stage as you really have no idea what is going on in the request cycle; realistically if core could get on a path where there aren’t any session interactions until after the request is routed (which can let the page cache plugin serve a response without a session), if not into components themselves, then the floodgates get opened as far as granular control over sessions and being able to get to a stateless platform, but this would involve some major rethinking of some core features like language support).

/semi-off-topic-rant

See #27614