Can we really protect against all "stupidity"?

For example we don't prevent someone from being able to create content at the front end as a guest with all filters disabled and the ability to upload images etc.

You can never protect against all 'stupidity', but that's not a reason not to protect against what you can.

@DavidBoggitt We can protect against the example I gave as well and its much more likely but we dont

I see no problems with this - if the webmaster is dumb enough to change the default registration group to super user then they either have a genuine reason for this or they need to learn their job as webmaster fast.

Most webmasters if they didn't know what this did would leave it as registered, and if they did they might have a genuine reason for doing so - like if the site is running on a private LAN for developing and they don't want the hassle of keep authorising super users into the super user list.

Whilst it may be true it's unlikely to happen, but it's like saying that we should put a guard to stop stuff from going near a blade on a chainsaw just because someone might cut their hand off with it.

You can protect against some things but sometimes if you start wrapping things up in cotton wool too much you start to become too restrictive

What would be the criteria as to which groups could not be used for a default usergroup?
It could not be based on the user group name or the user group id. It would have to be based on the permissions for that group and in that case what permissions?

I see no reason to restrict this.

It would have to be based on the permissions for that group and in that case what permissions?

I would suggest the global core.admin permission.

i've made a quick test, and you cannot register from frontend a new user as SuperUser even when this setting is in place

Set group for new users to Super Users.

there is already a check that prevent this https://github.com/joomla/joomla-cms/blob/staging/libraries/src/User/User.php#L791

nice @alikon thanks for this simple test... sorry we didn't do this in the first place

BTW, "User not Super Administrator" should be translatable... and does not really represent the error here.

yes right.... it can be improved, it's not really easily understandable, plus the same test should be made on j4... my fault, still didn't have the time to do it on j4

@HLeithner

This does raise the issue however of how that initial site was compromised as the original assumption was not correct (as shown by @alikon) and that code has been in place for a decade or more.

@alikon
Same result in J4.

thanks @infograf768 to cover my back.... ?
so i'm considering this as it was a false negative issue

@brianteeman that's the question, we will give this feedback to the reporter.

The original report started with:

I wanted to raise an issue, but it is actually more a security concern.

So I think he / she didn't tested it before reporting his / her concern.

I will report back when I get an answer.

Hello,

I actually missed to give an information I wasn't aware at that time. The guest user group setting below the newly registered user group has to be set to super user too. The guest is then able to register as Super User.

could you please share a screenshot of that to avoid confusion

if you mean something like this screenshot

then you already lost the war because every site visitor is super user already and don't need to register...

This is the setting I am talking about. There is no need to change any arrangement for user groups if the guest is set to super user.
If the guest is super user he becomes super user at registration.
So if someone tries this setting while playing/learning on a live system there is a pretty good chance that a bot will be registering right in that moment even if the user is just testing that for an hour.

With the amount of attacks these days, I just think having a settings

1. to give guests super user rights
2. to register user as super user
   should either be removed or it should get a red warning like the PHP version messages.

From my point of view there is no doubt that this is a very unlikely setting. But there is a risk.

And unlike my first thoughts, the main problem is not that someone can be registered as a super user, but that a guest user can be treated as super user. If the decision was on me, I would remove that possibility.
The register as super user function I would remove too, but if there are good arguments to keep it, a warning could reduce the security risk of keeping it enabled by mistake.

I can confirm that in the scenario tested by @alikon you can not register as a super user

I can confirm that in the scenario above from @StefanSTS you can register as a super user

I just see this issue was closed on 21st Dec 2019. I did not realize that before.

It was closed before the real issue was clearly understood. I still see this as a low security risk that should be addressed.

So for removing the option to be able to set guest users as Super User I request to open this issue again.

Whilst it may be true it's unlikely to happen, but it's like saying that we should put a guard to stop stuff from going near a blade on a chainsaw just because someone might cut their hand off with it.

If you would like examples of cutting machines with guards to stop people cutting their hands off I can provide thousands of examples.

please test #27629
not sure if it is the best approach so i let this issue open till feedback

@alikon I tested the code on a 3.9.15 RC, it works as described. Thanks you.

There is still my concern that evolved from this super user registration issue.
Is there any intended use for the setting that the guest user can be super user?
Is anyone using that?

From my point of view there should be only:
Public

• Guest
• Registered
  as an option for the guest user.

Are there any experience from other systems how it is handled there?

I guess my intial issue is solved, only in case the setting super user is removed later on for the guest user, this additional code would be redundant, so it might be a good idea to have a final decision on if it is to removed or if it will stay.

the reason for using the user plugin was : https://github.com/joomla/joomla-cms/blob/staging/libraries/src/User/User.php#L762-L765

		// The only mandatory check is that only Super Admins can operate on other Super Admin accounts.
		// To add additional business rules, use a user plugin and throw an Exception with onUserBeforeSave.

please test #28011