Створення окремої групи користувачів для редагування загального CSS/JS

Tracked in Phabricator:
Task T190015

Проблема

Адміністратори мають надзвичайно небезпечну владу: редагуванням таких сторінок, як Common.js, вони можуть миттєво виконати код на машинах мільйонів наших читачів і тисяч дописувачів (те саме стосується інших груп користувачів із порівнянними привілеями, як-от редактори інтерфейсу). Хоча це широко відомо, лише кілька людей розуміють, як погано це можна хибно використати.

• Надсилаючи зловмисний код читачам/редакторам, можна практично робити все: красти паролі або номери кредитних карток, перенаправляти пожертви, деанонімізувати редакторів, робити правки від імені інших редакторів, обманювати людей для встановлення шкідливого ПЗ, розсилати спам, організовувати DDoS-атаки на сторонні сайти...
• На відміну від інших небезпечних повноважень (наприклад, checkuser), які не можна монетизувати, це приваблива ціль для атакуючого. Нещодавно ми бачили, як хтось зловживав своїми привілеями, запускаючи криптовалютні майнери на машинах відвідувачів; є набагато гірші речі, які приваблюють будь-якого нападника, що шукає легкий заробіток.
• Збитки не обмежуються одним вікі: через те, що всі вікі Вікімедіа використовують єдину глобальну систему входу, експлойт в одній вікі може бути використаний для захоплення адміністраторських акаунтів у будь-якій іншій вікі та розширення атаки.

Отже, зловмисні адміністратори та хакери, що крадуть акаунти адміністраторів, становлять серйозну загрозу, і ми повинні зробити все можливе, щоб її зменшити. Це маленьке диво, що досі не трапилося серйозних інцидентів, хоча акаунти адміністраторів регулярно викрадають; нам потрібно зменшити залежність від дива.

Водночас здатність спільнот Вікімедіа впливати на роботу своїх сайтів є надзвичайно цінною і повинна бути збережена. Гаджети для редакторів значно підвищують продуктивність; модифікації для читачів дозволяють адаптувати вікі до широкого спектру проблем і випадків використання на сотнях вікі Вікімедіа, які централізований процес розробки не зможе відтворити; можливість вирішувати проблеми локально, замість покладатися на зовнішню допомогу, є важливим джерелом самоствердження і мотивації для спільноти вікі. Контроль за локальним середовищем CSS/JS має залишатися за місцевою спільнотою.

Рішення

Більшість адміністраторів фактично не хочуть і не потребують можливості редагувати CSS та JavaScript. По-перше, це вимагає знання цих мов, яких більшість адміністраторів не має. Людей, які вже редагують глобальний JavaScript і CSS (або хочуть почати це робити), не слід обмежувати, але адміністратори, яким це байдуже, не повинні мати таке право, щоб нападник, викравши їх акаунт, не міг завдати шкоди. Також спільноти, які хочуть перевіряти редакторів JS на вищому рівні чи під пильнішим контролем, ніж адміністратори (що зазвичай мудро), повинні отримати підтримку від вікі-програмного забезпечення.

Для цього буде створено нову групу користувачів адміністратори інтерфейсу, і лише користувачі цієї групи зможуть редагувати глобальні CSS/JS сторінки. За замовчуванням бюрократи і стюарди зможуть надавати членство в цю групу користувачам так само, як це робиться з адміністраторами. Призначення нових адміністраторів інтерфейсу буде залишено на розсуд кожної локальної спільноти (або глобальної спільноти Вікімедіа, якщо вона створить глобальну політику звичайним шляхом).

Це матиме кілька переваг:

• Кількість акаунтів, які можуть бути використані для компрометації сайту, буде різко зменшена. Менша кількість акаунтів, що можуть служити векторами атаки, означає менший ризик уразливості акаунта у випадку компрометації бази паролів стороннього сайту. (Це також означає, що звичайні адміністратори можуть менше хвилюватися про те, щоб стати жертвами крадіжки акаунта.) Меншу кількість акаунтів також легше контролювати на предмет підозрілих входів.
• Окрім простої кількості акаунтів, це усуне найуразливіші акаунти як вектори атаки. Користувачі, які можуть писати код CSS/JS, зазвичай мають кращі ІТ-навички загалом, а отже й кращі практики безпеки паролів і систем.
• У майбутньому ми зможемо встановити підвищені вимоги безпеки для редакторів CSS/JS (наприклад, вимогу двофакторної аутентифікації), не створюючи незручностей для інших адміністраторів, у яких компрометація акаунта не становитиме великої загрози.

З технічної точки зору: у MediaWiki вводиться новий набір прав (editsitecss і editsitejs); для редагування сторінки .css або .js у просторі імен MediaWiki буде потрібне як старе право editinterface, так і відповідне нове editsiteXXX. Адміністратори та інші групи користувачів, які зараз мають editinterface, тимчасово отримають нові права для періоду міграції (щоб перехід відбувся без перебоїв), але згодом їх втратять, і програмне забезпечення забезпечить, щоб лише адміністратори інтерфейсу мали ці права.

Чим Ви можете допомогти

