Создание новой группы участников для редактирования общесайтового CSS/JS

Tracked in Phabricator:
Task T190015

Проблема

Администраторы имеют чрезвычно опасную возможность редактировать такие страницы, как Common.js, изменение которых может повлиять на миллионы читателей и тысячи редакторов (это же касается и иных лиц, имеющих возможность редактирования данных страниц). Хотя редактирование подобных страниц является обычной практикой, но мало кто знает, что это может использоваться в недобросовестных целях:

• Внося вредоносный для читателей или редакторов код, можно сделать что угодно: красть пароли или номера кредитных карт, перенаправлять пожертвования, деанонимизировать редакторов, вносить изменения от лица других участников, обманывать людей, устанавливая вредоносные программы, отправлять спам и организовывать DDoS-атаки на сторонние сайты…
• В отличие от других опасных возможностей (проверка участников, например), которые не могут быть монетизированы, эта является финансово прибыльной для атакующего. Недавно мы увидели, как кто-то злоупотреблял своими привилегиями для майнинга криптовалют на машинах посетителей; но это только малая часть того, что можно сделать с помощью этой возможности, которая может принести злоумышленнику лёгкий доход.
• Подобные действия могут принести ущерб не только одному проекту: Викимедиа использует единую систему для входа, поэтому взлом на одном проекте может стать причиной захвата учётных записей администраторов на других проектах, и в дальнейшем это может привести к расширению количества захваченных сообществ.

Таким образом, администраторы-мошенники и хакеры, крадущие административные аккаунты, представляют серьёзную угрозу, и мы должны сделать всё возможное, чтобы уменьшить её. Это чудо, но до сих пор не произошло ни одного серьёзного инцидента, несмотря на то, что аккаунты администраторов периодически взламывают; однако нам нужно меньше полагаться на чудеса.

В то же время, способность сообществ Фонда Викимедиа самим формировать работу проекта чрезвычайно ценна и должна быть сохранена. Инструменты для редакторов дают громадный прирост производительности, а модификации для читателей помогают приспособить вики для решения различных проблем и способов использования на сотнях вики-сайтов Фонда, чей централизованный процесс разработки не может быть использован повсеместно. Возможность решения проблем локально вместо того, чтобы зависеть от внешней помощи — это важный источник силы и мотивации для вики-сообщества.

Решение

Большинство администраторов не хотят или не нуждаются в возможности редактирования CSS и JavaScript. В первую очередь, это требует знание языков программирования, которые многие администраторы не знают. Участники, которые занимаются этой деятельностью (или будут заниматься), должны иметь такую возможность, но администраторы, которые не используют эту привилегию, должны быть лишены этого, для того чтобы избежать вреда в случае взлома. Кроме того, если сообщества решат проверять участников с такой возможностью на знание JS на более высоком уровне, чем администраторов (что является разумным), то это должно поддерживаться программным обеспечением вики.

Для облегчения будет создана новая группа участников — технический администратор — и только пользователи этой группы смогут редактировать CSS/JS-страницы. По умолчанию добавлять/исключать в данные группы могут бюрократы и стюарды. Назначение таких лиц будет оставлено на усмотрение каждого сообщества (или глобального сообщества, если будет создана глобальная политика).

Это будет иметь несколько преимуществ:

• Количество учётных записей, которые могут быть использованы для компрометации сайта, будет значительно сокращено. Это уменьшит количество уязвимых учётных записей в случае взлома базы данных (обычные администраторы также могут быть спокойны, так как риск стать мишенью взлома намного уменьшается). Небольшое количество учётных записей с данной возможностью позволит облегчить процесс отслеживания подозрительных действий.
• Пользователи, которые знают CSS/JS, как правило, трепетнее относятся к безопасности своей учётной записи из-за IT-навыков. Это уменьшит количество наиболее уязвимых участников.
• В будущем могут быть установлены более высокие требования безопасности для редакторов CSS/JS (например, обязательная двухфакторная аутентификация), не доставляя неудобств обычным администраторам, чьи учётные записи не представляют серьёзной опасности.

На техническом уровне: в «Медиавики» вводится новый ряд прав (editsitecss и editsitejs); чтобы редактировать страницу .css или .js в пространстве MediaWiki, потребуется как старое право editinterface, так и соответствующее право editsiteXXX. Администраторы и другие группы, которые имеют сейчас право editinterface, получат новые права в течение короткого периода миграции (чтобы переход мог произойти без проблем), но не будут иметь их впоследствии, и движок будет следить за тем, чтобы никто, кроме технических администраторов, не имел эти права в дальнейшем.

Как вы можете помочь

