Sending forged user right changes to the webhook

[Soveia]

It appears it is possible to send forged user right notifications to the webhook, maybe even other log entries. No changes actually happen. I have no idea how this is done, however, but it did stop once the offender was blocked.

Figured out how it works.

Mediawiki won't outright reject your POST request for usergroup changes when you don't actually have permisions to do that. While whatever you do in the UserRights form will silently fail in the background, this is enough to throw a Discord notification with the Reason text supplied. This can be done even if you are not logged in and the wiki does not allow IP edits.

Works with another Discord extesnsion too. Could be a a mediawiki bug.

[jayktaylor]

Interesting - thanks for raising this. Will investigate.

[jayktaylor]

Hey @Soveia, can you confirm what version of MediaWiki you are using to reproduce this, along with reproduction steps?

[Soveia]

We currently use 1.39.1

How I did this was to copy over the userrights form HTML from another wiki I had permissions on to the target wiki's userrights form. Write in a reason and submit the group changes.

The group changes will not go through but the reason will get sent to the UserGroupsChanged hook and pass the data along.

You could do this faster by using perl to send the same POST requests to the server but I don't have a script at hand to do so.

This is probably a Mediawiki bug, not really extension specific. The UserGroupsChanged hook shouldn't pass data that wasn't authorized by the permissions config to begin with. MW already prevents the group changes from going through, it just doesn't give any feedback (eg. no permissions prompt). If I try this with another privileged form, like deletion, MW throws a permission error and the extension won't get reason data from the ArticleDeleteComplete hook.

So far, the only workaround is to just disable the UserGroupsChanged hook for the extension. Blocking the offending user/IP seems to work as well, presumably the isBlocked check happens early enough in the userrights process.

E: mislick with the close button.

[jayktaylor]

Thanks - this is really interesting. Weirdly enough though, I'm not able to reproduce it on either 1.39.1 or the current master branch of MediaWiki (1.41 beta). I've tried both copying the HTML for the form across from a privileged wiki, and sending a direct POST request to the server.

That said, I agree that this is probably a core MediaWiki bug, if anything.

[Soveia]

Could this be specific to a PHP version? We run Debian so our PHP version is still 7.4.33. Another wiki I tested this is running 7.4.3 under Ubuntu with apache2handler.

I don't know what httpd that other wiki is running due to cloudflare but we use nginx.