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

Tracked in Phabricator:
Task T190015

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

Op technisch niveau: er wordt een nieuwe set rechten (editsitecss en editsitejs) toegevoegd aan de MediaWiki; om een .css of .js pagina te bewerken in de MediaWiki-naamruimte, zijn de oude editinterface en het overeenkomende editsiteXXX recht nodig. Beheerders en andere gebruikersgroepen die nu editinterface hebben krijgen de nieuwe rechten voor een korte migratieperiode (zodat de transitie zonder storing kan verlopen) maar uiteindelijk zullen ze die rechten niet hebben, de software zal afdwingen dat alleen interfacemoderatoren die rechten kunnen hebben.

Hoe jij kunt helpen

• Na afloop van de consultatie is er een migratieperiode (mogelijk twee weken) waarin de interfacemoderator-gebruikersgroep zal bestaan, maar normale beheerders kunnen nog steeds de CSS/JS bewerken. Zorg ervoor dat dit in uw gemeenschap bekend is, zodat die mensen als interfacemoderator kunnen inzetten in die periode, en kunnen besluiten wie dat zijn.
• Zorg er ook voor dat uw wiki documentatie heeft en een verkiezing houdt voordat de nieuwe groep de migratie-fase door is. Dit kan eenvoudig door de gekozen beheerders te vragen of ze ook interfacemoderator willen zijn en of zij vertrouwd zijn met JavaScript en een basiskennis over beveiliging hebben. Het wordt in dat geval aanbevolen de eisen aan interfacemoderator minstens zo hoog te maken als voor moderator (in termen van vertrouwen en gebruikersgedrag), en misschien zelfs wel nog hoger (zie de adviezen op de gebruikersgroep pagina).
• Vertel ons over de CSS/JavaScript bewerkingen die extra rechten vereisen (dat is nodig om te weten welke rechten de groep met interfacemoderatoren standaard moet hebben). Een voorbeeld: moet een interfacemoderator een pagina kunnen verwijderen of een inhoudsmodel kunnen wijzigen?
• Stel een betere groepsnaam voor! "Interfacemoderator" 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 interfacemoderatorengroep zijn (voor het bewerken van MediaWiki-berichten); idealiter geeft de naam aan dat deze rol minstens zoveel vertrouwen vereist als een moderator.
• Indien u een probleem ziet, dat niet in dit document wordt behandeld, of een andere wijziging wilt laten doen om een meer bruikbaar of gemakkelijker document te maken, laat het ons weten!

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?

Niet dat dat dan afhangt van overeenstemming in de gemeenschap. Beslissingen over de beveiliging worden genomen als er overeenstemming is bij de MediaWiki ontwikkelaars, met een uiteindelijk beslissing gebaseerd op een code review, zoals gewoonlijk. Ondanks dat, wij stellen uw feedback op prijs!' Hier zien we misschien inbreng die die het duidelijk maakt waarom sommige dingen op een bepaalde manier worden gedaan. Of zien we dat de nieuwe gebruikersgroep meer rechten nodig heeft. Ook kan het de gemeenschap helpen om de nieuwe gebruikersgroep te verwerken in hun beleid en hun 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 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.

Waarom niet werken aan het automatisch voorkomen dat gebruikers met de mogelijkheid om JavaScript te bewerken iets slecht doen?

Er is met die aanpak wel vooruitgang geboekt (bijvoorbeeld CSP en een vorm van het reviewen van code), maar het is geen aanpak die volledig aanvallen kan voorkomen, het is een programmeertaal. Het is dus meer complex en het vergt veel inzet. Op de korte termijn is het beperken van het aantal gebruikers die JavaScript kunnen bewerken verreweg de de beste uitvoerbare beperkende strategie; op de lange termijn kan het een van de opties zijn.

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?

Dat is voor het bewerken van .json pagina's in de MediaWiki namespace. JSON is data, geen code, het wijzigen wordt niet als gevaarlijk beschouwd en beheerders kunnen het nog doen; gadgets moeten zodanig worden geschreven dat een aanvaller die de .json pagina's kan controleren die niet in gevaar kan brengen.