Nhóm người dùng mới để sửa trang CSS/JS toàn cục
Thảo luận này cho đến thứ hai, 23 tháng 7 năm 2018. Thời gian cài đặt vào 30 tháng 7 đến 27 tháng 8.
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.
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:
- Số tài khoản có thể sử dụng những trang đó sẽ giảm đáng kể.
- 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 (
editsitejs) is being introduced to MediaWiki; to edit a
.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.
Giúp bằng cách nào
- 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.)
- 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.
Những câu hỏi thường gặp
- Ai đằng sau văn bản này?
- 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.
- 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
- No, only CSS pages in the MediaWiki namespace. TemplateStyles CSS code is automatically sanitized to ensure it cannot be used for anything dangerous.
- What about the
- 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
- That is for editing
.jsonpages 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
.jsonpages should not be able to compromise them.