Creación de un grupo de usuarios separado para editar CSS y JS que afecta a todo un proyecto wiki

Tracked in Phabricator:
Task T190015

El problema

Los administradores tienen un poder sumamente peligroso: al editar páginas como Common.js pueden ejecutar código de manera instantánea en los dispositivos de nuestros millones de lectores y miles de editores (Lo mismo ocurre con otros grupos de usuarios con privilegios similares, como los editores de interfaz). Si bien esto es ampliamente conocido, pocas personas entienden lo dañino que esto puede ser mal utilizado:

• Al enviar código maligno a los lectores o editores, uno puede básicamente hacer cualquier cosa: obtener contraseñas o números de tarjetas de crédito, redirigir las donaciones, rastrear la identidad de los editores, realizar ediciones en el nombre de otros editores, engañar a las personas para instalar software maligno, enviar spam, organizar ataques de denegación de servicio en perjuicio de sitios web de terceros...
• A diferencia de otros permisos peligrosos (por ejemplo, los verificadores de usuarios) que no pueden ser monetizados, este es un objetivo lucrativo para un atacante. Hemos visto recientemente a algún usuario abusar de sus privilegios para ejecutar programas de minería de criptomonedas en los dispositivos de los visitantes; y hay cosas más graves que son atractivas para un atacante buscando unos ingresos fáciles.
• El daño no se limita a una sola wiki: debido a que las wikis de Wikimedia usan solo un sistema de inicio de sesión global, un software malicioso en una wiki podría ser usado para controlar las cuentas de administrador en cualquier otra wiki y extender el ataque aún más.

Por lo tanto, los administradores deshonestos y los piratas informáticos que roban cuentas de administrador representan una seria amenaza y debemos hacer todo lo posible para reducir esta amenaza. Ha sido un pequeño milagro que hasta ahora no se han producido grandes incidentes, a pesar de que las cuentas de administrador son robadas regularmente; necesitamos reducir nuestra confianza en los milagros.

Al mismo tiempo, la capacidad de las comunidades Wikimedia de dar forma al funcionamiento de sus sitios es sumamente valiosa y debería preservarse. Los accesorios orientados al editor proporcionan enormes aumentos de productividad; las modificaciones orientadas al lector pueden adaptar la wiki a la gran variedad de problemas y casos de uso en las cientos de wikis de Wikimedia, que un proceso de desarrollo centralizado no tendría ninguna esperanza de replicar; y ser capaz de resolver problemas localmente en lugar de tener que depender de la ayuda externa es una fuente importante de empoderamiento y motivación para una comunidad wiki. El control del entorno CSS y JS debería dejarse en manos de la comunidad local.

La solución

La mayoría de los administradores de hecho no quieren o no necesitan la capacidad de editar CSS y JavaScript. En primer lugar, eso requiere el conocimiento de aquellos lenguajes de programación, que muchos de los administradores no poseen. Las personas que ya editan el código JavaScript y el CSS del sitio (o quieren comenzar a hacerlo) no debería impedírseles, pero aquellos administradores que no les importa no deberían tener el permiso, así un atacante que robe sus cuentas no pueden hacer daño. Además, las comunidades que quieran examinar a los editores de JS a un nivel más alto o bajo escrutinio de los administradores (lo que por lo general es una buena decisión) deberían estar apoyados por el software wiki.

Para facilitar esto, se creará un nuevo grupo de usuario denominado administradores de interfaz, y solamente usuarios de este grupo podrán editar las páginas CSS y JS de todo el sitio. De forma predeterminada los burócratas y stewards podrán otorgar el permiso a los usuarios, de la misma manera que se hace con los administradores. La forma de designar nuevos administradores de interfaz se dejará a discreción de cada comunidad local (o de la comunidad global de Wikimedia si esta comunidad crea una política global mediante el procedimiento habitual).

Esto tendrá varios beneficios:

