Sitewide CSS/JS'yi düzenlemek için ayrı kullanıcı grubunun oluşturulması

Tracked in Phabricator:
Task T190015

Sorun

Administrators have an extremely dangerous power: by editing pages such as Common.js they can instantly execute code on the machines of our millions of readers and thousands of editors. (The same goes for other user groups with comparable privileges, such as interface-editors.) While this is widely known, few people understand how badly this can be misused:

• By sending malicious code to readers/editors, one can basically do anything: phish passwords or credit card numbers, redirect donations, deanonymize editors, make edits in another editors' name, trick people into installing malware, send spam, orchestrate DDoS attacks against third-party sites...
• Unlike other dangerous powers (e.g. checkuser) which cannot be monetized, this is a lucrative target for an attacker. Recently we have seen someone abuse their privileges to run cryptocoin miners on visitors' machines; there are far worse things that are attractive to any attacker looking for some easy income.
• The damage is not limited to a single wiki: due to Wikimedia wikis all using a single global login system, an exploit on one wiki can be used to take over admin accounts on any other wiki and extend the attack further.

Thus, rogue admins and hackers stealing admin accounts present a serious threat, and we should do what we can to reduce it. It's a small miracle no major incident has happened so far, even though admin accounts are stolen regularly; we need to reduce our reliance on miracles.

At the same time, Wikimedia communities' ability to shape the workings of their sites is extremely valuable and should be preserved. Editor-facing gadgets give huge productivity boosts; reader-facing modifications can adapt the wiki to the wide variety of problems and use cases on the hundreds of Wikimedia wikis, which a centralized development process would have no hope of replicating; being able to solve problems locally instead of having to rely on external help is an important source of empowerment and motivation for a wiki community. The control of the local CSS/JS environment should be left with the local community.

Çözüm

Most administrators do not actually want or need the ability to edit CSS and JavaScript. In the first place, that requires the knowledge of those languages, which most admins lack. People who already edit sitewide JavaScript and CSS code (or want to start doing it) should not be prevented, but admins who don't care about it should not have the right, so that an attacker stealing their account can do no harm. Also, communities who want to vet JS editors at a higher level or scrutiny than admins (which is generally a wise thing to do) should be supported by the wiki software.

To facilitate this, a new interface administrators user group will be created, and only users in this group will be able to edit sitewide CSS/JS pages. By default, bureaucrats and stewards will be able to grant group membership to users, the same way it works with admins. How to appoint new interface administrators will be left at the discretion of each local community (or the global Wikimedia community if that community creates a global policy through the usual means).

This will have several benefits:

• The number of accounts which can be used to compromise the site will be drastically reduced. Fewer accounts that can serve as attack vectors means a smaller chance of an account being vulnerable when the password database of some third-party website gets compromised. (It also means normal administrators need to worry less about becoming targets of account theft.) A smaller number of accounts is also easier to monitor for suspicious logins.
• Beyond the mere numbers of accounts, it will remove the most vulnerable accounts as attack vectors. Users who can write CSS/JS code typically have better IT skills in general, and thus better password and system security practices.
• In the future, we can set higher security requirements for CSS/JS editors (such as requiring two-factor authentication) without inconveniencing all the other admins whose account compromise wouldn't pose as big a danger.

On a technical level: a new set of permissions (editsitecss and editsitejs) is being introduced to MediaWiki; to edit a .css or .js page in the MediaWiki namespace, both the old editinterface permission and the corresponding editsiteXXX permission will be needed. Admins and other user groups who currently have editinterface will receive the new rights for a short migration period (so that the transition can happen without any disruption) but eventually won't have them, and the software will enforce that no other groups than interface admins can have it.

Nasıl yardımcı olabilirsiniz

