Criação de grupo de utilizadores separado para edição do CSS/JS do site

Tracked in Phabricator:
Task T190015

O problema

Os administradores têm uma capacidade extremamente perigosa: ao editar páginas como Common.js, podem instantaneamente executar código nas máquinas dos nossos milhões de leitores e milhares de editores. O mesmo é válido para outros grupos de utilizadores com privilégios semelhantes, como os editores da interface. Embora este facto seja do conhecimento geral, poucas pessoas compreendem como esta capacidade pode ser usada para fins indevidos:

• Enviando código malicioso para os leitores ou editores, é basicamente possível fazer tudo: phishing de palavras-passe ou de números de cartões de crédito, redirecionamento de donativos, remoção da anonimização dos editores, edição em nome de outros editores, levar as pessoas a instalar malware sem o saberem, envio de spam, orquestração de ataques de negação de serviço (DDoS) contra terceiros...
• Ao contrário de outras capacidades perigosas (por exemplo, a verificação de utilizadores) que não podem ser usadas para fins lucrativos, este é um alvo lucrativo para um atacante. Recentemente, vimos alguém abusar dos seus privilégios para executar mineradores de criptomoedas nas máquinas de visitantes; há possibilidades bastantes piores que podem atrair qualquer intruso à procura de rendimentos fáceis.
• Os possíveis danos não estão limitados a uma única wiki: devido a todas as wikis da Wikimedia usarem um único sistema de autenticação global, um exploit numa wiki pode ser usado para controlar contas de administrador em qualquer outra wiki e expandir o ataque.

Assim, administradores e hackers desonestos que roubem contas de administrador representam uma ameaça séria, e devemos fazer os possíveis por reduzi-la. É um pequeno milagre que ainda não tenha acontecido um incidente sério, apesar de serem roubadas contas de administrador com regularidade; precisamos de reduzir a nossa dependência de milagres.

Ao mesmo tempo, a capacidade das comunidades Wikimedia adaptarem o funcionamento dos seus sites é extremamente valiosa e deve ser preservada. Os gadgets direcionados para os editores proporcionam enormes aumentos de produtividade; modificações direcionadas para os leitores podem adaptar uma wiki à grande variedade de problemas e de casos de utilização, nas centenas de wikis da Wikimedia, que um processo de desenvolvimento centralizado não teria esperança 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 controlo do ambiente CSS/JS local deve ser deixado à comunidade local.

A solução

A maioria dos administradores não querem nem precisam da capacidade de editar CSS e JavaScript. Em primeiro lugar, fazê-lo requer conhecimento dessas linguagens, que a maioria dos administradores não tem. As pessoas que já editam o código JavaScript e CSS comum do site (ou que desejam começar a fazê-lo) não devem ser impedidas, mas os administradores que não o pretendem não devem ter o direito de fazê-lo, para que um invasor que roube a conta de um administrador não possa causar danos. Adicionalmente, as comunidades que queiram aprovar os editores de JS a um nível de escrutínio superior ao dos administradores (o que geralmente é sensato) devem ser suportadas pelo software da wiki.

Para permitir isto, será criado um novo grupo de utilizadores, os administradores da interface, e só os utilizadores desse grupo poderão editar páginas CSS/JS do site. Por padrão, os burocratas e stewards poderão colocar utilizadores neste grupo, tal como se faz para os administradores. O processo de nomear novos administradores da interface será deixado ao critério de cada comunidade local (ou da comunidade global da Wikimedia se essa comunidade criar uma norma global pelos métodos tradicionais).

Daqui resultarão vários benefícios:

• O número de contas que podem ser usadas para danificar o site será drasticamente reduzido. A existência de menos contas que possam servir como vetor de ataque significa uma probabilidade menor de uma conta ficar vulnerável quando a base de dados de palavras-passe de um site de terceiros for atacada. Isto também significa que os administradores normais não precisam de se preocupar tanto se forem alvos de roubo da conta. Também é mais fácil monitorizar um número de contas menor, para identificação de sessões suspeitas.
• Para além do simples número de contas, também são removidas como vetor de ataque as contas mais vulneráveis. Os utilizadores que podem escrever código CSS/JS normalmente têm melhores conhecimentos informáticos em geral e, portanto, melhores práticas de segurança da palavra-chave e do sistema.
• De futuro, podemos definir requisitos de segurança mais estritos para os editores de CSS/JS (como exigir a autenticação de dois fatores) sem incomodar todos os outros administradores cujo roubo da conta não seria tão perigoso.

A nível técnico: está a ser introduzido no MediaWiki um novo conjunto de permissões (editsitecss e editsitejs); para editar uma página .css ou .js no espaço nominal (domínio) MediaWiki, serão necessárias tanto a antiga permissão editinterface como a nova editsiteXXX. Os administradores e outros grupos de utilizadores que atualmente têm editinterface receberão os novos privilégios durante um período curto de migração (para que a transição possa decorrer sem perturbações), mas eventualmente não os terão, e o software garantirá que nenhum outro grupo para além dos administradores da interface pode tê-los.

Como pode ajudar