• El número de cuentas que sean usadas para poner en riesgo el sitio serán reducidas drásticamente. Menos cuentas que puedan servir de vectores de ataque significa una menor probabilidad de que esté en riesgo una cuenta vulnerable cuando la base de datos de contraseñas de un sitio web de terceros sea comprometida (esto también significa que los administradores comunes se tengan que preocupar menos sobre convertirse el blanco de un robo de cuenta). Asimismo es más sencillo vigilar en busca de inicios de sesión sospechosos si hay un número menor de cuentas.
• Más allá del mero número de cuentas, eliminará a las cuentas más vulnerables de ser vectores de un ataque. Los usuarios que pueden escribir código CSS y JS generalmente tienen mejores habilidades en tecnologías de la información, y por eso tienen mejores contraseñas y prácticas de seguridad en un sistema.
• En el futuro podemos establecer requisitos de seguridad más estrictos para los editores de CSS y JS (como exigir autenticación de dos pasos) sin molestar a todos los otros usuarios cuyas cuentas comprometidas no supongan tal peligro.

En un nivel técnico: se está agregando un conjunto nuevo de permisos (editsitecss y editsitejs); para editar páginas .css o .js en el espacio de páginas MediaWiki, será necesario tanto el permiso antiguo editinterface como el permiso correspondiente editsiteXXX. Los administradores y otros grupos de usuarios que actualmente tienen editinterface recibirán los nuevos permisos durante un período breve durante la migración (de modo que la transición pueda tener lugar sin ninguna perturbación) pero finalmente no los tendrán, y el software se asegurará de que ningún otro grupo de usuarios aparte de los administradores técnicos los puedan tener.

Cómo puedes ayudar

• Después de que esta consulta finalice, habrá un período de migración (probablemente de dos semanas) en el cual el grupo de usuarios de administradores técnicos existirá pero los administradores normales aún podrán editar páginas CSS y JS. Por favor asegúrate de que tu comunidad está informada de esto, así ellos pueden agregar personas al grupo de administradores técnicos durante ese tiempo y establecen un proceso para decidir quién podrá ser agregado. (Se deja a la comunidad local el establecer cómo será el proceso de migración; podría ser tan simple como añadir a cada administrador que lo pida).
• Asimismo, por favor asegúrate de que tu wiki tiene alguna documentación y proceso de elección para el nuevo grupo de usuario una vez finalice el proceso de migración. De nuevo, esto podría ser tan simple como preguntarle a los nuevos administradores electos si también desean ser administradores técnicos y si ellos conocen Javascript y prácticas básicas de seguridad. En cualquier caso, se recomienda establecer un baremo al menos tan alto como el requerido para los administradores (en términos de confianza y comportamiento del usuario) y quizá incluso más alto (véase la página sobre el grupo de usuarios para tener una guía).
• Cuéntanos sobre flujos de trabajo en la edición de CSS y JavaScript que exijan permisos adicionales (esto será de ayuda para decidir qué permisos debería tener por defecto el grupo de usuario de administradores técnicos). Por ejemplo, ¿los administradores técnicos deberían ser capaces de borrar páginas o de cambiar el modelo de contenido de una página?
• Sugerencias de un mejor nombre para el grupo. "Administradores técnicos" no tiene impacto. Cosas a tener en cuenta: los miembros del grupo no deberían ser confundidos con los desarrolladores que mantienen el código fuente fuera de los wikis (desarrolladores de MediaWiki, mantenedores de herramientas en Toolforge, etc.); tampoco deberían ser confundidos con personas que trabajan con código Lua (en el espacio de nombres Módulo); aún existirá un grupo de editores de la interfaz (para editar mensajes del espacio de páginas MediaWiki); e idealmente el nombre debería expresar que este permiso requiere al menos tanta confianza como la requerida para ser administrador.
• Si tienes cualquier problema no previsto en este documento o si tienes para proponer otros cambios que harían del cambio más útil o menos pesado, por favor háznoslos saber.

Por favor usa la página de discusión para intercambiar opiniones. Puedes escribir en cualquier idioma.

Preguntas frecuentes

¿Quién está detrás de este documento?

Esta página y los cambios correspondientes en el código fuente han sido escritos por el usuario Tgr (de modo voluntario). Basado en el debate en T190015 y en la lista de correo wikitech-l, creo que tiene el consenso de la comunidad de desarrolladores de MediaWiki.