• Після завершення цієї консультації розпочнеться період міграції (ймовірно два тижні), під час якого існуватиме група адміністраторів інтерфейсу, але звичайні адміністратори все ще зможуть редагувати CSS/JS. Будь ласка, переконайтеся, що ваша спільнота про це знає, щоб додати людей до групи адміністраторів інтерфейсу у цей час, а також щоб був процес визначення, кого додавати. (Який саме процес міграції – це справа кожної локальної спільноти; це може бути так просто, як додавання кожного адміністратора, який про це попросить.)
• Також переконайтеся, що у вашій вікі є документація та виборчий процес для нової групи після періоду міграції. Знову ж таки, це може бути так просто, як запитати новообраних адміністраторів, чи хочуть вони бути адміністраторами інтерфейсу і чи знайомі з Javascript та базовими практиками безпеки. У будь-якому випадку рекомендується встановити рівень довіри для адміністраторів інтерфейсу принаймні не нижчий за рівень адміністраторів, а можливо навіть вищий (див. сторінку групи користувачів для додаткових порад).
• Розкажіть нам про робочі процеси редагування CSS/JavaScript, які вимагають додаткових прав (це допоможе вирішити, які права група адміністраторів інтерфейсу має мати за замовчуванням). Наприклад, чи потрібно адміністраторам інтерфейсу мати можливість видаляти сторінки або змінювати модель вмісту?
• Запропонуйте кращу назву для групи! "Адміністратори інтерфейсу" (Interface administrators) — не дуже вдала назва. Варто врахувати: учасників групи не слід плутати з розробниками, які підтримують позавіковий код (розробники MediaWiki, утримувачі інструментів Toolforge тощо); їх не слід плутати з тими, хто працює з Lua-кодом (простір імен Модулів); також існуватиме група редакторів інтерфейсу (для редагування повідомлень MediaWiki); ідеально, щоб назва виражала, що ця роль потребує принаймні такого самого рівня довіри, як і роль адміністратора.
• Якщо ви бачите будь-які проблеми, не передбачені в цьому документі, або є додаткові зміни, які зроблять це оновлення кориснішим / менш обтяжливим, будь ласка, повідомте нам!

Будь ласка, використовуйте сторінку обговорень для зворотного відгуку. Ви можете писати будь-якою мовою.

ЧаПи

Хто стоїть за цим документом?

Цю сторінку та відповідну зміну в коді написав Користувач:Tgr (у волонтерській ролі). Спираючись на обговорення у T190015 та на wikitech-l, я вважаю, що вона має консенсус спільноти розробників MediaWiki.

Це RfC?

Не в тому сенсі, що зміна буде або не буде впроваджена на основі консенсусу спільноти. Це не голосування. Рішення щодо безпеки програмного забезпечення ухвалюються на основі консенсусу спільноти розробників MediaWiki, а не редакторів; остаточне рішення буде прийняте шляхом перегляду коду, як зазвичай. Водночас, ваш відгук надзвичайно важливий! Обговорення може виявити причини для зміни підходу, відмінного від запропонованого тут, або визначити важливі деталі, наприклад, які ще права має отримати нова група користувачів. Це також може допомогти спільнотам адаптувати цю зміну в політиках і процедурах.

Чи це емоційна реакція на нещодавні інциденти?

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

Навіть після цього залишаться деякі способи, за допомогою яких адміністратори зможуть розгортати глобальний JavaScript.

Це (складна) технічна проблема, яка зрештою буде вирішена. Тим не менш, обмеження можливості редагування JS для адміністраторів кількома неочевидними й маловідомими методами суттєво зменшує поверхню атаки й полегшує моніторинг залишкових вразливостей.

Чому редагування CSS розглядається так само, як редагування JS?

Хоча CSS менш небезпечний, ніж JavaScript, він все одно може завдати шкоди:

• Властивості CSS, пов'язані з зображеннями, можуть бути використані для деанонімізації редакторів.
• У деяких старих браузерах код JavaScript можна вбудовувати в CSS.
• CSS може бути використаний для крадіжки токенів редагування (а отже, для редагування від імені іншого користувача і з його правами), хоча наразі це обмежено відсутністю підтримки в браузерах.
• CSS-заснований клікджекинг може бути використаний для організації фішингових атак.

Дані показують, що майже всі адміністратори, які регулярно редагують CSS, також редагують JS, тому немає причин розділяти ці дві проблеми.

У майбутньому може бути повернута можливість редагувати санітизовану, безпечну підмножину CSS; стежте за проєктом TemplateStyles, у якому ведеться відповідна робота.

Чи стосується це також сторінок TemplateStyles .css?

Ні, лише сторінок CSS у просторі імен MediaWiki. Код CSS у TemplateStyles автоматично санітизується, щоб його не можна було використати в шкідливих цілях.

Чому не зосередитись на автоматичному запобіганні зловживанню правом редагування JavaScript?

Хоча в цьому напрямі є прогрес (наприклад, CSP та різні форми рецензування редагувань), вони ніколи не зможуть повністю запобігти атакам — неможливо повністю санітизувати мову програмування. Крім того, це значно складніше й потребує набагато більше зусиль. У короткостроковій перспективі зменшення кількості акаунтів, що можуть редагувати JavaScript, — найреальніший захід; у довгостроковій перспективі це слід поєднувати з іншими підходами.

А як щодо прав editusercss / edituserjs?

Ці (мало відомі й дуже рідко використовувані) права дозволяють редагування особистого CSS/JS іншого користувача. Оскільки це дозволяє викрасти акаунт цільового користувача, ті самі міркування застосовуються і ці права будуть обмежені таким самим чином. (У довгостроковій перспективі дивіться T197087.)

А як щодо нового права editsitejson?

Це право призначене для редагування сторінок .json у просторі імен MediaWiki (щось, що програмне забезпечення нещодавно навчилося обробляти особливим чином, і що призначене для конфігурації ґаджетів та ботів). JSON — це дані, а не код, тому його редагування не вважається небезпечним, і адміністратори як і раніше зможуть це робити; ґаджети мають бути написані так, щоб навіть нападник, який може керувати сторінками .json, не зміг їх скомпрометувати.