サイト全体 CSS/JS 編集用の別個の利用者グループの作成

Tracked in Phabricator:
Task T190015

問題点

管理者に与えられた非常に危険な権限: Common.js などのページを編集することで、何百万もの閲覧者や、何千もの編集者の閲覧端末上で即座にコードを実行することができます（同等の権限を有するインターフェース編集者も同様）。これは広く知られていますが、次のような悪用の可能性については、少数の人にしか理解されていません。

• 悪意のあるコードを閲覧者や編集者に送信すると、基本的にはあらゆる悪用、すなわちパスワードやクレジットカード番号のフィッシング、寄付のリダイレクト、編集者の特定、他の編集者名をかたる編集、マルウェアをインストールさせる罠を仕掛ける、迷惑通信の送信、他サイトに対する分散型サービス不能化攻撃の指揮などが行えます。
• 収益化できない他の危険な権能（チェックユーザーなど）と異なり、これは攻撃者に有益な標的となります。直近では、本権限の濫用によって閲覧者の端末上で仮想通貨の採掘が行われました。簡単に収益をあげようとする攻撃者を魅了し、さらに深刻な被害をもたらすものはこれにとどまりません。
• 被害は単一のウィキに限定されません。ウィキメディアのウィキ群では単一のログイン方式をグローバルに運用するため、特定のウィキで管理者権限が乗っ取られ不正利用が発生すると、他のウィキでも濫用され攻撃範囲の拡大を招いてしまいます。

このように悪意のある管理者やハッカーに管理者アカウントを盗まれると脅威が深刻なため、少しでも被害を抑える努力は惜しまずに実行する必要があります。これまで管理者アカウントの盗難がしばしば起きているのに大規模な事件が発生していないのは、ちょっとした奇跡と呼んでもよいくらいです。しかし運に頼ってばかりではいけません。

この問題にはまた、ウィキメディアのコミュニティには、自分たちのサイトの運用を自分たちで形作るという非常に意義深い能力があり、今後も保持するべきという面があります。編集者向けのガジェットは生産性を飛躍的に伸ばします。閲読者向けの修正により、ウィキメディアの何百というウィキ群で発生するさまざまな問題の解決や使用例に対応でき、中央集約化された開発過程ではとても真似ができません。外部の支援に依存するのと違って、ローカルに問題に対処できると、ウィキのコミュニティのやる気と能力を育てる重要な要素です。その意味でも、CSS/JavaScript 環境をどう扱うかは、ローカルコミュニティの裁量に任される必要があります。

対策

大多数の管理者はCSSやJavaScriptの編集をしたがらず、実行する権限も必要としていません。第一に専門用語の知識を求められても、ほとんどの管理者は知識がありません。サイト共通のJavaScriptやCSSのコードの編集の経験が既にある人（もしくはこれから始める意欲がある人）は除外するべきではありませんが、アカウント乗っ取りによる被害対策上、興味のない管理者には権限を与えるべきではありません。あるいはまた、JavaScript編集者を管理者より上位レベルもしくは厳しく監視したいコミュニティの場合（一般的に懸命な判断であり）、ウィキのソフトウェアの支援を頼むことを推奨します。

その実現に向け、新規に技術管理者の利用者グループを創設し、サイト共通のCSS/JSページの編集はこのグループに所属する人に限定する計画です。既定として参加者承認は、管理者の場合に準じてビューロクラットとスチュワードが行います。技術管理者を新任する手順の裁量は各ローカルの（当該のコミュニティが通常の手続きでグローバルな方針を決めている場合はグローバルなウィキメディアの）コミュニティに委任されます。

この方法の利点はいくつかあります。

• サイトに脅威を与える可能性のあるアカウントが量的に激減します。外部ウェブサイトのパスワードデータベースが被害を受けても、攻撃のベクトルになる可能性のあるアカウント数が少なければ、アカウントの脆弱性の確率は低くなります。（通常レベルの管理者にはアカウント盗難のリスクにさらされる心配が減るという意味です。）またアカウント数が少ないほど疑わしいログインの監視も楽になります。
• 単にアカウントが量的に減るばかりか、攻撃のベクトルになり得る最も脆弱性の高いアカウントが除外されるはずです。一般論としてCSS/JSコードを書ける利用者はIT能力が高めで、パスワード設定やシステムのセキュリティ保持の習慣が優れています。
• 将来的にはCSS/JS編集者に対するセキュリティ要件を厳格化し（2要素証明など）、その他の管理者でアカウント被害の脅威がそれほど高くない人全員の利便性を保つ方策を導入することも検討していきます。

技術面の利点は次の通りです。MediaWikiに新規の権限を1セット導入し（editsitecssとeditsitejs）、その目的はMediaWiki名前空間で.cssページもしくは.jsページの編集時に旧来のeditinterface権限と合わせて対応するeditsiteXXX権限を求めることです。（移行を円滑に進めるため）管理者ほか現状でeditinterface権限を有する利用者にはこの権限を期間限定で付与して、その権限が短期の移行期間後に失効すると、ソフトウェアにより技術管理者グループ以外のグループに対する権限承認は規制されます。

支援のお願い