• Depois de esta consulta terminar, haverá um período de migração (provavelmente de duas semanas) durante o qual existirá o grupo de administradores da interface, mas os administradores normais ainda poderão editar CSS/JS. Certifique-se de que a sua comunidade está ciente disto, para que possam adicionar utilizadores ao grupo de administradores da interface durante esse período e ter um processo para decidir quem é adicionado (o processo de migração deve ser deixado para cada comunidade local; pode ser tão simples como adicionar todos os administradores que o solicitem).
• Adicionalmente, certifique-se de que a sua wiki tem alguma documentação e um processo de eleição para o novo grupo após o período de migração. Novamente, este pode ser tão simples como perguntar aos administradores recém-eleitos se também querem ser administradores da interface e se conhecem Javascript e práticas básicas de segurança. Em qualquer caso, recomenda-se tornar a barra para administradores da interface pelo menos tão alta como para administradores (em termos de confiança e do comportamento do utilizador), e talvez ainda mais alta (veja a página dos grupos de utilizadores para mais conselhos).
• Informe-nos sobre os fluxos de edição de CSS/JavaScript que exigem permissões extra (isto será útil para decidir que direitos o grupo de administradores da interface deve ter por padrão). Por exemplo, os administradores da interface precisam de poder eliminar páginas ou alterar o modelo de conteúdo?
• Sugira um nome de grupo melhor! "Administradores da interface" não é ótimo. Coisas a ter em conta: os membros deste grupo não devem ser confundidos com programadores que mantêm código-fonte fora da wiki (programadores do MediaWiki, equipa de manutenção da ferramenta Toolforge, etc.); não devem ser confundidos com aqueles que trabalham no código Lua (o espaço nominal, ou domínio, Módulo); continuará a existir um grupo de editores da interface (para editar as mensagens do MediaWiki); idealmente, o nome deve expressar que o papel requer pelo menos tanta confiança quanto para se ser administrador.
• Se antevê algum problema não previsto neste documento, ou se houver alterações adicionais que podem tornar esta mudança mais útil ou menos onerosa, diga-nos!

Use a página de discussão para os seus comentários. Pode escrever em qualquer língua.

Perguntas frequentes

Quem criou este documento?

Esta página e a mudança de código correspondente foram criadas por User:Tgr (na função de voluntário). Com base na discussão em T190015 e no wikitech-l, acredito que têm o consenso da comunidade de desenvolvimento do MediaWiki.

Isto é um pedido de comentários (RfC)?

Não, no sentido de que a alteração seja feita, ou não feita, com base no consenso da comunidade. Isto não é uma votação. As decisões acerca da segurança do software são tomadas por consenso da comunidade de desenvolvimento do MediaWiki, e não por consenso entre os editores; a decisão final será feita através da revisão do código, como de costume. Dito isto, a sua opinião é muito desejada! A discussão pode revelar razões para fazer as coisas de maneira diferente da aqui sugerida, ou pode ajudar a decidir detalhes importantes, como que outras permissões o novo grupo de utilizadores deve receber. Pode também ajudar as comunidades a integrarem esta alteração do software nas suas normas e procedimentos.

Esta é uma resposta impulsiva aos recentes incidentes?

Não. Embora eu espere que eles tenham sublinhado a importância desta mudança, a ideia já é discutida há anos e a alteração específica à qual esta consulta se refere foi escrita em março.

Mesmo que isto se torne uma realidade, continuarão a haver formas de os administradores implementarem JS comum do 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 mecanismos obscuros e pouco conhecidos reduz significativamente a área de ataque e torna as vulnerabilidades restantes muito mais fáceis de monitorizar.

Porque 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 assim é muito arriscado:

• As propriedades CSS relacionadas com imagens podem ser usadas para remover o anonimato dos editores.
• Em alguns browsers mais antigos, o código JavaScript pode ser incorporado no CSS.
• O CSS pode ser usado para roubar chaves de edição (e, portanto, fazer edições em nome de outro utilizador e com os seus privilégios), embora, por agora, isto seja limitado pela falta de suporte do navegador.
• O clickjacking baseado em CSS pode ser usado para preparar ataques de phishing.

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

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

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

Não, só as páginas CSS do espaço nominal MediaWiki. O código CSS de TemplateStyles é automaticamente validado para garantir que não possa ser usado para fins perigosos.

Porque não tentar, alternativamente, impedir automaticamente os utilizadores com a capacidade de editar JavaScript de fazerem algo prejudicial?

Embora haja progressos nessa área (como CSP e uma forma de revisão das edições), eles nunca serão capazes de impedir ataques - não é possível validar a inexistência de código malicioso numa linguagem de programação. Além disso, isso é muito mais complexo e exige 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 ela deve continuar, em paralelo com outras estratégias.

E quanto às permissões editusercss e edituserjs?

Estas permissões (pouco conhecidas e muito raramente usadas) permitem a edição do CSS/JS pessoal de outro utilizador. Como isso permite apropriar-se da conta do utilizador alvo, aplicam-se as mesmas considerações e essas permissões serão restringidas da mesma forma (a mais longo prazo, veja T197087).

E quanto à nova permissão editsitejson?

Essa permissão é para editar páginas .json no espaço nominal (domínio) MediaWiki (algo que o software aprendeu recentemente a tratar de forma especial, como páginas de configuração de gadgets e de robôs). JSON são dados, não código, portanto, editá-los não é considerado perigoso e os administradores continuarão a poder fazê-lo; os gadgets devem ser escritos de forma a que um intruso que possa controlar as páginas .json não consiga pô-los em risco.