• After this consultation ends, there will be a migration period (probably two weeks) in which the interface administrator user group will exist but normal administrators will still be able to edit CSS/JS. Please make sure your community is aware of this so they can add people to the interface administrator group during that time, and have a process for deciding who gets added. (What that migration process should be is left to each local community; it could be as simple as adding every administrator who asks for it.)
• Also, please make sure your wiki has some documentation and election process for the new group past the migration period. Again, this could be as simple as asking newly elected administrators whether they also want to be interface administrators and whether they are familiar with Javascript and basic security practices. In any case, it is recommended to make the bar for interface admins at least as high as for admins (in terms of trust and user behavior), and maybe even higher (see the user group page for more advice).
• Tell us about CSS/JavaScript editing workflows that require extra permissions (this will be helpful in deciding what rights the interface administrator group should have by default). For example, do interface administrators need to be able to delete pages, or change the content model?
• Suggest a better group name! "Interface administrators" is not great. Things to take into account: groups members should not be confused with developers who maintain off-wiki source code (MediaWiki developers, Toolforge tool maintainers etc.); they should not be confused with people working on Lua code (the Module namespace); there will still be an interface-editor group (for editing MediaWiki messages); ideally, the name should express that this role requires at least as much trust as being an administrator.
• If you see any problems not anticipated in this document, or there are additional changes which would make the change more useful / less burdensome, please tell us about it!

Please use the talk page for feedback. You can write in any language.

SSS

Who is behind this document?

This page and the corresponding code change was written by User:Tgr (in a volunteer capacity). Based on the discussion in T190015 and on wikitech-l, I believe it has the consensus of the MediaWiki developer community.

Is this an RfC?

Not in the sense that the change would be done or not done based on community consensus. This is not a vote. Software security decisions are governed by the consensus of the MediaWiki developer community, rather than the consensus of editors; the final decision will be made via code review, as usual. That said, your feedback is very much wanted! The discussion might uncover reasons for doing things differently than suggested here, or it might decide on important details, such as what other permissions the new user group should get. It may also help communities address this software change in their policies and procedures.

Is this a kneejerk response to the recent incidents?

No. While I hope they have highlighted the importance of this change, the idea has been discussed for years, and the specific patch which this consultation is about was written in March.

Even if this happens, there will still be some ways for administrators to deploy sitewide JS.

That's a (hard) technical problem that will eventually be dealt with. Nevertheless, limiting the JS-editing ability of administrators to a few obscure and not-widely-known hacks significantly reduces the attack surface, and makes the remaining vulnerabilities much easier to monitor.

Why is CSS editing treated the same way as JS editing?

While CSS is less dangerous than JS it is still pretty bad:

• Image-related CSS properties can be used to deanonymize editors.
• In some older browsers, JavaScript code can be embedded in CSS.
• CSS can be used to steal edit tokens (and thus make edits in another user's name and with their privileges), although for now this is limited by lack of browser support.
• CSS-based clickjacking can be used to set up phishing attacks.

Data shows that almost all admins who regularly edit CSS edit JS as well, so there is no reason not to treat the two problems together.

In the future, the ability to edit a sanitized, safe subset of CSS might be reintroduced; watch the TemplateStyles project for work in progress on that front.

Does this also affect TemplateStyles .css pages?

No, only CSS pages in the MediaWiki namespace. TemplateStyles CSS code is automatically sanitized to ensure it cannot be used for anything dangerous.

Why not work instead on automatically preventing users with the ability of editing JavaScript from doing anything bad?

While there are advances to be had on that front (such as CSP and some form of edit review), they will never be able to fully prevent attacks – it is just not possible to sanitize a programming language. Also, they are much more complex and require far more effort. In the short term, reducing the number of accounts who can edit JavaScript is by far the most feasible mitigation strategy; in the long term, it should still be done alongside the others.

What about the editusercss/edituserjs permissions?

These (little known and very rarely used) permissions allow the editing of another user's personal CSS/JS. Since that allows stealing the target user's account, the same considerations apply and these permissions will be restricted the same way. (In the longer term, see T197087.)

What about the new editsitejson permission?

That is for editing .json pages in the MediaWiki namespace (something the software has recently learned to handle specially, meant as configuration pages for gadgets and bots). JSON is data, not code, so editing it is not considered dangerous and admins will still be able to do it; gadgets should be written in such a way that an attacker who can control .json pages should not be able to compromise them.