// Listen for messages from the web page window.addEventListener( “message”, (event) => { // Only accept messages from the same window if (event.source !== window) { return }

// Check if the message type is “FROM_PAGE” if (event.data.type && event.data.type === “FROM_PAGE”) { console.log(“Content script received: “ + event.data.text) // Forward the message to the background script port.postMessage({ type: “FROM_PAGE”, text: event.data.text }) } }, false )

// Listen for messages from the background script port.onMessage.addListener(function (msg) { console.log(“Content script received message from background script:”, msg) // Handle the response message from the background script })

</details>

Es ist auch möglich, Nachrichten von einem Hintergrundskript an ein Content-Skript in einem bestimmten Tab zu senden, indem man **`chrome.tabs.sendMessage`** aufruft, wobei die **ID des Tabs** angegeben werden muss, an den die Nachricht gesendet werden soll.

### Von erlaubten `externally_connectable` zur Erweiterung

**Web-Apps und externe Browser-Erweiterungen, die in der `externally_connectable`-Konfiguration erlaubt sind,** können Anfragen wie folgt senden:
```javascript
chrome.runtime.sendMessage(extensionId, ...

Wo es nötig ist, die extension ID zu erwähnen.

Native Messaging

Es ist möglich, dass die Hintergrundskripte mit Binärdateien im System kommunizieren, die anfällig für kritische Schwachstellen wie RCEs sein können, wenn diese Kommunikation nicht ordnungsgemäß gesichert ist. More on this later.

chrome.runtime.sendNativeMessage(
"com.my_company.my_application",
{ text: "Hello" },
function (response) {
console.log("Received " + response)
}
)

Web ↔︎ Content Script Kommunikation

Die Umgebungen, in denen content scripts laufen, und die, in denen Host-Seiten existieren, sind voneinander getrennt, was Isolation sicherstellt. Trotz dieser Isolation können beide mit dem gemeinsamen Document Object Model (DOM) der Seite interagieren. Damit die Host-Seite mit dem content script kommunizieren kann, oder indirekt mit der Erweiterung über das content script, muss sie das für beide zugängliche DOM als Kommunikationskanal nutzen.

Post Messages

// This is like "chrome.runtime.sendMessage" but to maintain the connection
var port = chrome.runtime.connect()

window.addEventListener(
"message",
(event) => {
// We only accept messages from ourselves
if (event.source !== window) {
return
}

if (event.data.type && event.data.type === "FROM_PAGE") {
console.log("Content script received: " + event.data.text)
// Forward the message to the background script
port.postMessage(event.data.text)
}
},
false
)

document.getElementById("theButton").addEventListener(
"click",
() => {
window.postMessage(
{ type: "FROM_PAGE", text: "Hello from the webpage!" },
"*"
)
},
false
)

Eine sichere Post Message-Kommunikation sollte die Authentizität der empfangenen Nachricht prüfen, das kann überprüft werden durch:

• event.isTrusted: Dies ist True nur, wenn das Event durch eine Benutzeraktion ausgelöst wurde
• Das Content Script könnte eine Nachricht nur erwarten, wenn der Benutzer eine Aktion ausführt
• origin domain: könnte Nachrichten nur von einer Allowlist von Domains erwarten
• Wenn ein regex verwendet wird, sei sehr vorsichtig
• Quelle: received_message.source !== window kann verwendet werden, um zu prüfen, ob die Nachricht aus demselben Fenster stammt, in dem das Content Script lauscht.

Die vorherigen Prüfungen könnten, selbst wenn sie durchgeführt werden, verwundbar sein — prüfe daher auf der folgenden Seite mögliche Post Message-Bypässe:

PostMessage Vulnerabilities

Iframe

Eine weitere mögliche Kommunikationsmethode können Iframe URLs sein, ein Beispiel findest du in:

BrowExt - XSS Example

DOM

Das ist nicht “genau” eine Kommunikationsmethode, aber das web und das Content Script haben Zugriff auf das web DOM. Wenn das Content Script also Informationen daraus liest und dem web DOM vertraut, könnte das web diese Daten modifizieren (weil das web nicht vertraut werden sollte oder weil das web für XSS anfällig ist) und damit das Content Script kompromittieren.

Ein Beispiel für ein DOM-basiertes XSS zum Kompromittieren einer browser extension findest du ebenfalls in:

BrowExt - XSS Example

Content Script ↔︎ Background Script Kommunikation

Ein Content Script kann die Funktionen runtime.sendMessage() oder tabs.sendMessage() verwenden, um eine einmalige JSON-serialisierbare Nachricht zu senden.

Um die response zu verarbeiten, verwende das zurückgegebene Promise. Aus Gründen der Abwärtskompatibilität kannst du jedoch weiterhin einen callback als letztes Argument übergeben.

Das Senden einer Anfrage aus einem content script sieht so aus:

;(async () => {
const response = await chrome.runtime.sendMessage({ greeting: "hello" })
// do something with response here, not outside the function
console.log(response)
})()

Senden einer Anfrage aus der extension (normalerweise aus einem background script). Beispiel, wie man eine Nachricht an das content script im ausgewählten Tab sendet:

// From https://stackoverflow.com/questions/36153999/how-to-send-a-message-between-chrome-extension-popup-and-content-script
;(async () => {
const [tab] = await chrome.tabs.query({
active: true,
lastFocusedWindow: true,
})
const response = await chrome.tabs.sendMessage(tab.id, { greeting: "hello" })
// do something with response here, not outside the function
console.log(response)
})()

Auf der Empfangsseite musst du einen runtime.onMessage Event-Listener einrichten, um die Nachricht zu verarbeiten. Das sieht vom content script oder extension page gleich aus.

// From https://stackoverflow.com/questions/70406787/javascript-send-message-from-content-js-to-background-js
chrome.runtime.onMessage.addListener(function (request, sender, sendResponse) {
console.log(
sender.tab
? "from a content script:" + sender.tab.url
: "from the extension"
)
if (request.greeting === "hello") sendResponse({ farewell: "goodbye" })
})

In dem hervorgehobenen Beispiel wurde sendResponse() synchron ausgeführt. Um den onMessage-Event-Handler für eine asynchrone Ausführung von sendResponse() zu ändern, ist es zwingend erforderlich, return true; zu verwenden.

Eine wichtige Überlegung ist, dass in Szenarien, in denen mehrere Seiten auf onMessage-Events hören, die erste Seite, die sendResponse() für ein bestimmtes Event ausführt, die einzige sein wird, die die Antwort effektiv liefern kann. Alle nachfolgenden Antworten auf dasselbe Event werden nicht berücksichtigt.

Beim Entwickeln neuer Extensions sollte die Präferenz auf promises statt callbacks liegen. Bei Verwendung von callbacks gilt die Funktion sendResponse() nur dann als gültig, wenn sie direkt im synchronen Kontext ausgeführt wird oder wenn der Event-Handler eine asynchrone Operation durch Zurückgeben von true anzeigt. Gibt keiner der Handler true zurück oder wird sendResponse() aus dem Speicher entfernt (garbage-collected), wird standardmäßig der Callback, der mit der Funktion sendMessage() verknüpft ist, ausgelöst.

Native Messaging

Browser extensions erlauben außerdem die Kommunikation mit binaries in the system via stdin. Die Anwendung muss dazu ein json installieren, das dies angibt, in einem json wie:

{
"name": "com.my_company.my_application",
"description": "My Application",
"path": "C:\\Program Files\\My Application\\chrome_native_messaging_host.exe",
"type": "stdio",
"allowed_origins": ["chrome-extension://knldjmfmopnpolahpmmgbagdohdnhkik/"]
}

Wobei name die Zeichenkette ist, die an runtime.connectNative() oder runtime.sendNativeMessage() übergeben wird, um von den Hintergrundskripten der Browser-Erweiterung mit der Anwendung zu kommunizieren. Der path ist der Pfad zur Binary, es gibt nur einen gültigen type, nämlich stdio (use stdin and stdout), und die allowed_origins geben die Extensions an, die darauf zugreifen dürfen (sie dürfen kein Wildcard enthalten).

Chrome/Chromium sucht dieses json in bestimmten Windows-Registry-Einträgen und in einigen Pfaden auf macOS und Linux (mehr Infos in den docs).

Tip

Die Browser-Erweiterung benötigt außerdem die deklarierte Berechtigung nativeMessaing, um diese Kommunikation nutzen zu können.

So sieht beispielhaft ein Hintergrundskript aus, das Nachrichten an eine native Anwendung sendet:

chrome.runtime.sendNativeMessage(
"com.my_company.my_application",
{ text: "Hello" },
function (response) {
console.log("Received " + response)
}
)

In this blog post, ein verwundbares Muster vorgeschlagen, das native messages missbraucht:

1. Browser Extension hat ein Wildcard-Pattern für content script.
2. content script leitet postMessage-Nachrichten an den background script weiter, indem es sendMessage verwendet.
3. background script sendet die Nachricht an die native application mittels sendNativeMessage.
4. native application verarbeitet die Nachricht unsicher, was zu code execution führt.

Und darin wird ein Beispiel erklärt, wie man von jeder Seite zu RCE gelangt, indem man eine browser extension ausnutzt.

Sensible Informationen in Memory/Code/Clipboard

Wenn eine Browser Extension sensible Informationen im Speicher ablegt, könnten diese (insbesondere auf Windows-Maschinen) ausgelesen und nach diesen Informationen durchsucht werden.

Daher sollte der Speicher der Browser Extension nicht als sicher angesehen werden und sensible Informationen wie Zugangsdaten oder mnemonic phrases sollten nicht gespeichert werden.

Natürlich sollten keine sensiblen Informationen im code abgelegt werden, da dieser öffentlich sein wird.

Um den Speicher des Browsers zu dumpen, können Sie den Prozessspeicher auslesen oder in die Einstellungen der Browser Extension gehen, auf Inspect pop-up klicken -> Im Memory-Bereich -> Take a snaphost und CTRL+F drücken, um im Snapshot nach sensiblen Informationen zu suchen.

Außerdem sollten hochsensible Informationen wie mnemonic keys oder Passwörter nicht in die clipboard kopiert werden dürfen (oder zumindest nach ein paar Sekunden aus der clipboard entfernt werden), da sonst Prozesse, die die clipboard überwachen, darauf zugreifen können.

Loading an Extension in the Browser

1. Herunterladen der Browser Extension und entpacken
2. Gehen Sie zu chrome://extensions/ und den Developer Mode aktivieren
3. Klicken Sie auf die Schaltfläche Load unpacked

In Firefox gehen Sie zu about:debugging#/runtime/this-firefox und klicken auf die Schaltfläche Load Temporary Add-on.

Getting the source code from the store

Der Quellcode einer Chrome extension kann auf verschiedenen Wegen beschafft werden. Nachfolgend sind detaillierte Erklärungen und Anweisungen für jede Option aufgeführt.

Download Extension as ZIP via Command Line

Der Quellcode einer Chrome extension kann per Kommandozeile als ZIP-Datei heruntergeladen werden. Dabei wird curl verwendet, um die ZIP-Datei von einer spezifischen URL zu holen und anschließend den Inhalt der ZIP-Datei in ein Verzeichnis zu extrahieren. Hier sind die Schritte:

1. Ersetzen Sie "extension_id" durch die tatsächliche ID der Extension.
2. Führen Sie die folgenden Befehle aus:

extension_id=your_extension_id   # Replace with the actual extension ID
curl -L -o "$extension_id.zip" "https://clients2.google.com/service/update2/crx?response=redirect&os=mac&arch=x86-64&nacl_arch=x86-64&prod=chromecrx&prodchannel=stable&prodversion=44.0.2403.130&x=id%3D$extension_id%26uc"
unzip -d "$extension_id-source" "$extension_id.zip"

CRX Viewer-Website verwenden

https://robwu.nl/crxviewer/

CRX Viewer-Erweiterung verwenden

Eine weitere praktische Methode ist die Verwendung des Chrome Extension Source Viewer, einem Open-Source-Projekt. Es kann aus dem Chrome Web Store installiert werden. Der Quellcode des Viewers ist in seinem GitHub repository verfügbar.

Quellcode einer lokal installierten Erweiterung anzeigen

Lokal installierte Chrome-Erweiterungen können ebenfalls inspiziert werden. So geht’s:

1. Greife auf dein lokales Chrome-Profilverzeichnis zu, indem du chrome://version/ aufrufst und das Feld “Profile Path” findest.
2. Navigiere zum Unterordner Extensions/ im Profilverzeichnis.
3. Dieser Ordner enthält alle installierten Erweiterungen, typischerweise mit ihrem Quellcode in lesbarer Form.

Um Erweiterungen zu identifizieren, kannst du ihre IDs den Namen zuordnen:

• Aktiviere den Entwicklermodus auf der about:extensions-Seite, um die IDs jeder Erweiterung zu sehen.
• Innerhalb des Ordners jeder Erweiterung enthält die Datei manifest.json ein lesbares name-Feld, das dir hilft, die Erweiterung zu identifizieren.

Dateiarchivprogramm oder Entpacker verwenden

Gehe zum Chrome Web Store und lade die Erweiterung herunter. Die Datei hat die Endung .crx. Ändere die Dateiendung von .crx zu .zip. Verwende ein beliebiges Archivprogramm (z. B. WinRAR, 7-Zip, etc.), um den Inhalt der ZIP-Datei zu entpacken.

Developer Mode in Chrome verwenden

Öffne Chrome und rufe chrome://extensions/ auf. Aktiviere oben rechts den “Developer mode”. Klicke auf “Load unpacked extension…”. Navigiere zu dem Verzeichnis deiner Erweiterung. Das lädt den Quellcode nicht herunter, ist aber nützlich, um den Code einer bereits heruntergeladenen oder entwickelten Erweiterung anzusehen und zu bearbeiten.

Chrome-Erweiterungs-Manifest-Datensatz

Um zu versuchen, verwundbare Browser-Erweiterungen zu finden, kannst du das https://github.com/palant/chrome-extension-manifests-dataset verwenden und deren manifest files auf potenziell verwundbare Hinweise prüfen. Zum Beispiel, um nach Erweiterungen mit mehr als 25000 Nutzern, content_scripts und der Berechtigung nativeMessaing zu suchen:

# Query example from https://spaceraccoon.dev/universal-code-execution-browser-extensions/
node query.js -f "metadata.user_count > 250000" "manifest.content_scripts?.length > 0 && manifest.permissions?.includes('nativeMessaging')"

Post-exploitation: Forced extension load & persistence (Windows)

Stealthy Technik, um Chromium zu backdooren, indem per-user Preferences direkt bearbeitet und gültige HMACs gefälscht werden, sodass der Browser eine beliebige unpacked extension ohne Aufforderungen oder Flags akzeptiert und aktiviert.

Forced Extension Load Preferences Mac Forgery Windows

Erkennung bösartiger Extension-Updates (statischer Versionsvergleich)

Supply-chain-Kompromittierungen treten häufig als bösartige Updates an zuvor harmlosen Extensions auf. Ein praktikabler, geräuscharmer Ansatz ist, ein neues Extension-Paket mit der zuletzt bekannten guten Version mittels statischer Analyse (zum Beispiel Assemblyline) zu vergleichen. Ziel ist, auf signalstarke Deltas statt auf jede Änderung zu alarmieren.

Workflow

• Reiche beide Versionen ein (alt + neu) beim selben static-analysis-Profil.
• Markiere neue oder aktualisierte background/service worker scripts (persistence + privileged logic).
• Markiere neue oder aktualisierte content scripts (DOM-Zugriff und Datensammlung).
• Markiere neu hinzugefügte permissions/host_permissions in manifest.json.
• Markiere neue Domains, extrahiert aus dem Code (potentielle C2-/exfil-Endpunkte).
• Markiere neue static-analysis-Detektionen (z. B. base64 decode, cookie harvesting, network-request builders, Obfuskationsmuster).
• Markiere statistische Anomalien wie starke Entropiesprünge oder Ausreißer-z-Scores in geänderten Skripten.

Skriptänderungen genau erkennen

• New script added → erkennen via manifest.json-Diff.
• Existing script modified (manifest unchanged) → vergleiche per-file hashes aus dem extrahierten Dateibaum (z. B. Assemblyline Extract-Output). Das fängt stealthy Updates an bestehenden Workern oder Content Scripts ab.

Detektionen vor Veröffentlichung

Um „Easy-Mode“-Detektionen auf Basis bereits bekannter IOCs zu vermeiden, deaktiviere threat-intel-fed Services und verlasse dich auf intrinsische Signale (Domains, heuristische Signaturen, Script-Deltas, Entropie-Anomalien). Das erhöht die Chancen, bösartige Updates vor öffentlicher Meldung zu entdecken.

Beispiel für Alarmlogik mit hoher Trefferwahrscheinlichkeit

• Low-noise combo: new domains + new static-analysis detections + updated background/service worker + updated or added content scripts.
• Broader catch: new domain + new or updated background/service worker (höhere Recall, mehr Noise).

Wichtige Assemblyline-Services für diesen Workflow:

• Extract: entpackt die Extension und liefert per-file hashes.
• Characterize: berechnet Dateieigenschaften (z. B. Entropie).
• JsJAWS / FrankenStrings / URLCreator: heben JS-Heuristiken, Strings und Domains hervor, um zwischen Versionen zu diffen.

Sicherheits-Audit-Checkliste

Auch wenn Browser Extensions eine begrenzte Angriffsfläche haben, können einige von ihnen Vulnerabilities oder Verbesserungspotenzial für Hardening enthalten. Die folgenden Punkte sind die häufigsten:

• Begrenze so weit wie möglich angeforderte permissions
• Begrenze so weit wie möglich host_permissions
• Nutze eine starke content_security_policy
• Begrenze so weit wie möglich das externally_connectable; wenn keins benötigt wird, lege standardmäßig {} fest
• Wenn hier eine URL genannt ist, die anfällig für XSS oder zur Übernahme geeignet ist, kann ein Angreifer direkt Nachrichten an die background scripts senden. Sehr mächtiger Bypass.
• Begrenze so weit wie möglich die web_accessible_resources, wenn möglich sogar leer.
• Wenn web_accessible_resources nicht leer ist, prüfe auf ClickJacking
• Wenn irgendeine Kommunikation von der Extension zur Webseite erfolgt, prüfe auf XSS-Vulnerabilities, die durch diese Kommunikation entstehen können (siehe XSS).
• Wenn Post Messages verwendet werden, prüfe auf Post Message vulnerabilities.
• Wenn das Content Script DOM-Details verwendet, prüfe, dass es keinen XSS einführt, falls die DOM-Inhalte durch die Webseite modifiziert werden.
• Lege besonderes Augenmerk auf die Content Script -> Background script-Kommunikation.
• Wenn der background script über native messaging kommuniziert, stelle sicher, dass die Kommunikation sicher und sanitized ist.
• Sensitive information sollte nicht im Code der Browser Extension gespeichert werden.
• Sensitive information sollte nicht im Speicher der Browser Extension gehalten werden.
• Sensitive information sollte nicht ungeschützt im Dateisystem gespeichert werden.

Risiken von Browser Extensions

• Die App https://crxaminer.tech/ analysiert einige Daten wie die permissions, die eine Browser Extension anfordert, um ein Risikoniveau für die Nutzung der Extension anzugeben.

Tools

Tarnish

• Lädt jede Chrome-Extension von einem angegebenen Chrome Webstore-Link herunter.
• manifest.json Viewer: zeigt eine JSON-prettified Version des Manifests an.
• Fingerprint Analysis: Detektion von web_accessible_resources und automatische Generierung von Chrome-Extension-Fingerprinting-JavaScript.
• Potentielle Clickjacking-Analyse: Erkennung von Extension-HTML-Seiten mit der web_accessible_resources-Direktive. Diese können abhängig vom Zweck der Seiten potentiell für Clickjacking anfällig sein.
• Permission Warning(s) viewer: zeigt eine Liste aller Chrome-Permission-Prompt-Warnungen, die beim Versuch, die Extension zu installieren, angezeigt werden.
• Dangerous Function(s): zeigt die Stellen gefährlicher Funktionen, die potenziell von einem Angreifer ausgenutzt werden können (z. B. innerHTML, chrome.tabs.executeScript).
• Entry Point(s): zeigt, wo die Extension Benutzereingaben/externe Eingaben annimmt. Nützlich, um die Angriffsfläche zu verstehen und mögliche Stellen zu finden, an die man bösartig gestaltete Daten senden kann.
• Sowohl die Dangerous Function(s)- als auch die Entry Point(s)-Scanner liefern für ihre Alerts:
  • Relevanten Codeausschnitt und die Zeile, die den Alert verursacht hat.
  • Beschreibung des Problems.
  • Einen „View File“-Button, um die vollständige Quelldatei anzusehen.
  • Den Pfad der gemeldeten Datei.
  • Die vollständige Chrome-Extension-URI der gemeldeten Datei.
  • Den Dateityp, z. B. Background Page script, Content Script, Browser Action etc.
  • Wenn die verwundbare Zeile in einer JavaScript-Datei ist, die Pfade aller Seiten, in denen sie eingebunden ist, sowie den Typ dieser Seiten und den web_accessible_resource-Status.
• Content Security Policy (CSP) analyzer and bypass checker: hebt Schwächen in der CSP der Extension hervor und zeigt mögliche Bypass-Wege aufgrund whitelisted CDNs etc.
• Known Vulnerable Libraries: nutzt Retire.js zur Prüfung auf bekannte verwundbare JavaScript-Bibliotheken.
• Download der Extension und formatierte Versionen.
• Download der Original-Extension.
• Download einer beautified Version der Extension (auto prettified HTML und JavaScript).
• Automatisches Caching der Scan-Ergebnisse; ein Extension-Scan benötigt beim ersten Mal Zeit, beim zweiten Mal (sofern die Extension nicht aktualisiert wurde) ist das Ergebnis nahezu sofort verfügbar.
• Linkbare Report-URLs, um anderen einfach einen Extension-Report von tarnish zu teilen.

Neto

Project Neto ist ein Python-3-Paket, entwickelt, um versteckte Features von Browser-Plugins und Extensions für bekannte Browser wie Firefox und Chrome zu analysieren und aufzudecken. Es automatisiert das Entpacken der Dateien, um diese Features aus relevanten Ressourcen einer Extension wie manifest.json, Lokalisierungsordnern oder Javascript- und HTML-Quell-Dateien zu extrahieren.

Referenzen

• Thanks to @naivenom for the help with this methodology
• https://www.cobalt.io/blog/introduction-to-chrome-browser-extension-security-testing
• https://palant.info/2022/08/10/anatomy-of-a-basic-extension/
• https://palant.info/2022/08/24/attack-surface-of-extension-pages/
• https://palant.info/2022/08/31/when-extension-pages-are-web-accessible/
• https://help.passbolt.com/assets/files/PBL-02-report.pdf
• https://developer.chrome.com/docs/extensions/develop/concepts/content-scripts
• https://developer.chrome.com/docs/extensions/mv2/background-pages
• https://thehackerblog.com/kicking-the-rims-a-guide-for-securely-writing-and-auditing-chrome-extensions/
• https://gist.github.com/LongJohnCoder/9ddf5735df3a4f2e9559665fb864eac0
• https://redcanary.com/blog/threat-detection/assemblyline-browser-extensions/

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

• Überprüfen Sie die Abonnementpläne!
• Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @hacktricks_live.
• Teilen Sie Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repos senden.