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 75% complete.

Outdated translations are marked like this.
Other languages:
Ελληνικά • ‎English • ‎español • ‎français • ‎galego • ‎עברית • ‎magyar • ‎italiano • ‎日本語 • ‎한국어 • ‎মেইতেই লোন্ • ‎Nederlands • ‎polski • ‎português do Brasil • ‎русский • ‎Türkçe • ‎українська • ‎ייִדיש • ‎中文
Nutshell.png
This page in a nutshell: Om veiligheid en privavy van lezers en redacteuren te garanderen, is het vereist de mogelijkheid om sitebrede code te bewerken stringenter te beheren. Aan de andere kant is de vaardigheid van Wikimediagemeenschappen om hun werkklimaat vorm te geven een levensvatbare bron van kracht en vernieuwing. Om deze beide eisen beter te vervullen zullen we CSS/JS-bewerkingen beperken tot moderatoren die ze willen en nodig hebben. De plaayselijke redactiegemeenschap zal beslissen wie dat zijn.

Probleem

Moderatoren hebben een bijzonder gevaarlijke macht: door veranderen van pagina's als Common.js kunnen ze in een oogwenk code uitvoeren op de apparaten van onze miljoenen lezers en duizenden collega's. (hetzelfde geldt voor andere gebruikersgroepen met vergelijkbare voorrechten zoals interfacebewerkers.) Hoewel dit wijd en zijd bekend is, snappen weinigen hoe erg misbruik ervan kan uitpakken.

  • Door kwaadaardige code naar lezers/collega's te sturen kan men eigenlijk alles doen: wachtwoorden of creditcardnummers opvangen, schenkingen omleiden, anoniemen aangemeld laten zijn, bewerkingen op naam van iemand anders doen, mensen malware laten installeren, spam verzenden en DDoS-aanvallen tegen derden in gang zetten...
  • In tegenstelling tot andere gevaarlijke machten (bijv. checkusers die geen geld opleveren, is dit lucratief voor een aanvaller. Recentelijk zagen we iemand zijn rechten misbruiken om cryptomuntzoekers op bezoekersmachines te exploiteren; er zijn veel kwalijker zaken aantrekkelijk voor enig aanvaller op zoek naar gemakkelijke bijverdiensten.
  • De schade blijft niet beperkt tot een ekele wiki: wegens het feit dat Wikimediawiki's alle een iniverseel aanmeldsysteem hanteren, kan een procedure op één wiki ingezet worden om moderatorregistraties op om het even welke andere wiki over te nemen en de aanval verder te verspreiden.

Zodoende leveren schurkenmods en hackers een serieuze bedreiging op en zouden we alles moeten doen om dit binnen de perken te houden. Het mag een wondertje genoemd worden dat zich tot op heden geen catastrofe heeft voorgedaan, terwijl modaccounts geregeld zijn gekaapt: we dienen minder blind te varen op wonderen.

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.

Oplossing

De meeste moderatoren willen de mogelijkheid om cascading stylesheets en Javascript te schrijven niet noch hebben ze dat nodug. Op de eerste plaats vereist dat kennis van voornoemde talen die de meeste beheerders ontberen. Mensen die reeds sitebrede Javascript en/of CSS (of daarmee willen beginnen) coderen, zouden niet belemmerd moeten worden, maar mods die het geen moer uitmaakt zou dat recht ontnomen moeten worden, opdat een kaper met hun account geen kwaad kan aanrichten. Tevens zou de wikiprogrammatuur gemeenschappen die JS-codering naar een hoger niveau te tillen of beter onderzoeken dan moderatoren (wat altijd verstandig is) moeten bijstaan.

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

Dit zal verscheidene voordelen bieden:

  • 't Aantal accounts dat gebruikt kan worden om de site te beschadigen loopt drastisch terug.[1] Minder accounts die als aanvalswapen fungeren verkleint de kans op kwetsbaarheid wanneer de wachtwoordendatabase of wat sites van derden zijn gekraakt. (Het houdt ook in dat gewone beheerders zich minder zorgen hoeven te maken slachtoffer te worden van accountkaping.) Minder accounts zijn ook gemakkelijker in de gaten te houden voor verdachte aanmeldingen.
  • 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 de toekomst stellen we hogere beveiligingseisen aan CSS/JS-codeurs (zoals de eis om tweeledige authorisatie toe te passen) zonder alle andere mods wier gehackte accounts niet zoveel kwaad kan.

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 geholpen kan worden

  • 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" bekt niet lekker. Om in aanmerking te nemen: verwar groepsleden niet met ontwikkelaars die die buitenwiki broncode (MediaWiki-ontwikkelaars, Toolforge-instrumentmonteurs enz.) onderhouden; evenmin met mensen die Lua (Module-naamruimte) coderen; d'r zal toch een interfaceredacteursgroep (om MediaWikimeldingen te vervaardigen) lijven; idealiter geeft de naam aan dat die rol minstens zoveel betrouwbaarheid opeist als die van 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.

Vaak gestelde 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 het overleg in T190015 en op wikitech-l. Men gelooft dat er consensus is bij de MediaWiki-ontwikkelclub.
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 klip-en-klaar antwoord op recente incidenten?
Nee. Hoewel ik hoop dat ze het belang van deze verandering - het idee ligt al jaren op de discussietafel - en de patch waar deze raadpleging over gaat, toelichten was in maart geschreven.
Mocht dit gebeuren zullen beheerders og steeds middelen hebben om sitebrede Javascript te implementeren.
Dat is een (zeer) technisch euvel waarmee we eventueel aan de slag gaan. Niettemin reduceert het terugdringen van JS-codering door moderatoren tot een paar obscure en minder bekende lekdichtingen danig het aanvalsoppervlak en maakt het bespieden van overgebleven kwetsbaarheden simpeler.
Waarom krijgen Cascading style sheets en Javascript gelijke behandeling?
Hoewel Cascading styleSheets onschuldiger zijn dan Javascript zijn ze aardig geniepig:
  • Met bestandsgerelateerde CSS-eigenschappen kunnen anonieme gebruikers zich als aangemeld voordoen.
  • In sommige oudere browser(versie)s kan Javascript binnen CSS meegebakken worden.
  • CSS kan men voor bewerkingsvlaggenkaping (zo doende bewerkingen met bijbehorende rechten uitvoeren alsof een ander zijn gepleegd) inzetten, hoewel dit nu is afgevangen door gebrek aan browserondersteuning.
  • Op CSS gebaseerde clickjacking houdt een een risico op (grootscheepse) phishing in.
Gegevens tonen [2] dat vrijwel alle beheerders die geregeld CSS-scripts schrijven, zich ook met .js bezighouden, derhalve is er wat voor te zeggen de twee problemen samen op te pakken.
In de toekomst wordt de bewerkingsmogelijkheid gesaneerd, waarbij een uitgekleed CSS-pakket opnieuw van stal gehaald wordt; hou het SjabloonStijlenProject in de smiezen.
Heeft dit ook consequenties voor de pagina's van SjabloonStijlen .css?
Nee, slechts VSS-pagina's in de naamruimte MediaWiki. SjabloonStijlenCSS-code is automatisch gesaneerd, zodat riskant misbruik vrijwel is uitgesloten.
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 dat met toestaan van editusercss/edituserjs?
Deze (nauwelijks bekende en hoogstzelden toegepaste) rechten staan bewerkingen op persoonlijke .css/.js van anderen toe. Daar dit de deur openzet met het doelgebruikersaccount aan de haal te gaan, zijn dezelfde overwegingen van toepassing en gelden voor dit voorrechten gelijke beperkingen. (Voor de lange duur: zie T197087.)
En de nieuwe editsitejson permissie?
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.

Bronnen, noten en/of referenties

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