• После окончания данной консультации начнётся период миграции (скорее всего, две недели), в течение которого будет существовать группа «технический администратор», но обычные администраторы будут продолжать иметь возможность редактировать CSS/JS. Пожалуйста, оповестите своё сообщество об этом, чтобы они смогли добавить людей в группу «технический администратор» в течение этого времени и создали процедуру решения вопроса, кто будет добавлен. (Как будет происходить процесс миграции, остаётся на откуп сообществу; он может быть даже таким, что в эту группу просто будет добавляться любой администратор, который об этом попросит.)
• Кроме того, пожалуйста, убедитесь, что ваша вики имеет какую-либо документацию и процедуру отбора для новой группы после периода миграции. Повторюсь, это может быть простой процесс, такой как вопрос новоизбранным администраторам, хотят ли они также быть техническими администраторами и знакомы ли они с JavaScript и базовыми практиками безопасности. В любом случае, рекомендуется сделать требования к техническим администраторам по крайней мере настолько же высокими, как к администраторам (в области доверия и пользовательского поведения), а может и выше (см. страницу группы участников для других советов).
• Расскажите нам о рабочем процессе редактирования CSS/JavaScript, который может потребовать дополнительных прав (это будет полезно для решения, какие права должна иметь группа технических администраторов по умолчанию). Например, нужна ли техническим администраторам возможность удалять страницы или изменять контентную модель?
• Предложите лучшее название группы! «Технические администраторы» — не самый лучший вариант. Что стоит принимать во внимание: членов группы не должны путать с разработчиками, которые поддерживают код за пределами вики (разработчики «Медиавики», инструментов на Toolforge и т. д.); их не должны путать с людьми, работающими над кодом Lua (пространство «Модуль»); всё ещё может быть группа «редактор интерфейса» (для редактирования сообщений MediaWiki); в идеале, название должно выражать, что эта роль требует столько же доверия, сколько и роль администратора.
• Если вы видите любые проблемы, которые не были обсуждены в этом документе, или есть дополнительные изменения, которые бы сделали это изменение более полезным / менее обременительным, пожалуйста, скажите нам об этом!

Пожалуйста, используйте страницу обсуждения для отзывов. Вы можете написать на любом языке.

ЧЗВ

Кто автор этого документа?

Эта страница и связанное с ней изменение кода написаны Tgr (как волонтёром). Основываясь на обсуждении в T190015 и в рассылке wikitech-l, я считаю, что она имеет консенсус сообщества разработчиков «Медиавики».

Это опрос?

Не в том смысле, что изменение будет сделано или не сделано на основании консенсуса сообщества. Это не голосование. Изменения в области безопасности ПО принимаются на основании консенсуса сообщества разработчиков «Медиавики», а не консенсуса редакторов; окончательное решение будет сделано через проверку кода, как обычно. Но ваши отзывы очень востребованы! В обсуждении могут быть обнаружены причины для того, чтобы сделать эти изменения иначе, чем предложено здесь, или решены важные детали, такие как наличие других прав у новой группы. Оно также может помочь сообществам адресовать это изменение в своих правилах и процедурах.

Не является ли это поспешным ответом на недавние инциденты?

Нет. Хоть я и надеюсь, что они показали важность данного изменения, сама идея обсуждалась годами, а патч, который обсуждается в этой консультации, был написан в марте.

Даже если это произойдёт, у администраторов всё ещё останутся пути для внедрения общесайтового JS.

Это (сложная) техническая проблема, с которой мы рано или поздно справимся. Как бы то ни было, ограничение возможности правки JS у администраторов к нескольким слабо известным хакам значительно снижает виды атаки и делает оставшиеся уязвимости куда более простыми для отслеживания.

Почему к правке CSS подходят так же, как к JS?

Хотя CSS и менее опасен, чем JS, у него всё ещё есть опасные возможности:

• Связанные с изображениями свойства CSS могут использоваться для деанонимизации участников.
• В некоторых старых браузерах JavaScript-код может быть вставлен в CSS.
• CSS может использоваться для кражи токенов для редактирования (и таким образом — правки от лица другого участника), хотя пока это ограничено малой поддержкой браузеров.
• Основанный на CSS кликджекинг может использоваться для фишинга.

Данные показывают, что почти все администраторы, которые регулярно редактируют CSS, редактируют и JS, так что нет никаких причин для того, чтобы не считать эти проблемы одинаковыми.

В будущем будет введена возможность редактировать очищенный, безопасный подкласс CSS; следите за проектом TemplateStyles, если вас интересует прогресс в этой задаче.

Затрагивает ли это страницы .css стилей шаблонов?

Нет, только страницы CSS в пространстве MediaWiki. CSS-код «Стилей шаблонов» автоматически чистится, чтобы его нельзя было использовать ни для чего опасного.

Почему вместо этого не поработать на автоматическом предотвращении плохих правок у пользователей, имеющих возможность редактирования JavaScript?

Хотя и есть возможности прогресса на этом фронте (такие как CSP и какая-то форма проверки правок), они никогда не смогут полностью предотвратить атаки — полностью очистить язык программирования просто невозможно. Также, они будут гораздо более сложными и потребуют куда больше усилий. В краткосрочном периоде, снижение числа учётных записей, которые могут редактировать JavaScript, является наиболее реалистичной стратегией уменьшения последствий; в долгосрочном периоде, это должно быть сделано наряду с другими мерами.

Что насчёт прав editusercss/edituserjs?

Эти (малоизвестные и очень редко используемые) права позволяют править чужие личные CSS/JS. Так как это даёт возможность кражи учётной записи, те же соображения применимы и к ним, и эти права будут ограничены тем же образом. (В более дальней перспективе, см. T197087.)

Что за новое право editsitejson?

Это право создано для редактирования страниц .json в пространстве «Медиавики» (недавнее нововведение движка, предназначенное для страниц конфигурации гаджетов и ботов). JSON — данные, а не код, так что его редактирование не является опасным, и администраторы всё ещё смогут этим заниматься; гаджеты же должны писаться так, чтобы атакующий, который имеет доступ к страницам .json, не мог их компрометировать.