Creación dun grupo de usuarios separado para editar CSS e JS que afecta a todo un proxecto wiki

Tracked in Phabricator:
Task T190015

O problema

Os administradores teñen un poder sumamente perigoso: ó editar páxinas como Common.js poden inmediatamente executar código nos dispositivos dos nosos millóns de lectores e miles de editores (o mesmo aplica para outros grupos de usuarios con privilexios do mesmo nivel como os editores da interface). Se ben isto é coñecido amplamente, poucas persoas comprenden canto dano se pode facer se isto é mal utilizado:

• Ó enviar código maligno ós lectores ou editores, un pode basicamente facer calquera cousa: obter contrasinais ou números de tarxetas de crédito, redirixir as doazóns, rastrexar a identidade dos editores, facer edicións en nome doutro editor, enganar ás persoas para instalar software maligno, enviar publicidade, instrumentar un ataque de denegación de servizo en prexuízo de sitios web de terceiros...
• A diferenza doutros permisos perigosos (por exemplo, os verificadores de usuarios) que non poden ser monetizados, este é un branco lucrativo para un atacante. Recentemente temos visto a algún usuario abusar dos seus privilexios para executar programas de minaría de criptomoedas nos dispositivos dos visitantes; e hai cousas máis graves que son atractivas para un atacante que procures uns ingresos doados.
• O dano non se limita a un só wiki: debido a que as wikis de Wikimedia usan todas un sistema global de usuario unificado, un software maligno nun wiki podería usarse para tomar o control de contas de administrador en calquera outro wiki e estender aínda máis o ataque.

Por iso, administradores deshonestos e hackers que rouban contas con permiso de administrador supoñen unha ameaza seria e deberíamos facer o posible para reducir esta ameaza. É un pequeno milagre que ata agora non houbese un incidente importante, aínda que contas con permiso de administrador son roubadas regularmente; necesitamos reducir a nosa dependencia dos milagres.

Ó mesmo tempo, a capacidade das comunidades Wikimedia de dar forma ó funcionamento dos seus sitios é sumamente valiosa e debería preservarse. Os accesorios dispoñibles para os editores proporcionan incrementos importantes na produtividade; as modificacións de cara ó lector poden adaptar a wiki a unha variedade ampla de problemas e casos de uso nos centos de wikis de Wikimedia, que un proceso de desenvolvemento centralizado non tería posibilidades de reproducir; e ser capaz de resolver problemas localmente en vez de depender de axuda externa é unha fonte importante de potenciación emotivación para unha wikicomunidade. O control da contorna CSS e JS debería deixarse en mans da comunidade local.

A solución

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.

How you can help

• 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.

FAQ

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.