• この協議期間の後の移行期間（おそらく2週間）には、技術管理者の利用者グループが存在するほか、通常の管理者もまだCSSとJSを編集できます。コミュニティにこの点を周知して、移行期間中にコミュニティから技術管理者グループに人を追加できること、追加するには人選のプロセス作りを完了する必要があることを伝えてください。（移行プロセスがどうあるべきかは個々のローカルコミュニティに委ねられます。単純に、この権限を求めた管理者全員を技術管理者グループに追加するという選択肢もあります。）
• さらにご利用のウィキで、移行期間中に新グループの人選の手順を決め、その文書化を必ず実行してください。繰り返しになりますが、簡単な方法なら、新任の管理者の皆さんに技術管理者を兼務したいか質問して、イエスであればJavascript やセキュリティの基本操作に詳しいかも尋ねるという選択肢もあります。いずれにせよ、技術管理者の選考基準は（信頼性と利用者行動について）通常の管理者と同等もしくは厳しくするよう推奨されています（詳細は利用者グループのページを参照してください。）
• CSS/JavaScript 編集のワークフローで、特別な権限が必要な部分を指定してください（技術管理者グループに付与される既定の権限の決定に活用するため）。一例として、ページ削除とか、コンテンツ見本の改訂の権限を与えますか？
• グループ名を募集中です。「技術管理者」よりもっとふさわしい名称があるはずです。命名の条件として、次の各点との紛らわしさを避けた名称でなければいけません。オフウィキのソースコード開発者ではないこと（MediaWiki開発者やToolforgeツールメンテナーなど）。Luaコード関連の担当ではないこと（Module名前空間）。インタフェース編集者グループとは所属が異なること（MediaWikiシステムメッセージの編集権限）。少なくとも、管理者と同等の人望のある権能だという点が伝わると理想的なのです。
• この文書で未検討の問題、あるいは今回の変更をより有効もしくは円滑に実行する修正案がありましたら、ぜひ提案をお待ちしています。

フィードバックは議論のページにお願いします。どの言語でも投稿を受け付けます。

よくある質問

この文書の文責は誰が負うのですか。

このページおよび対応するコードの執筆者はUser:Tgrです（ボランティアとして）。T190015ならびにwikitech-lの議論に基づき、MediaWiki開発者コミュニティの合意を得ていると判断しています。

これは「コメント依頼」なのですか？

コミュニティに変更の是非をお尋ねする意図があるかというと、そうではありません。賛否を問うものでもありません。ソフトウェアの安全に関する決定は編集者の合意ではなく、MediaWiki開発者コミュニティが統括しています。最終決定は通常どおり、コードリビューを介して行われます。以上をご確認の上、ぜひフィードバックをお寄せください！ 議論によりここで提示された方法以外の対策を行うべき理由が明らかになること、あるいは例えば新設する利用者グループにほかのどんな権限を付与すべきかなど、見落とせない細部を詰めることができるかもしれません。あるいはまたこのソフトウェア変更を各コミュニティで周知させるお役に立てると見込んでいます。

最近の一連の事件に対して、よく考えずに決めた対応策なのでは？

そうではありません。事件により今回の変更の重要性が強調されるなら望ましいのですが、基本概念は数年前から協議が続けられており、今回の協議の元となるパッチは3月に作成を開始しています。

もし実行されても、管理者がサイト共通のJavaScript を操作する手段は残ると見ています。

技術的に（難易度の高い）問題であり、ゆくゆくは解決すべきです。それでもやはりJavaScript 編集権限を管理者数名に限定すると、一般には知られていない特異的なハッキングに狙われる面を狭めることで、その他の脆弱性をずっと監視しやすくなります。

CSS 編集をJavaScript 編集と同列に扱っている理由は？

CSSはJavaScript より脅威度が低いとは言うものの、悪用されると被害が出ます。

• 画像関連のCSS属性の悪用により、編集者が特定されます。
• ブラウザのバージョンが低いものの中には、CSSにJavaScriptコードを埋め込む仕様のものがあります。
• CSSを使った編集トークンの盗用（自分以外の利用者の権限と名前を使って編集が可能）は可能ですが、現状ではブラウザのサポート外のため実行は限定されています。
• CSSによるクリックジャック攻撃（クリックジャッキング）はフィッシング詐欺の罠に悪用されることがあります。

データによるとCSSを日常的に編集する管理者のほとんど全員がJavaScript も同様に手がけるということであり、2つの問題を切り離して扱う合理性はありません。

将来的にはサニタイズ（無害化）した安全なCSSサブセットの編集が再び可能になるかもしれません。その方面でTemplateStylesプロジェクトが進行中で、進展に注目してはいかがでしょうか。

この変更でテンプレート関連のTemplateStyles .cssページにも影響が出ますか？

いいえ、対象はMediaWiki名前空間のCSSページだけです。TemplateStyles CSSコードは、脅威となる使われ方を予防するため、秘密にすべき情報を自動で削除してあります。

むしろJavaScriptの編集ができる人に不正行為をさせない自動処理を取り入れれば済むのでは？

その方面（例えばCSPあるいは編集レビュー関連）で進歩があるにせよ、攻撃を完全に予防することは不可能です - プログラム言語を完全にサニタイズ（無害化）するなどできないからです。しかもプログラム言語はずっと複雑で見直しには相当な労力が必要です。短期的な対策として最も実現可能性が高く環境への影響が最小なのは、JavaScript編集の権限を付与するアカウント数を減らす戦略です。長期的にはほかの戦略と並行して対策すべきでしょう。

editusercss/edituserjs権限は変更されますか？

これらの権限により（認知度が低く使用件数もごく少数ですが）、自分以外の利用者の個人的なCSS/JSを編集できます。狙った利用者のアカウント盗用も可能なため、本件の懸案事項と同等に扱われ制限を受けます（長期的な対応策はT197087で詳細を解説しています。）

新設されたeditsitejson権限に影響はありますか？

そちらはMediaWiki名前空間で.jsonページの編集を行う権限です（ソフトウェアの更新によりガジェットやボットの環境設定ページとして別個に対応を開始）。JSONはコードではなくデータであり編集しても脅威はないと判断されることから、管理者でも処理できます。ガジェットは、たとえ攻撃者が.jsonページを制御できてもガジェットを破壊できないように記述の内容に注意してください。