Currently, MediaWiki administrators (members of the sysop user group) have the ability to edit Javascript pages: site-wide JS such as MediaWiki:Vector.js, MediaWiki:Gadget-*.js pages (used by the Gadgets extension, can be configured to load by default) and JS subpages of another user (including User:<name>/global.js, used by the GlobalCssJs extension). Thus an attacker who compromises an admin account (on some wikis, even a less privileged account such as templateeditor on hewiki) can deploy malicious Javascript to all visitors.
The ability of wiki communities to shape wikis to their liking by deploying custom Javascript is an important tool for increasing power user productivity and empowering communities to solve their problems; as such, it is desirable even with this risk. The way access to this right is currently given is suboptimal though:
- Most administrators have no Javascript editing skills, and as such there is very little benefit in them having that right. (Maybe faster revert time in case of an attack, but even that is highly questionable.)
- Administrators who lack computer skills not only don't need Javascript editing abilities but are extra dangerous attack vectors as they often have weaker password and antivirus practices, don't keep their systems up to date etc.
- With Javascript editing being just one of the many rights administrators have, most communities do not fully understand its dangers and are not sufficiently careful about assigning it. E.g. relatively low-trust user groups sometimes get (that resulted in T189665 recently), no one is worried about long-inactive admins retaining their privileges, there is very little oversight of small wikis with few active admins etc.
The obvious solution for this is to split Javascript editing into a separate, dedicated user group, take away the right from all other user groups (sysop, interface-editor/engineer/templateeditor on some wikis), clearly document the risks of handing out that user group, and set higher expectations for membership (e.g. use of two-factor authentication). There is some paranoia around this issue (some people an attempt to revive Superprotect behind anything that changes Javascript editing workflows) but it is unlikely that many editors will be concerned as long as it is made clear that the power to assign Javascript editing capabilities is left with the local communities. Local bureaucrats would be able to add and remove users, and current admins (or interface editors where that right exists) could be grandfathered in if they want to.
Patches:
- core: 421121 - create editsitecss/editsitejs rights which are needed in combination with editinterface to edit the given type of MediaWiki page (T120886: Make javascript editing permissions more fine grained and separate from normal editinterface right); create new group techadmin which has these rights; take away editusercss/edituserjs from sysop group
- WMF config: 421122, 421123, 440676, 421124, 421125 - support migration process, prevent non-techadmin groups from being able to grant the new rights
(Draft) community consultation page: User:Tgr/Create separate user group for editing sitewide CSS/JS
(Draft) user group info page: User:Tgr/Technical_administrator
Affected Wikimedia user groups:
- sysop
- user (donatewiki, foundationwiki)
- securepoll (officewiki)
- electcomm/staffsupport/electionadmin (votewiki)
- centralnoticeadmin (metawiki, testwiki)
- botadmin (frwiktionary, mlwiki, mlwikisource, mlwiktionary)
- engineer (ruwiki)
- interface-editor (azbwiki, ckbwiki, elwiktionary, hewiki, huwiki, jawiki, pswiki, ptwiki, trwiki, urwiki)
- templateeditor (fawiki, rowiki)
- translator (incubatorwiki)
- wikidata-staff (wikidata)
Sitewide CSS/JS editing not covered by the patch:
- Raw HTML messages (T2212: Some MediaWiki: messages not safe in HTML (tracking)), editable with editinterface, Translatewiki.net access or by sneaking an i18n patch through code review (see T45646/T200997 for a partial solution)
- Pages not in the MediaWiki/User namespace which are loaded by another script (via importScript or similar) - see {T113042} and T171563: Only allow MediaWiki, Gadget, and User namespace pages to be treated as JS or CSS (no project namespace, etc.)
- Gadgets after T31272: Implement Gadgets 2.0 (will move gadgets out of the MediaWiki namespace and use gadgets-edit and maybe gadgets-definition-edit rights instead; we might want to have rights separation between global and personal gadgets).
- Javascript in CentralNotice banners (T202244: CentralNotice provides a means for non interface-admins to bypass new CSS/JS restrictions)
- Import does not do any per-page permission checks
Related issues:
- T71445: Implement a proper code-review process for MediaWiki JS/CSS pages on Wikimedia sites
- {T190019}
- {T186392}
Follow-ups: