Aanmaak van een aparte gebruikersgroep om sitebrede CSS/JS te bewerken

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search
This page is a translated version of the page Creation of separate user group for editing sitewide CSS/JS and the translation is 83% complete.

Other languages:
English • ‎Nederlands • ‎Tiếng Việt • ‎Türkçe • ‎español • ‎français • ‎galego • ‎italiano • ‎magyar • ‎polski • ‎português • ‎português do Brasil • ‎Ελληνικά • ‎русский • ‎українська • ‎ייִדיש • ‎עברית • ‎العربية • ‎مصرى • ‎মেইতেই লোন্ • ‎中文 • ‎日本語 • ‎한국어
Nutshell.png
This page in a nutshell: Om de veiligheid en privacy van onze lezers en redacteuren te garanderen, is een strikter toezicht op de mogelijkheid om sitebrede code te bewerken noodzakelijk. Aan de andere kant is de vaardigheid van Wikimedia-gemeenschappen om hun werkomgeving vorm te geven een essentiële bron van empowerment en vernieuwing. Om aan beide vereisten te voldoen, zullen we het bewerken van CSS/JS beperken tot de moderatoren die het willen en nodig hebben. De plaatselijke redactiegemeenschap zal beslissen wie dat zijn.

Het probleem

Moderatoren hebben een bijzonder gevaarlijke bevoegdheid: door pagina's zoals Common.js te bewerken, kunnen ze in een oogwenk code uitvoeren op de apparaten van onze miljoenen lezers en duizenden redacteuren. (Hetzelfde geldt voor andere gebruikersgroepen met vergelijkbare rechten, zoals interfacebewerkers.) Hoewel dit algemeen bekend is, begrijpen maar weinig mensen hoe erg dit kan worden misbruikt:

  • Door kwaadaardige code naar lezers/redacteuren te sturen, kan men in feite alles doen: wachtwoorden of creditcardnummers opvangen, donaties omleiden, redacteuren ontanonimiseren, bewerkingen op naam van iemand anders doen, mensen misleiden om malware te installeren, spam verzenden, DDoS-aanvallen tegen derden in gang zetten...
  • In tegenstelling tot andere gevaarlijke bevoegdheden (zoals checkuser) die geen geld opleveren, is dit lucratief voor een aanvaller. Recentelijk zagen we iemand zijn rechten misbruiken om cryptocoin-miners op de machines van bezoekers uit te voeren; er zijn veel ergere dingen die aantrekkelijk zijn voor elke aanvaller die op zoek is naar gemakkelijke bijverdiensten.
  • De schade blijft niet beperkt tot een enkele wiki: omdat alle Wikimedia-wiki's een universeel aanmeldsysteem gebruiken, kan een exploit op één wiki worden gebruikt om moderatoraccounts op elke andere wiki over te nemen en de aanval verder uit te breiden.

Zodoende vormen schurkenmoderatoren en hackers die moderatoraccounts stelen een serieuze bedreiging, en we moeten doen wat we kunnen om die te verminderen. Het is een klein wonder dat er tot nu toe geen groot incident is geweest, terwijl moderatoraccounts geregeld zijn gekaapt; we moeten minder afhankelijk van wonderen worden.

Tegelijkertijd is de mogelijkheid van Wikimedia-gemeenschappen om de werking van hun sites vorm te geven uiterst waardevol en moet deze behouden blijven. Bewerker-gerichte uitbreidingen zorgen voor een enorme productiviteitstoename; lezer-gerichte aanpassingen kunnen de wiki afstemmen op de grote verscheidenheid aan problemen en toepassingen op de honderden Wikimedia-wiki's, waar een gecentraliseerd ontwikkelingsproces niet aan kan tippen; het lokaal kunnen oplossen van problemen in plaats van afhankelijk zijn van externe hulp is een belangrijke bron van empowerment en motivatie voor een wikigemeenschap. De controle over de lokale CSS/JS-omgeving moet bij de lokale gemeenschap blijven.

De oplossing

De meeste moderatoren hebben de mogelijkheid om CSS en JavaScript te bewerken eigenlijk niet nodig. Op de eerste plaats vereist het kennis van die talen, die de meeste moderatoren niet hebben. Mensen die reeds sitewide JavaScript en CSS bewerken (of daarmee willen beginnen), moeten niet belemmerd worden, maar moderatoren die er niet om geven zouden het bewerkingsrecht niet moeten hebben, opdat een aanvaller die hun accounts steelt geen kwaad kan aanrichten. Tevens moeten gemeenschappen die JS-bewerkers aan een kritischer toelatingsprocedure dan moderatoren willen onderwerpen (wat over het algemeen verstandig is) worden ondersteund door de wiki-software.

Om dit te faciliteren zal er een nieuwe interfacebeheerders-gebruikersgroep worden aangemaakt, en alleen gebruikers in deze groep zullen in staat zijn om sitewide CSS/JS-pagina's te bewerken. Standaard kunnen bureaucraten en stewards dit groepslidmaatschap toekennen aan gebruikers, op dezelfde manier als moderatorrechten. De procedure voor het aanwijzen van nieuwe interfacebeheerders wordt overgelaten aan de discretie van elke lokale gemeenschap (of de globale Wikimedia-gemeenschap als die gemeenschap op de gebruikelijke manier een globaal beleid maakt).

Dit zal verscheidene voordelen bieden:

  • Het aantal accounts dat gebruikt kan worden om de site in gevaar te brengen, zal drastisch worden verminderd.[1] Minder accounts die als aanvalsvectoren kunnen dienen, betekent een kleinere kans dat een account kwetsbaar is wanneer de wachtwoordendatabase van een website van een derde partij wordt gekraakt. (Het betekent ook dat gewone moderatoren zich minder zorgen hoeven te maken om doelwit te worden van accountdiefstal.) Een kleiner aantal accounts is ook gemakkelijker in de gaten te houden voor verdachte aanmeldingen.
  • Behalve louter het aantal accounts, elimineert het de meest kwetsbare accounts als aanvalsvectoren. Gebruikers die CSS/JS-code kunnen schrijven, hebben over het algemeen betere IT-vaardigheden, en daarmee betere methoden voor wachtwoord- en systeembeveiliging.
  • In de toekomst kunnen we hogere beveiligingsvereisten instellen voor CSS/JS-bewerkers (zoals het vereisen van tweefactor-authenticatie), zonder alle andere moderatoren lastig te vallen van wie een accountdiefstal een minder groot gevaar zou opleveren.

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.

Hoe jij kunt helpen

  • 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?
  • Stel een betere groepsnaam voor! "Interfacemoderatoren" is niet geweldig. Waarmee rekening moet worden gehouden: groepsleden moeten niet verward worden met ontwikkelaars die de off-wiki-broncode bijhouden (MediaWiki-ontwikkelaars, Toolforge-toolbeheerders, enz.); ze moeten niet verward worden met mensen die werken aan Lua-code (de Module-naamruimte); er zal nog steeds een interfacebewerkersgroep zijn (voor het bewerken van MediaWiki-berichten); idealiter geeft de naam aan dat deze rol minstens zoveel vertrouwen vereist als een moderator.
  • 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!

Gebruik alstublieft de overlegpagina voor terugkoppeling.

Veelgestelde vragen

Wie zit er achter dit document?
De originele taalversie van deze pagina en de overeenkomstige codering is geschreven door vrijwilliger Tgr. Op basis van de discussie in T190015 en op wikitech-l wordt uitgegaan van consensus bij de MediaWiki-ontwikkelaarsgemeenschap.
Is dit een verzoek om commentaar?
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 dit een impulsieve reactie op de recente incidenten?
Nee. Hoewel ik hoop dat ze het belang van deze verandering onder de aandacht hebben gebracht, is het idee jarenlang besproken, en de specifieke patch is in maart geschreven.
Zelfs als dit gebeurt, zijn er nog steeds manieren voor beheerders om sitewide JS te implementeren.
Dat is een (moeilijk) technisch probleem dat uiteindelijk zal worden aangepakt. Niettemin reduceert het beperken van de JS-bewerkingscapaciteit van moderatoren tot enkele obscure en niet algemeen bekende hacks het aanvalsrisico aanzienlijk, en maakt het de resterende kwetsbaarheden veel gemakkelijker te controleren.
Waarom wordt het bewerken van CSS op dezelfde manier behandeld als het bewerken van JS?
Hoewel CSS minder gevaarlijk is dan JS, is het nog steeds vrij beroerd:
  • Beeldgerelateerde CSS-eigenschappen kunnen worden gebruikt om bewerkers te ontanonimiseren.
  • In sommige oudere browsers kan JavaScript-code worden ingesloten in CSS.
  • CSS kan worden gebruikt om bewerkingstokens te stelen (en dus bewerkingen te doen in de naam van een andere gebruiker en met diens rechten), hoewel dit voorlopig beperkt wordt door gebrek aan browserondersteuning.
  • Op CSS gebaseerde clickjacking kan worden gebruikt voor phishing-aanvallen.
Uit gegevens blijkt[2] dat vrijwel alle moderatoren die geregeld CSS bewerken ook JS bewerken, dus er is geen reden om de twee problemen niet samen te behandelen.
In de toekomst kan de mogelijkheid om een opgeschoonde, veilige subset van CSS te bewerken opnieuw worden geïntroduceerd; houd het TemplateStyles-project in de gaten voor vorderingen op dat front.
Heeft dit ook invloed op TemplateStyles .css-pagina's?
Nee, slechts CSS-pagina's in de MediaWiki-naamruimte. TemplateStyles CSS-code wordt automatisch opgeschoond zodat deze niet voor iets gevaarlijks kan worden gebruikt.
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.
Hoe zit het met de editusercss/edituserjs-rechten?
Deze (weinig bekende en zeer zelden gebruikte) rechten maken het bewerken van de persoonlijke CSS/JS van een andere gebruiker mogelijk. Aangezien dat het stelen van het account van de doelgebruiker mogelijk maakt, gelden dezelfde overwegingen en worden deze rechten op dezelfde manier beperkt. (Op de langere termijn zie T197087.)
Hoe zit het met het nieuwe editsitejson-recht?
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.

Referenties

  1. Op de vijf grootste wiki's heeft 75% van de moderatoren nooit CSS/JS bewerkt; 92% bijna nooit.
  2. https://phabricator.wikimedia.org/T190015#4193983