Google Chromeは、拡張機能の仕組みを大きく変える「Manifest V3（MV3）」への移行を進めています。これは広告ブロックなどの機能を制限し、よりセキュアで効率的なブラウザを目指す動きの一環です。しかしこの移行の中で、広告ブロックを可能にする「webRequestBlocking API」が使用できなくなることで、広告ブロッカーが実質的に機能しなくなるとの懸念が広がっていました。
🧠 Manifest V3がもたらす制限とは？
Manifest V3では、従来利用可能だった webRequest.onBeforeRequest によるリクエストブロックが制限され、代替として declarativeNetRequest が導入されました。これにより、拡張機能はWebリクエストをリアルタイムで柔軟に制御できなくなり、広告ブロッカーにとっては致命的な制限となります。
特に、動的なルール追加やユーザー設定に応じたフィルタリングが難しくなるため、多くの広告ブロック拡張の開発者がMV3に対して批判を強めていました。
🔍 バグによる回避策が発見された経緯
そんな中、2023年にセキュリティ研究者のDerin Eryılmaz氏が、Manifest V3の制限を回避して「webRequestBlocking」を有効にするバグを発見しました。彼はこの手法を「Googleの広告ブロック対策アップデートを回避する抜け道」と表現し、詳細を自身のブログで公開しました。
その手法の鍵となるのが、Chromeの内部でJavaScriptとC++がAPIを橋渡しする「バインディング」の仕組みです。Chromeの多くのAPIはC++で厳重に管理されていますが、一部の古いAPIでは依然としてJavaScriptバインディングが使われており、これがセキュリティの盲点となっていました。
💥 偽イベントオブジェクトを使った攻撃手法
発見されたバグでは、chrome.webRequest.onBeforeRequest の偽のイベントを作成し、その際に opt_webViewInstanceId という本来は無効となるべきパラメータを設定することで、MV3の制限を突破できる状態になっていました。
このIDは、かつて廃止されたChromeアプリで使用されていたもので、本来の目的とは異なる形で残存していたことが今回のバグにつながったのです。
驚くべきことに、これにより通常の拡張機能でもwebRequestBlockingを有効にし、広告ブロッカーとして正常に機能させることができてしまったというわけです。
🛠 Googleによる対応と修正
Eryılmaz氏はこの問題を2023年8月にGoogleに報告。結果として、このバグはChrome 118で修正され、opt_webViewInstanceId を含むイベントが不正に使用されないよう検証処理が追加されました。
ただし、Googleはこの問題をセキュリティ上の深刻な脆弱性とは見なさず、通常提供されるバグ報奨金（バグバウンティ）は支払われませんでした。
一方、同氏が同年に発見した別の脆弱性（CVE-2023-4369）については、報奨金として1万ドル（約145万円）が支払われたとのことです。
💬 今回のケースが示す教訓
今回の事例は、以下のような重要なポイントを浮き彫りにしました：
- Manifest V3の導入により広告ブロック機能が抑制されつつあること
- 古いコードベースが思わぬ脆弱性を残すリスクがあること
- 正規の手続きを踏まない方法での回避策は脆弱であると同時に、すぐに修正対象となること
Eryılmaz氏の報告は、セキュリティの観点からも開発者コミュニティに多くの示唆を与えるものでした。
📝 今後、広告ブロック機能のあり方や、ユーザーのプライバシー保護とのバランスがますます重要な議論になっていくでしょう。拡張機能の進化と共に、そのセキュリティ体制や透明性の確保にも注目が集まります。
