概要
- Google Chrome が Manifest V2 （MV2）から Manifest V3 （MV3）へ移行
- MV3 で adblocker などの拡張機能に影響
- webRequestBlocking 権限の廃止とそのバグ
- JavaScriptバインディング の脆弱性利用例
- バグ報告と 修正対応、報酬の話
Chrome Manifest V3とAdblocker問題
- MV は Manifest Version の略称
- MV3 導入により、拡張機能の webRequestBlocking 権限が廃止
- webRequestBlocking は、リクエスト内容に応じて 動的に通信をブロック する機能
- adblocker はこの権限に依存しており、MV3で 機能制限 を受ける
- Google が広告収入主体であるため、意図的な変更と見る声も
Chrome拡張APIのJavaScriptバインディングの歴史
- Chrome本体 は C++ で記述
- 拡張機能は JavaScript で記述し、API呼び出しもJS風
- かつては「 extension binding modules」というJSファイルをページに注入
- グローバル関数やプロトタイプの 上書き で XSS脆弱性 が多発（2015〜2016年）
- Google はその後、APIバインディングの多くを C++ へ移行
- ただし一部は現在も JavaScriptバインディング を使用
webRequest APIの特殊性とバグ概要
- chrome.webRequest APIは今も JavaScriptバインディング 利用
- 本来、MV3では blocking オプションが使えず、 cancel: true は無効化
- しかし、 webRequestEvent のラッパークラスの constructor が公開状態
- 独自イベントを生成可能
- 例：
let fooEvent = new WebRequestEvent("foo")
- 例：
- opt_webViewInstanceId パラメータを悪用し、 webRequestBlocking の権限チェックを回避可能
- 本来は Platform Apps 用の仕組み
- イベント名やIDを偽装し、 blocking 機能を利用できるバグ
バグの実例コード
- 偽装イベント 生成例
let fakeEvent = new WebRequestEvent("webRequest.onBeforeRequest", 0, 0, 0, 1337)fakeEvent.addListener(() => { return { cancel: true } }, { urls: ['*://*.example.com/*'] }, ['blocking'])
- Platform Apps は2020年に廃止済みだが、2025年時点でもコードが残存
バグの影響と修正対応
- このバグを使えば、 MV3 でも adblocker が完全動作可能
- 報告者は2023年に Google へ報告、 Chrome 118 で修正
- opt_webViewInstanceId 利用時に WebView権限 チェックを追加
- 報酬は 0ドル （セキュリティ上の重大性が低いと判断）
- 脆弱性 の本質は、 古いコード の残存によるもの
総括・教訓
- 数行のコード で大規模なアップデートの回避が可能な事例
- 古い設計 や レガシーコード のリスク
- 興味深い脆弱性体験談として紹介
参考・関連情報
- さらに興味があれば、同年に発見された Chrome拡張バグ （CVE付き・1万ドル報酬）の記事も参照推奨