Creazione di un gruppo separato di utenti per editare CSS/JS comune

Tracked in Phabricator:
Task T190015

Il problema

Gli amministratori hanno un potere estremamente pericoloso: modificando pagine come Common.js possono eseguire immediatamente codice sulle macchine dei nostri milioni di lettori e migliaia di editor. (Lo stesso vale per altri gruppi di utenti con privilegi analoghi, come gli editor dell'interfaccia). Mentre questo è ampiamente noto, poche persone capiscono quanti danni possono essere fatti se usato impropriamente:

• Inviando codice malevolo a chi legge o modifica, uno può praticamente fare qualsiasi cosa: ottenere password o numeri di carte di credito, reindirizzare le donazioni, rivelare la vera identità degli utenti, effettuare modifiche a nome di un altro, indurre con l'inganno a installare software malevolo, inviare spam, organizzare attacchi DDoS contro siti web altrui...
• A differenza di altri poteri pericolosi (per esempio, i checkuser) che non possono essere monetizzati, questo è un bersaglio redditizio per un utente ostile. Abbiamo recentemente veduto qualcuno abusare dei suoi privilegi per eseguire programmi di mining di criptovaluta nelle macchine dei visitatori; e ci sono attività molto peggiori che sono attraenti per un malintenzionato in cerca di facili guadagni.
• Il danno non è limitato a un singolo wiki: a causa dell'adozione del login globale per i singoli utenti, un exploit su un wiki può essere usato per usupare account di amministratori su qualunque altro wiki per estendere ulteriormente l'attacco.

In questo modo amministratori allo sbaraglio e hackers che sottraggano credenziali di amministratori costituiscono una seria minaccia, e noi dovremmo fare il possibile per ridurla. È un piccolo miracolo che nessun incidente di rilievo sia accaduto finora, anche se credenziali di amministratori sono rubate regolarmente; abbiamo bisogno di ridurre al nostra confidenza nei miracoli.

Allo stesso tempo, la capacità delle comunità WikiMedia di sagomare il funzionamento dei propri siti è estremamente preziosa e dovrebbe essere protetta. Gli strumenti a disposizione degli utenti fruttano enormi aumenti di produttività; le modifiche all'interfaccia di lettura possono adattare la wiki all'ampia varietà di problemi e soluzioni di uso già sperimentate nelle centinaia di wiki Wikimedia, che un processo di sviluppo centralizzato non avrebbe speranza di replicare; la capacità di risolvere problemi localmente invece di affidarsi a un aiuto esterno è un'importante fonte di potenziamento e motivazione per una comunità wiki. Il controllo dell'ambiente CSS/JS locale dovrebbe rimanere nelle mani della comunità locale.

La soluzione

La maggior parte degli amministratori non vuole o non ha la necessità di modificare CSS e JavaScript. In primo luogo, ciò richiede la conoscenza di quei linguaggi, che la maggior parte degli amministratori non ha. Le persone che già modificano il codice JavaScript e CSS (o che vogliono iniziare a farlo) non dovrebbero essere impedite, ma gli amministratori che non se ne preoccupano non dovrebbero averne il diritto, così che un utente malintenzionato che gli rubi le credenziali non possa fare danni. Inoltre, le comunità che desiderano gestire gli editor JS a un livello di controllo superiore rispetto agli amministratori (in genere è una cosa saggia da fare) dovrebbero ricevere sostegno dal software wiki.

Per facilitare questo, sarà creato un nuovo gruppo utente denominato operatore tecnico e solamente utenti di questo gruppo potranno modificare le pagine CSS e JS del sito. I burocrati e gli steward potranno autorizzare gli utenti, della stessa maniera che con gli amministratori. Rimarrà a discrezione di ogni comunità locale la modalità di scelta dei nuovi operatori tecnici (o della comunità globale di Wikimedia se questa comunità crea una politica globale mediante la procedura abituale).

Questo produrrà diversi benefici:

• Il numero di utenze che possano essere sfruttate per compromettere il sito sarà drasticamente ridotto. Meno utenti che possano costituire un vettore di attacco significa una probabilità minore che un'utenza diventi vulnerabile quando il database delle password di un sito terzo venga compromesso. (Questo significa anche che i normali amministratori devono preoccuparsi di meno di diventare bersaglio di un furto di credenziali). Meno utenze sono più facili da tenere sotto controllo in caso di accessi sospetti.
• Oltre il semplice numero di utenze, eliminerà le utenze più passibili di essere vettori di un attacco. Gli utenti che possano scrivere codice CSS e JS generalmente hanno migliori abilità in tecnologie dell'informazione, e perciò hanno migliori password e pratica di sicurezza informatica.
• In futuro potremo porre requisiti di sicurezza più stringenti per gli editor CSS/JS, (ad esempio l'autenticazione a due fattori) senz aimplicare tutti gli altri amministratori il cui furto di identità non prospetterebbe un pericolo altrettanto grande.

A livello tecnico: un nuovo insieme di autorizzazioni (editsitecss e editsitejs); sarà introdotto in MediaWiki; per modificare una pagina .css o .js nel namespace MediaWiki sarà necessario tanto il precedente accesso editinterface quanto l'accesso corrispondente editsiteXXX. Gli amministratori e altri gruppi di utenti che attualmente hanno editinterface riceveranno le nuove autorizzazioni durante un breve periodo di migrazione (in modo che la transizione possa avere luogo senza nessun disturbo) ma alla fine non lo manterranno, e il software assicurerà di che nessun un altro gruppo di utenti a parte degli amministratori tecnici possa averlo.

Come puoi aiutare

• Al termine di questa consultazione, ci sarà un periodo di migrazione (probabilmente di due settimane) in cui il gruppo di utenti amministratori dell'interfaccia esisterà ma gli amministratori saranno comunque in grado di modificare i CSS/JS. Assicurati che la tua comunità ne sia consapevole in modo che possa aggiungere persone al gruppo degli amministratori dell'interfaccia in quel periodo, e che abbia un processo per decidere chi viene aggiunto. Il processo di migrazione dovrebbe essere lasciato a ogni comunità locale; potrebbe essere semplice come aggiungere ogni amministratore che lo richiedesse.
• Inoltre, assicurati che la tua wiki abbia della documentazione e un processo di elezione per il nuovo gruppo dopo il periodo di migrazione. Ancora una volta, questo potrebbe essere semplice come chiedere agli amministratori neo eletti se vogliono anche essere amministratori dell'interfaccia e se hanno familiarità con Javascript e le pratiche di sicurezza di base. In ogni caso, si raccomanda di rendere i requisiti per gli amministratori dell'interfaccia almeno altrettanto alti di quelli per gli amministratori (in termini di fiducia e comportamento dell'utente), e forse anche più alti (vedere la pagina gruppo utenti per maggiori consigli).
• Raccontaci dei processi di editing CSS/JavaScript che richiedono permessi aggiuntivi (questo sarà utile per decidere quali diritti il gruppo di amministratori dell'interfaccia dovrebbe avere per impostazione predefinita). Ad esempio, gli amministratori dell'interfaccia devono essere in grado di eliminare le pagine o modificare il modello di contenuto?
• Suggerisci un nome migliore per il gruppo! "Amministratori dell'interfaccia" non è grande. Cose da tenere in considerazione: i membri del gruppo non devono essere confusi con gli sviluppatori che mantengono il codice sorgente off-wiki (sviluppatori MediaWiki, manutentori di Toolforge, ecc.); non devono essere confusi con le persone che lavorano sul codice Lua (il Module namespace); ci sarà ancora un gruppo modificatori di interfaccia (per la modifica dei messaggi MediaWiki); idealmente, il nome dovrebbe esprimere il fatto che questo ruolo richiede almeno la stessa fiducia di un amministratore.
• Se noti qualche problema non anticipato in questa pagina, o ci sono ulteriori cambiamenti che renderebbero il cambiamento più utile / meno oneroso, per favore faccelo sapere!

Per favore usa la pagina di discussione per feedback. Puoi scrivere in qualsiasi lingua.

Domande frequenti

Chi c'è dietro questo documento?

Questa pagina e il codice corrispondente sono stati scritti da User:Tgr (in qualità di volontario). Basata sulla discussione in T190015 e su wikitech-l, credo che abbia il consenso della comunità di sviluppatori di MediaWiki.

Questa è una Richiesta di Commenti?

Non nel senso che il cambiamento sarebbe stato fatto o non sarebbe stato fatto sulla base del consenso della comunità. Non è una votazione. Le decisioni sulla sicurezza del software sono governate dal consenso della comunità di sviluppatori MediaWiki, piuttosto che dal consenso degli utenti; la decisione finale sarà presa attraverso la revisione del codice, come al solito. Detto questo, il tuo feedback è molto apprezzato! La discussione potrebbe far emergere ragioni per fare le cose in modo diverso da quanto suggerito qui, o potrebbe determinare dettagli importanti, come quali altri permessi il nuovo gruppo di utenti dovrebbe ottenere. Può anche aiutare le comunità ad affrontare questo cambiamento del software nelle loro politiche e procedure.

Questa è una risposta impulsiva ai recenti incidenti?

No. Benché spero che abbiano messo in luce l'importanza di questo cambiamento, l'idea è stata discussa per anni e la patch specifica su cui si basa questa consultazione è stata scritta a marzo.

Anche se ciò dovesse accadere, ci saranno ancora alcuni modi per gli amministratori di implementare il JS in tutto il sito.

Si tratta di un (grave) problema tecnico che alla fine verrà risolto. Tuttavia, limitare la capacità di editing JS degli amministratori a pochi hack oscuri e non molto noti riduce significativamente la possibilità di attacco e rende molto più facile il monitoraggio delle vulnerabilità rimanenti.

Perché l'editing CSS è trattato allo stesso modo di quello JS?

Benché CSS sia meno pericoloso di JS, può essere ancora piuttosto dannoso:

• Le proprietà CSS relative alle immagini possono essere utilizzate per identificare gli utenti.
• In alcuni browser più vecchi, è possibile incorporare il codice JS all'interno del CSS.
• I CSS possono essere usati per rubare edit tokens (e quindi modificare con un altro nome utente e con suoi privilegi), anche se per ora questo è limitato dalla mancanza di supporto per il browser.
• È possibile utilizzare clickjacking basato su CSS per configurare attacchi di phishing.

I dati mostrano che quasi tutti gli amministratori che modificano regolarmente i CSS modificano anche i JS, quindi non c'è motivo per non trattare i due problemi insieme.

In futuro, la possibilità di modificare un sottoinsieme di CSS sanitizzato e sicuro potrebbe essere reintrodotta; si veda il progetto TemplateStyles per il lavoro in corso su questo aspetto.

Questo avrà effetti anche sulle pagine .css di TemplateStyles?

No, soltanto le pagine CSS nel namespace MediaWiki. Il codice CSS di emplateStyles è automaticamente ripulito per garantire che non possa essere utilizzato per nulla di pericoloso.

Perché non lavorare invece per impedire automaticamente agli utenti con la possibilità di modificare JavaScript dal fare qualcosa di male?

Anche se ci sono dei progressi da fare su questo fronte (come CSP e una qualche forma di revisione delle modifiche), non si riuscirà mai a prevenire completamente gli attacchi, non è possibile sanificare un linguaggio di programmazione. Inoltre, sono molto più complesse e richiedono uno sforzo molto maggiore. A breve termine, ridurre il numero di account che possono modificare i JavaScript è di gran lunga la strategia di riduzione più fattibile; a lungo termine, dovrebbe essere fatto sempre insieme agli altre strategie.

E per quanto riguarda i permessi editusercss/edituserjs?

Queste permessi (poco conosciuti e usati molto raramente) permettono la modifica di CSS/JS personali di un altro utente. Poiché questo permette di rubare l'account dell'utente desiderato, valgono le stesse considerazioni e questi permessi saranno limitati allo stesso modo (a lungo termine, vedere T197087).

Che dire della nuova autorizzazione editsitejson?

Serve per modificare le pagine .json nel namespace MediaWiki (qualcosa che il software ha recentemente imparato a gestire in modo speciale, inteso come pagine di configurazione per gadget e bot).JSON sono dati, non codice, quindi modificarli non è considerato pericoloso e gli amministratori saranno comunque in grado di farlo; i gadget dovrebbero essere scritti in modo tale che un attaccante che possa controllare le pagine .json non dovrebbe essere in grado di comprometterli.