¿Esto es una solicitud de comentarios?

No en el sentido de que el cambio se haga o no se haga en base al consenso de la comunidad. Esto no es una votación. Las decisiones de seguridad del software se rigen por el consenso de la comunidad de desarrolladores de MediaWiki, en lugar del consenso de los editores; la decisión final se hará a través de la revisión del código, como de costumbre. Dicho esto, tus comentarios son bienvenidos. El debate podría revelar razones para hacer las cosas de forma diferente a la sugerida aquí, o podría decidir sobre detalles importantes como qué otros permisos debería obtener el nuevo grupo de usuarios. También podría ayudar a las comunidades a abordar este cambio de software en sus políticas y procedimientos.

¿Esta es una respuesta impulsiva a los incidentes recientes?

No. Si bien espero que estos incidentes hayan destacado la importancia de este cambio, la idea ha sido debatida durante años y el parche específico que motivó esta consulta se escribió en marzo.

Incluso si esto tiene lugar, aún habrá algunas formas para que los administradores implementen código JS en todo el sitio.

Ese es un problema técnico (difícil) que eventualmente será tratado. Sin embargo, la limitación de la capacidad de edición de JS de los administradores a unos pocos hacks raramente conocidos reduce significativamente la superficie de ataque y hace que las vulnerabilidades restantes sean mucho más fáciles de vigilar.

¿Por qué se trata la edición de CSS del mismo modo que la edición de JS?

Si bien CSS es menos peligroso que JS, todavía es bastante malo:

• Las propiedades CSS relacionadas con las imágenes pueden ser usadas para rastrear la identidad de los editores.
• En algunos navegadores antiguos, puede insertarse código JavaScript en el código CSS.
• El CSS puede usarse para robar tokens de edición (y así hacer ediciones en nombre de otro usuario y con sus privilegios), aunque por ahora esto está limitado por la falta de soporte de los navegadores.
• Las técnicas maliciosas de Clickjacking (o engaño al usuario mediante un elemento de la interfaz que aparenta ser una cosa pero que hace otra) basadas en CSS pueden usarse para configurar ataques de suplantación de identidad.

Los datos muestran que casi todos los administradores que regularmente editan CSS también editan JS, así que no hay razón para no tratar los dos problemas juntos.

En el futuro, podría restaurarse la capacidad de editar un subconjunto seguro y depurado de CSS. Manténte al tanto del proyecto TemplateStyles para el trabajo en curso en ese ámbito.

¿Esto también afecta a las páginas .css de TemplateStyles?

No, solo afecta a las páginas CSS en el espacio de nombres MediaWiki. El código CSS de TemplateStyles es depurado automáticamente para asegurarse de que no puede ser usado para nada peligroso.

¿Por qué no mejor trabajar en que se prevenga automáticamente que usuarios con la capacidad de editar JavaScript hagan algo malo?

Aunque hay avances para hacerse en aquel frente (tales como CSP y algunas formas de revisión de ediciones), esos nunca serán capaces de prevenir totalmente los ataques. No es simplemente posible depurar un lenguaje de programación. Además, estos son mucho más complejos y requieren por lejos mucho esfuerzo. A corto plazo, reducir el número de cuentas que pueden editar JavaScript es por lejos la estrategia de mitigación más factible; a largo plazo, debería aún ser hecha en conjunto con las otras.

¿Qué hay de los permisos editusercss y edituserjs?

Estos permisos (poco conocidos y raramente usados) permiten editar el CSS y JS personal de otro usuario. Dado que eso permite robar la cuenta de usuario blanco del ataque, aplican las mismas consideraciones y estos permisos serán restringidos de la misma manera. (A largo plazo, véase T197087).

¿Qué hay del permiso editsitejson?

Ese permiso es para editar págias .json en el espacio de páginas MediaWiki (algo que el software recientemente ha sido capaz de manipular de forma específica, pensado para páginas de configuración para accesorios y robots). JSON es datos, no código, así que editarlos no se considera peligroso y los administradores aún deberían ser capaces de hacerlo. Los accesorios deberían ser reescritos de una forma en la que un atacante que tome control de páginas .json no deberían poder comprometerlas.