Chrome拡張機能権限のアーキテクチャ:深掘り

Chrome拡張機能 ブラウザの機能を強化する非常に人気のあるツールです。おそらく多くの拡張機能をインストールしているでしょう。これらの拡張機能はパスワードの保存、タブの管理、入力中の単語変更、広告のブロックなど、通常のウェブサイトセキュリティモデルを超えることができます。ブラウザが保存する機密データや個人情報(閲覧履歴、パスワード、銀行認証情報など)を考えると、ブラウザは拡張機能のセキュリティをどのように確保しているのでしょうか?今回の投稿では、Chrome拡張機能の許可システムについて説明します.

この投稿では、 マニフェスト V3(MV3), 現在のChrome拡張機能権限システムです。Manifest V2(MV2)はよりシンプルでしたが、現在は非推奨化されており、今後はサポートされなくなります.

基本:マニフェストファイル

すべてのChrome拡張機能には マニフェストファイル (manifest.json)には、拡張機能の名前、バージョン、必要な権限などの基本情報が含まれています。例えば、拡張機能はクッキーの読み取り、ブックマークへのアクセス、ダウンロード管理、音声再生、プリンターの使用など、多くのことを要求できます.

以下はマニフェストファイルの見た目の一部です:

アーチクロームイメージ2

特に重要な権限の種類(content_scriptsブロック内で)は以下の通りです ホスト権限, これによりChrome拡張機能を注入できます コンテンツスクリプト 特定のURLセットにマッチするウェブサイトに変換します。これはすべてのウェブサイトで実行される場合もあれば、特定のウェブサイトだけで実行される場合もあります(例:YouTube専用の拡張機能を開発している場合、YouTubeウェブサイトにコンテンツスクリプトを注入すれば十分でしょう)。拡張機能をインストールすると、ユーザーには拡張機能がこれらの権限で何をできるかを説明する警告ダイアログが表示されます.

アーチクロームイメージ1

例えば、拡張機能が “訪問するウェブサイトのすべてのデータを読み、変更してください.” これは一見不安に思えるかもしれませんが、拡張機能がウェブサイトにJavaScriptを注入すれば、理論上はどのページのコンテンツも読み書きできる可能性があるため、必要なことです。ブラウザはスクリプトが何をしているのか正確には分からないので、最悪のシナリオしか想定できません.

Chrome拡張機能の構成要素

Chrome拡張機能は単なる一つの統一された存在ではなく、複数の部分で構成されており、それぞれの部分が異なる権限を持っています。最も重要な3つの要素は コンテンツスクリプト、ポップアップページ、バックグラウンドサービスワーカー.

アーチクロームイメージ8

DevToolsページ、オプションページ、Omniboxなどの追加コンポーネントもありますが、この投稿では主に3つのコンポーネントに焦点を当てます。これらのパーツは次のように通信します メッセージパッシング WebExtensions APIを通じて。各要素を分解して見ていきましょう.

コンテンツスクリプト

コンテンツスクリプト Chrome拡張機能の中で唯一、ウェブページのDOMとやり取りできる部分です。例えば、コンテンツスクリプトはページの背景色を青に変更することができます。しかし、マニフェストファイルで権限が付与されていても、より高い権限を持つChrome APIにはアクセスできません。代わりに、コンテンツスクリプトは拡張の他の部分、通常は 背景サービスワーカー, 権限が高まる作業を遂行すること.

コンテンツスクリプトは本質的に低権限システムです。彼らはページDOMにアクセスし、UIを直接ページ上に表示し、他のコンポーネントにメッセージを送信できます.

しかし、彼らはChromeのAPIにアクセスしたり、データを自由に取得したりすることはできません(CORSおよびCSPポリシーにより制限されています)).

背景サービスワーカー

サービス労働者 バックグラウンドで動作し、拡張機能が権限を持つすべてのChrome API(タブやブックマークなど)にアクセスできます.

どのウェブページのDOMにも操作できず、UIも表示できません。これらは拡張内の他の部分からのイベントにのみ応答でき、制限時間稼働した後はシャットダウンします.

主な役割は、他のコンポーネント、Chrome API、バックエンドサーバー間でメッセージを中継することです.

ポップアップページ

ポップアップページ ブラウザのツールバーアイコンをクリックしてトリガーした拡張機能のユーザーインターフェースを提供します。これらはユーザーがツールバーボタンをクリックすることでのみトリガーでき、他の方法(例:プログラム的またはユーザーの操作に応じて)を開くことはできません).

アーチクロームイメージ7

これらのページはChrome APIへのアクセス権限を持っていますが、サービスワーカーと同様にウェブページのDOMとやり取りすることはできません.

権限の概要

Chrome拡張機能の各コンポーネントには独自の権限と制限があります。簡単にまとめます:

アーチクロームイメージ5

Chrome拡張機能はこれらの部分を調整しなければなりません メッセージパッシング, これにより、データが安全に転送され、適切なコンポーネントでタスクが実行されることが保証されます.

例:AIサマライザー拡張

AIを使って現在のページを要約するChrome拡張機能の例を見てみましょう。この拡張機能をどのように設計すればよいかをご紹介します:

  1. ユーザーはポップアップウィンドウを通じてアクションをトリガーします.

  2. ポップアップウィンドウはページに注入されたコンテンツスクリプトにメッセージを送信します.

  3. コンテンツスクリプトはページのDOMを読み取りますが、バックエンドのリクエストはできないため、サービスワーカーにメッセージを送信します.

  4. サービスワーカーはバックエンドのAIモデルからデータを取得し、その要約をコンテンツスクリプトに返します.

  5. 最後に、コンテンツスクリプトはページのDOMを更新し、AI生成の要約を表示します.

