Criação de grupo de usuários separado para edição de CSS/JS do site

Tracked in Phabricator:
Task T190015

O problema

Administradores têm um poder extremamente perigoso: editando páginas como Common.js eles podem executar instantaneamente códigos nas máquinas de milhões de leitores e milhares de editores. (O mesmo vale para outros grupos de usuários com privilégios semelhantes, como editores de interface.) Embora isso seja amplamente conhecido, poucas pessoas entendem o quanto isso pode ser mal utilizado:

• Ao enviar código malicioso para leitores/editores, basicamente é possível fazer qualquer coisa: senhas phish ou números de cartão de crédito, redirecionar doações, desmineralizar editores, editar edições de outros editores, enganar as pessoas para instalar malware, enviar spam, orquestrar ataques DDoS contra terceiros...
• Ao contrário de outras potências perigosas (por exemplo, verificação de usuário) que não podem ser monetizadas, esse é um alvo lucrativo para um invasor. Recentemente, vimos alguém abusar de seus privilégios para executar mineração de criptochomas nas máquinas dos visitantes; Há coisas muito piores que são atraentes para qualquer atacante que esteja procurando alguma renda fácil.
• O dano não está limitado a um único wiki: devido a Wikimedia usar um único sistema de login global, um exploit em um wiki pode ser usado para assumir contas de administrador em qualquer outro wiki e estender o ataque ainda mais.

Assim, administradores e hackers desonestos que roubam contas de administrador que representam uma séria ameaça, e devemos fazer o possível para reduzi-lo. É um pequeno milagre que nenhum grande incidente tenha acontecido até agora, apesar de contas de administrador serem roubadas regularmente; Precisamos reduzir nossa dependência em milagres.

Ao mesmo tempo, A capacidade das comunidades Wikimedia de moldar o funcionamento de seus sites é extremamente valiosa e deve ser preservada. Os gadgets voltados para editores proporcionam enormes aumentos de produtividade; as modificações voltadas para o leitor podem adaptar o wiki à grande variedade de problemas e casos de uso nas centenas de wikis da Wikimedia, que um processo de desenvolvimento centralizado não teria a menor chance de replicar; ser capaz de resolver problemas localmente, em vez de depender de ajuda externa, é uma fonte importante de capacitação e motivação para uma comunidade wiki. O controle do ambiente CSS/JS local deve ser deixado com a comunidade local.

A solução

A maioria dos administradores realmente não quer ou precisa da capacidade de editar CSS e JavaScript. Em primeiro lugar, isso requer o conhecimento dessas línguas, que a maioria dos administradores não possui. As pessoas que já editam o código JavaScript e CSS em todo o site (ou que desejam começar a fazer isso) não devem ser impedidas, mas os administradores que não se importam com isso não devem ter o direito de impedir que um invasor roube sua conta. Além disso, as comunidades que querem examinar os editores de JS em um nível mais alto ou escrutínio do que os administradores (o que geralmente é uma coisa sensata a fazer) devem ser suportadas pelo software wiki.

Para facilitar isso, um novo grupo de usuários de administradores técnicos será criado e somente os usuários desse grupo poderão editar páginas CSS / JS em todo o site. Por padrão, os burocratas e administradores poderão conceder membros do grupo aos usuários, da mesma forma que funciona com os administradores. Como nomear novos administradores técnicos será deixado a critério de cada comunidade local (ou da comunidade global da Wikimedia se essa comunidade criar uma política global através dos meios usuais).

Isso terá vários benefícios:

• O número de contas que podem ser usadas para comprometer o site será drasticamente reduzido.Menos contas que podem servir como vetores de ataque significam uma menor chance de uma conta ser vulnerável quando o banco de dados de senhas de algum site de terceiros é comprometido. (Isso também significa que os administradores normais precisam se preocupar menos em se tornarem alvos de roubo de conta.) Um número menor de contas também é mais fácil de monitorar para logins suspeitos.
• Além do mero número de contas, ele removerá as contas mais vulneráveis como vetores de ataque. Os usuários que podem escrever códigos CSS/JS normalmente têm melhores habilidades de TI em geral e, portanto, melhores práticas de segurança de senha e sistema.
• No futuro, podemos definir requisitos de segurança mais altos para os editores de CSS/JS (como exigir autenticação de dois fatores) sem incomodar todos os outros administradores cuja conta comprometer não seria um grande perigo.

Em um nível técnico: um novo conjunto de permissões (editsitecss e editsitejs) está sendo apresentado ao MediaWiki; para editar uma página .css ou .js no namespace da MediaWiki, tanto a antiga editinterface quanto o editsiteXXX correspondente > permissão será necessária. Administradores e outros grupos de usuários que atualmente possuem editinterface receberão os novos direitos por um curto período de migração (para que a transição possa acontecer sem qualquer interrupção), mas eventualmente não os terão, e o software aplicará que nenhum outro grupo além de administradores de interface pode ter isso.

Como você pode ajudar

