Page MenuHomeMiraheze

ManageWiki API allows viewing configs that shouldn't be viewed publicly
Closed, ResolvedPublic

Description

The ManageWiki API allows viewing of sensitive information set as visible to only ManageWiki right users (such as Discord webhooks)

This should be fixed immediately, likely by either creating another configuration variable to hide specific settings from the API, or by reverting ManageWiki changes to even support this, and move Discord webhooks back to PrivateSettings.php (which I really would rather not go that route as it's nice to allow users to add their own, and for support with other configs)

Event Timeline

Is it just discord webhooks?

Is it just discord webhooks?

Right now, Discord and SlackNotifications only.

Ack they're near forks of each other.

@Universal_Omega: Should that not match the private config flag? It seems like duplication to me.

@Universal_Omega: Should that not match the private config flag? It seems like duplication to me.

You mean the commits I did and PR paladox opened? If so then no because the private config is set as an option key from within MWS.php, and therefore the api can't really read it the same so I introduced a whole new config variable for the API to read.

But SpecialManageWiki can access it so why can't API do the same and just not emit it. That's a mistake waiting to happen.

But SpecialManageWiki can access it so why can't API do the same and just not emit it. That's a mistake waiting to happen.

Technically it probably could but it'd have to read the entire ManageWikiSettings config and check for the right keys, this seemed better.

But SpecialManageWiki can access it so why can't API do the same and just not emit it. That's a mistake waiting to happen.

Technically it probably could but it'd have to read the entire ManageWikiSettings config and check for the right keys, this seemed better.

I disagree. It's an extra step to think about and introduces a risk.

If this can’t be done as a single source of truth, my personal opinion would be to get rid of public/private settings until they can be done safely and securely.

But SpecialManageWiki can access it so why can't API do the same and just not emit it. That's a mistake waiting to happen.

Technically it probably could but it'd have to read the entire ManageWikiSettings config and check for the right keys, this seemed better.

I disagree. It's an extra step to think about and introduces a risk.

Well what about other scenarios also, there can be multiple reasons configs shouldn't be shown in API rather then that one key, this allows multiple reasons without adding hard coded checks for them all.

In T7213#143142, @John wrote:

If this can’t be done as a single source of truth, my personal opinion would be to get rid of public/private settings until they can be done safely and securely.

Thats fair and overall its up to the tech team. I'm only trying to fix a mistake but removing the private/public configs I really disagree with as it is hard to revert back to PrivateSettings.php (which of course if wanted it can be done) but also allowing users to manage it themselves is essential, but I guess its just opinion. Ots your choice.

Well what about other scenarios also, there can be multiple reasons configs shouldn't be shown in API rather then that one key, this allows multiple reasons without adding hard coded checks for them all.

Can you think of any?

I'm 1000% with John, we need a single source of truth whatever that might be.

You can create private patches too on GitHub so that's a doc to right after.

Well I guess you make a point ill redo commits to use ManageWikiSettings config.

RhinosF1 changed the visibility from "Custom Policy" to "Public (No Login Required)".
RhinosF1 changed the edit policy from "Custom Policy" to "All Users".

It seems that the visibility check is awkwardly implemented if each interface that exposes a setting needs to independently check the visibility.

Also (somewhat related): The PSA for the Discord/Slack hook security issue is probably of no interest for vast majority of the users: only Bureaucrats can act on the stuff, and the readers from external links don't even care if there's discord or slack stuff. It is probably a wise idea to implement some hacks (i.e. Wikimedia Stewards Election Call for Candidates CN banner which is only displayed if you have sysop on the wiki) so those who are simply not affected can skip it even further. (Or think of a better way to alert crats without relying on sitenotice/CN)

In T7213#143208, @revi wrote:

Also (somewhat related): The PSA for the Discord/Slack hook security issue is probably of no interest for vast majority of the users: only Bureaucrats can act on the stuff, and the readers from external links don't even care if there's discord or slack stuff. It is probably a wise idea to implement some hacks (i.e. Wikimedia Stewards Election Call for Candidates CN banner which is only displayed if you have sysop on the wiki) so those who are simply not affected can skip it even further. (Or think of a better way to alert crats without relying on sitenotice/CN)

Yeah I was actually thinking about that also. But I think it is OK if the site notice is up for only a day or 2, anything beyond that I think what you suggested should be done.

In T7213#143182, @Void wrote:

It seems that the visibility check is awkwardly implemented if each interface that exposes a setting needs to independently check the visibility.

True, ManageWikiSettings really should have this and by default be configured to display only non private settings. This would be one of numerous improvement to the security and reliability of this feature set.

In T7213#143208, @revi wrote:

Also (somewhat related): The PSA for the Discord/Slack hook security issue is probably of no interest for vast majority of the users: only Bureaucrats can act on the stuff, and the readers from external links don't even care if there's discord or slack stuff. It is probably a wise idea to implement some hacks (i.e. Wikimedia Stewards Election Call for Candidates CN banner which is only displayed if you have sysop on the wiki) so those who are simply not affected can skip it even further. (Or think of a better way to alert crats without relying on sitenotice/CN)

👍 to this idea, to allowing us to set the visibility to only local bureaucrats. There could be several ways to do this, I think.