アーチクロームイメージ4

この多段階のプロセスは、Chrome拡張機能開発者が権限制約を回避するためにメッセージパッシングを使う典型的な例です.

コンテンツセキュリティポリシー(CSP))

Chrome拡張機能が直面する一般的な制限の一つは、 コンテンツセキュリティポリシー(CSP)). CSPは、ウェブサイトがレスポンスヘッダーを通じてどのリソースや操作を許可するかを制御するセキュリティ機能です。CSPの一般的な例は以下の通りです。:

  • script-src: JavaScript を読み込める場所を制限します.

  • img-src: 画像の読み込み場所を制限します.

  • frame-src:要素に埋め込めるURLを制限します<iframe>.

  • connect-src:ブラウザがfetchを使ってリクエストを送信できる範囲を制限します().

コンテンツスクリプトはウェブページと同じ環境で実行されるため、ページのCSP制限の対象となります。つまり、一部のウェブサイト(例:GitHub)では、コンテンツスクリプトで開始されたフェッチリクエストがCSPによって失敗することがありますが、同じリクエストは他のウェブサイト(例:ウィキペディア)では動作するかもしれません).

すべてのウェブサイトで動作する拡張機能の場合、CSPによってブロックされるアクションは、少なくとも一部のウェブサイトではブロックされると考えられます。拡張の一般的な操作は、fetch() リクエストを通じてバックエンドと通信することです。したがって サービスワーカーを通じたプロキシフェッチリクエストの送信 これらの制限を回避するために必要です。サービスワーカーはページのCSPとは独立して動作し、制限のないフェッチリクエストを行うことができます.

マニフェストVにおける評価禁止3

Manifest V3で導入されたもう一つの重要な制限は、eval()や同等の構成文(例えば:

  • 関数を使った新しい関数の作成().

  • 正則表現における特定のパターンの使用.

  • スクリプトタグ付きのCDNからスクリプトを動的に読み込む方法.

  • ウェブワーカーのマルチスレッド利用.

アーチクロームイメージ3

eval() は現代のJavaScriptではあまり使われていませんが、特にサードパーティの依存関係ではその同等のものがより頻繁に現れます。この制限に対応するため、Chromeは特別なものを導入しました サンドボックスページ. このサンドボックスはChrome APIの使用権限がなく、他のページのDOMにはアクセスできませんが、評価は実行できます.

サンドボックスの仕組みは、評価や類似の構造を使うライブラリやコードを特別なサンドボックスページ内に配置しなければならないというものです。サンドボックスページと拡張機能の他の部分間で、入力と出力を(予想通り)より多くのメッセージパッシングで転送しなければなりません.

これが問題になる理由はおそらく理解できるでしょう。依存関係を通じて間接的であっても、評価や類似の構造を呼び出すライブラリは、サンドボックスページに隔離されなければなりません。このリファクタリングは非常に困難であり、特に評価の利用がフレームワークに深く組み込まれている場合はなおさらです.

これらの課題のため、多くの人気ライブラリはChrome拡張機能との互換性を確保するために評価に似た構造の使用を避ける措置を講じていますが、必ずしもそうとは限りません。このような場合、パッケージのGitHubリポジトリで問題を提起するのが正直なところ最善の解決策かもしれません.

なぜChrome拡張機能のセキュリティはこんなに複雑なのか?

Chrome拡張機能がどのようにして現在のセキュリティアーキテクチャに至ったのか気になるなら、その理由は驚くかもしれません。その理由は以下の通りです。 Googleからのこの論文. Chrome拡張機能のセキュリティモデルは、悪意ある拡張機能からユーザーを守ることを目的としていません。もし拡張機能が悪意ある場合、誰にもできることはほとんどありません。ユーザーはインストール前に警告を受けますが、多くの場合はインストールを続けます.

代わりに、Chromeのセキュリティモデルは拡張機能が 悪意はありませんが、セキュリティ上の脆弱性がある可能性があります. この前提は妥当です。なぜなら、ほとんどの拡張機能はセキュリティの専門家でない平均的な開発者によって作成されているからです。これらの安全でない拡張機能は、悪意のあるウェブサイトの標的となり得ます。悪意あるウェブサイトは、コンテンツスクリプトの脆弱性を悪用して特権APIにアクセスしようとします.

例えば、悪意のあるウェブサイトが拡張機能を騙して悪意のあるスクリプトを実行しようとすることがあります。ウィンドウオブジェクトの関数を独自の関数に置き換え、拡張が呼び出すと攻撃者の任意のコードを実行するなど、多くの攻撃ベクトルがあります.

アーチクロームイメージ6

これらのリスクを軽減するため、Chrome拡張機能は2つの異なる権限レベルに分けられています:

  1. コンテンツスクリプト(低権限)): これらはウェブページのDOMやプロセスと同じ環境を共有しています。彼らは信頼できないウェブサイトのコードとやり取りしますが、権限やアクセスは限定的です.

  2. 拡張コア(高権限): これにはポップアップページやバックグラウンドサービスワーカーが含まれ、ストレージ、タブ、ブックマークなどの強力なChromeのAPIへのアクセスを保持します。これらはコンテンツスクリプトからプロセス的に隔離されており、通信はメッセージの伝達(文字列のみ、共有オブジェクトなし)に限定されています).

特権を分離することで、攻撃者はまずコンテンツスクリプトの脆弱性を突き、それを騙して高特権のバックグラウンドスクリプトに悪意のあるメッセージを送信させます。しかし、たとえこれが実現しても、eval()は拡張内で完全に無効化されるため、任意のコード実行ははるかに困難になります.

これらの仕組みを合わせると、Chrome拡張機能の悪用が著しく難しくなります.