• Depois que essa consulta terminar, haverá um período de migração (provavelmente duas semanas) no qual o grupo de usuários do administrador técnico existirá, mas os administradores normais ainda poderão editar o CSS/JS. Verifique se sua comunidade está ciente disso, para que eles possam adicionar pessoas ao grupo de administradores técnicos durante esse período e ter um processo para decidir quem será adicionado. (O processo de migração deve ser deixado para cada comunidade local; pode ser tão simples quanto adicionar todos os administradores que solicitam isso.)
• Além disso, certifique-se de que seu wiki tenha alguma documentação e processo de eleição para o novo grupo após o período de migração. Novamente, isso pode ser tão simples quanto perguntar aos administradores recém-eleitos se eles também querem ser administradores técnicos e se estão familiarizados com Javascript e práticas básicas de segurança. Em qualquer caso, recomenda-se tornar a barra para administradores técnicos pelo menos tão alta quanto para administradores (em termos de confiança e comportamento do usuário), e talvez ainda maior (veja a página do grupo de usuários para mais conselhos).
• Conte-nos sobre os fluxos de trabalho de edição de CSS/JavaScript que exigem permissões extras (isso será útil para decidir quais direitos o grupo de administradores técnicos deve ter por padrão). Por exemplo, os administradores técnicos precisam poder excluir páginas ou alterar o modelo de conteúdo?
• Sugira um nome de grupo melhor! "Administradores técnicos" não é ótimo. Coisas a ter em conta: membros de grupos não devem ser confundidos com desenvolvedores que mantêm código-fonte off-wiki (desenvolvedores do MediaWiki, mantenedores de ferramentas Toolforge, etc.); eles não devem ser confundidos com pessoas que trabalham no código Lua (o namespace do Módulo); ainda haverá um grupo de editor de interface (para editar mensagens do MediaWiki); idealmente, o nome deve expressar que esse papel requer pelo menos tanta confiança quanto ser um administrador.
• Se você vir algum problema não previsto neste documento, ou se houver alterações adicionais que tornem a mudança mais útil / menos onerosa, informe-nos sobre isso!

Por favor use a página de discussão para feedback. Você pode escrever em qualquer idioma.

FAQ

Quem está por trás deste documento?

Esta página e a mudança de código correspondente foi escrita por User:Tgr (em capacidade de voluntário). Baseado na discussão em T190015 e em wikitech-l, acredito que tenha o consenso da comunidade de desenvolvedores do MediaWiki.

Isto é uma RfC?

Não no sentido de que a mudança seria feita ou não com base no consenso da comunidade. Isto não é um voto. Decisões de segurança de software são governadas pelo consenso da comunidade de desenvolvedores do MediaWiki, ao invés do consenso dos editores; a decisão final será feita via revisão de código, como de costume. Dito isso, seu feedback é muito desejado! A discussão pode revelar razões para fazer as coisas de maneira diferente da sugerida aqui, ou pode decidir detalhes importantes, como quais outras permissões o novo grupo de usuários deve receber. Pode também ajudar as comunidades a lidar com essa mudança de software em suas políticas e procedimentos.

Esta é uma resposta imediata aos recentes incidentes?

Não. Embora eu espere que eles tenham destacado a importância dessa mudança, a ideia tem sido discutida há anos, e o pacote específico sobre o qual esta consulta se refere foi escrito em março.

Mesmo que isso aconteça, ainda haverá algumas maneiras de os administradores implantarem JS em todo o site.

Esse é um problema técnico (difícil) que eventualmente será tratado. No entanto, limitar a capacidade de edição de JS dos administradores a alguns hacks obscuros e pouco conhecidos reduz significativamente a superfície de ataque e torna as vulnerabilidades restantes muito mais fáceis de monitorar.

Por que a edição de CSS é tratada da mesma maneira que a edição de JS?

Embora o CSS seja menos perigoso que o JS, ainda é muito ruim:

• As propriedades CSS relacionadas à imagem podem ser usadas para desmatar editores.
• Em alguns navegadores mais antigos, o código JavaScript pode ser incorporado em CSS.
• O CSS pode ser usado para roubar editar de tokens (e, portanto, fazer edições no nome de outro usuário e com seus privilégios), embora, por enquanto, isso seja limitado pela falta de suporte ao navegador.
• O clickjacking baseado em CSS pode ser usado para configurar ataques de phishing.

Os dados mostram que quase todos os administradores que regularmente editam CSS também editam JS, então não há razão para não tratar os dois problemas juntos.

No futuro, a capacidade de editar um subconjunto de CSS seguro e higienizado pode ser reintroduzida; assista ao projeto TemplateStyles para o trabalho em andamento nessa frente.

Isso também afeta as páginas TemplateStyles .css?

Não, somente páginas CSS no namespace do MediaWiki. O código CSS do TemplateStyles é automaticamente limpo para garantir que não possa ser usado para nada perigoso.

Por que não trabalhar em vez disso, impedindo automaticamente os usuários com a capacidade de editar JavaScript de fazer algo ruim?

Embora haja avanços nessa área (como CSP e alguma forma de revisão de edição), eles nunca serão capazes de prevenir ataques - não é possível higienizar linguagem de programação. Além disso, eles são muito mais complexos e exigem muito mais esforço. No curto prazo, reduzir o número de contas que podem editar JavaScript é, de longe, a estratégia de mitigação mais viável; a longo prazo, ainda deve ser feito ao lado dos outros.

E quanto às permissões editusercss/edituserjs ?

Essas permissões (pouco conhecidas e muito raramente usadas) permitem a edição do CSS/JS pessoal de outro usuário. Como isso permite roubar a conta do usuário alvo, as mesmas considerações se aplicam e essas permissões serão restritas da mesma maneira. (A mais longo prazo, veja T197087.)

E quanto à nova permissão editsitejson?

Isso é para editar páginas .json no espaço de nomes do MediaWiki (algo que o software aprendeu recentemente a lidar especialmente, como páginas de configuração para gadgets e bots). JSON é um dado, não um código, portanto, editá-lo não é considerado perigoso e os administradores ainda poderão fazê-lo; Os gadgets devem ser escritos de tal forma que um invasor que possa controlar as páginas .json não consiga comprometê-los.