// 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>

Il est aussi possible d'envoyer des messages depuis un background script vers un content script situé dans un onglet spécifique en appelant **`chrome.tabs.sendMessage`** où vous devrez indiquer l'**ID de l'onglet** auquel envoyer le message.

### Depuis un `externally_connectable` autorisé vers l'extension

**Les web apps et les browser extensions externes autorisés** dans la configuration `externally_connectable` peuvent envoyer des requêtes en utilisant :
```javascript
chrome.runtime.sendMessage(extensionId, ...

Là où il est nécessaire de mentionner l’extension ID.

Native Messaging

Il est possible pour les background scripts de communiquer avec des binaires à l’intérieur du système, ce qui pourrait être sujet à des vulnérabilités critiques telles que des RCEs si cette communication n’est pas correctement sécurisée. Plus d’informations plus tard.

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

Communication ↔︎ Web Script de contenu

Les environnements dans lesquels les content scripts opèrent et où les pages hôtes existent sont séparés les uns des autres, garantissant l’isolation. Malgré cette isolation, les deux ont la capacité d’interagir avec le Document Object Model (DOM) de la page, une ressource partagée. Pour que la page hôte puisse communiquer avec le content script, ou indirectement avec l’extension via le content script, il est nécessaire d’utiliser le DOM accessible aux deux parties comme canal de communication.

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
)

Une communication Post Message sécurisée devrait vérifier l’authenticité du message reçu, cela peut se faire en vérifiant :

• event.isTrusted : Cela est True uniquement si l’événement a été déclenché par une action de l’utilisateur
• Le content script peut s’attendre à un message uniquement si l’utilisateur effectue une certaine action
• origin domain : peut s’attendre à ce qu’un message ne soit autorisé que depuis une allowlist de domaines.
• Si une regex est utilisée, soyez très prudent
• Source : received_message.source !== window peut être utilisé pour vérifier si le message provenait de la même fenêtre où le Content Script écoute.

Les vérifications précédentes, même si elles sont effectuées, pourraient être vulnérables, alors consultez la page suivante pour les potential Post Message bypasses :

PostMessage Vulnerabilities

Iframe

Une autre façon possible de communication pourrait passer par des Iframe URLs, vous pouvez trouver un exemple dans :

BrowExt - XSS Example

DOM

Ce n’est pas une façon de communication exactement, mais le web et le content script auront accès au web DOM. Donc, si le content script lit certaines informations à partir de celui-ci, en faisant confiance au web DOM, le web pourrait modifier ces données (parce que le web ne devrait pas être digne de confiance, ou parce que le web est vulnérable à XSS) et compromettre le Content Script.

Vous pouvez également trouver un exemple de DOM based XSS pour compromettre une browser extension dans :

BrowExt - XSS Example

Content Script ↔︎ Background Script Communication

Un Content Script peut utiliser les fonctions runtime.sendMessage() ou tabs.sendMessage() pour envoyer un message one-time JSON-serializable.

Pour gérer la response, utilisez le Promise retourné. Cependant, pour la compatibilité ascendante, vous pouvez toujours passer un callback comme dernier argument.

L’envoi d’une requête depuis un content script ressemble à ceci :

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

Envoyer une requête depuis l’extension (généralement un background script). Exemple d’envoi d’un message au content script dans l’onglet sélectionné :

// 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)
})()

Du côté récepteur, vous devez configurer un écouteur d’événements runtime.onMessage pour traiter le message. Cela se présente de la même manière depuis un content script ou une page d’extension.

// 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" })
})

Dans l’exemple mis en évidence, sendResponse() a été exécuté de manière synchrone. Pour modifier le gestionnaire d’événement onMessage afin d’exécuter sendResponse() de façon asynchrone, il est impératif d’ajouter return true;.

Un point important à considérer est que, dans les scénarios où plusieurs pages sont configurées pour recevoir des événements onMessage, la première page à exécuter sendResponse() pour un événement spécifique sera la seule à pouvoir fournir la réponse efficacement. Toute réponse ultérieure au même événement ne sera pas prise en compte.

Lors de la création de nouvelles extensions, il faut privilégier les promises plutôt que les callbacks. Concernant l’utilisation des callbacks, la fonction sendResponse() n’est considérée comme valide que si elle est exécutée directement dans le contexte synchrone, ou si le gestionnaire d’événement indique une opération asynchrone en renvoyant true. Si aucun des gestionnaires ne renvoie true ou si la fonction sendResponse() est supprimée de la mémoire (garbage-collected), le callback associé à la fonction sendMessage() sera déclenché par défaut.

Native Messaging

Les browser extensions permettent aussi de communiquer avec des binaires dans le système via stdin. L’application doit installer un json indiquant cela dans un json comme :

{
"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/"]
}

Où name est la chaîne passée à runtime.connectNative() ou runtime.sendNativeMessage() pour communiquer avec l’application depuis les background scripts de l’extension browser. Le path est le chemin vers le binaire, il n’existe qu’un seul type valide qui est stdio (use stdin and stdout) et allowed_origins indique les extensions qui peuvent y accéder (et ne peut pas avoir de wildcard).

Chrome/Chromium recherchera ce json dans certaines windows registry et dans certains paths sur macOS et Linux (plus d’informations dans les docs).

Tip

L’extension browser a aussi besoin de la permission nativeMessaing déclarée afin de pouvoir utiliser cette communication.

Voici à quoi ressemble du code de background script envoyant des messages à une native application :

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

Dans ce billet de blog, un pattern vulnérable abusant des native messages est proposé :

1. L’extension browser a un wildcard pattern pour le content script.
2. Le content script passe des messages postMessage au script de fond en utilisant sendMessage.
3. Le script de fond passe le message à l’application native en utilisant sendNativeMessage.
4. L’application native gère le message de manière dangereuse, menant à l’exécution de code.

Et à l’intérieur, un exemple de passer de n’importe quelle page à RCE en abusant d’une browser extension est expliqué.

Sensitive Information in Memory/Code/Clipboard

Si une Browser Extension stocke des informations sensibles dans sa mémoire, celles-ci pourraient être dumped (surtout sur des machines Windows) et searched pour ces informations.

Par conséquent, la mémoire de la Browser Extension ne devrait pas être considérée comme sûre et les informations sensibles telles que des credentials ou des mnemonic phrases ne devraient pas être stockées.

Bien sûr, n’insérez pas d’informations sensibles dans le code, car elles seront publiques.

Pour dumper la mémoire du navigateur, vous pouvez dump le process memory ou aller dans les settings de la browser extension, cliquer sur Inspect pop-up -> dans la section Memory -> Take a snaphost et CTRL+F pour rechercher des informations sensibles dans le snapshot.

De plus, les informations hautement sensibles comme les mnemonic keys ou les passwords ne devraient pas pouvoir être copiées dans le clipboard (ou au moins être retirées du clipboard après quelques secondes) car des processus surveillant le clipboard pourront alors les récupérer.

Loading an Extension in the Browser

1. Download la Browser Extension & unzipped
2. Allez dans chrome://extensions/ et activez le Developer Mode
3. Cliquez sur le bouton Load unpacked

Dans Firefox, allez dans about:debugging#/runtime/this-firefox et cliquez sur le bouton Load Temporary Add-on.

Getting the source code from the store

Le source code d’une extension Chrome peut être obtenu via différentes méthodes. Ci-dessous se trouvent des explications détaillées et des instructions pour chaque option.

Download Extension as ZIP via Command Line

Le source code d’une extension Chrome peut être téléchargé sous forme de fichier ZIP en utilisant la command line. Cela implique d’utiliser curl pour récupérer le fichier ZIP depuis une URL spécifique, puis d’extraire le contenu du fichier ZIP vers un répertoire. Voici les étapes :

1. Remplacez "extension_id" par l’ID réel de l’extension.
2. Exécutez les commandes suivantes :

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"

Utiliser le site CRX Viewer

https://robwu.nl/crxviewer/

Utiliser l’extension CRX Viewer

Une autre méthode pratique consiste à utiliser Chrome Extension Source Viewer, qui est un projet open-source. Il peut être installé depuis le Chrome Web Store. Le code source du viewer est disponible dans son dépôt GitHub.

Voir le code source d’une extension installée localement

Les extensions Chrome installées localement peuvent aussi être inspectées. Voici comment :

1. Accédez au répertoire local du profil Chrome en visitant chrome://version/ et en localisant le champ “Profile Path”.
2. Naviguez vers le sous-dossier Extensions/ dans le répertoire du profil.
3. Ce dossier contient toutes les extensions installées, généralement avec leur code source dans un format lisible.

Pour identifier les extensions, vous pouvez faire correspondre leurs ID à leurs noms :

• Activez le Developer Mode sur la page about:extensions pour voir les ID de chaque extension.
• Dans le dossier de chaque extension, le fichier manifest.json contient un champ name lisible, ce qui vous aide à identifier l’extension.

Utiliser un archiveur de fichiers ou un décompresseur

Allez sur le Chrome Web Store et téléchargez l’extension. Le fichier aura une extension .crx. Changez l’extension du fichier de .crx à .zip. Utilisez n’importe quel archiveur de fichiers (comme WinRAR, 7-Zip, etc.) pour extraire le contenu du fichier ZIP.

Utiliser le Developer Mode dans Chrome

Ouvrez Chrome et allez sur chrome://extensions/. Activez “Developer mode” en haut à droite. Cliquez sur “Load unpacked extension…”. Naviguez vers le répertoire de votre extension. Cela ne télécharge pas le code source, mais c’est utile pour visualiser et modifier le code d’une extension déjà téléchargée ou développée.

Chrome extension manifest dataset

Afin d’essayer de repérer des browser extensions vulnérables, vous pouvez utiliser lehttps://github.com/palant/chrome-extension-manifests-dataset et vérifier leurs fichiers manifest à la recherche de signes potentiellement vulnérables. Par exemple, pour vérifier les extensions avec plus de 25000 users, content_scripts et la permission nativeMessaing:

# 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)

Technique furtive pour backdoor Chromium en modifiant directement les Preferences par utilisateur et en forgeant des HMAC valides, ce qui amène le navigateur à accepter et activer une extension unpacked arbitraire sans prompt ni flags.

Forced Extension Load Preferences Mac Forgery Windows

Détection des mises à jour malveillantes d’extensions (Static Version Diffing)

Les compromissions de supply-chain arrivent souvent sous forme de mises à jour malveillantes d’extensions jusque-là bénignes. Une approche pratique et discrète consiste à comparer un nouveau package d’extension avec la dernière version connue comme saine à l’aide d’une analyse statique (par exemple, Assemblyline). L’objectif est d’alerter sur des deltas à fort signal plutôt que sur n’importe quel changement.

Workflow

• Soumettre les deux versions (ancienne + nouvelle) au même profil d’analyse statique.
• Signaler les nouveaux scripts background/service worker ou mis à jour (persistence + logique privilégiée).
• Signaler les nouveaux content scripts ou mis à jour (accès au DOM et collecte de données).
• Signaler les nouvelles permissions/host_permissions ajoutées dans manifest.json.
• Signaler les nouveaux domaines extraits du code (potentiels points de C2/exfil).
• Signaler les nouvelles détections d’analyse statique (par exemple, décodage base64, collecte de cookies, générateurs de requêtes réseau, patterns d’obfuscation).
• Signaler les anomalies statistiques comme de fortes hausses d’entropie ou des z-scores aberrants dans les scripts modifiés.

Détecter précisément les changements de script

• Nouveau script ajouté → détecté via le diff de manifest.json.
• Script existant modifié (manifest inchangé) → comparer les hashs par fichier depuis l’arborescence extraite des fichiers (par exemple, la sortie Extract d’Assemblyline). Cela permet de détecter les mises à jour furtives de workers ou de content scripts existants.

Détections avant divulgation

Pour éviter des détections en “easy mode” basées sur des IOCs déjà connus, désactivez les services alimentés par threat-intel et fiez-vous aux signaux intrinsèques (domains, signatures heuristiques, deltas de scripts, anomalies d’entropie). Cela augmente les chances de détecter des mises à jour malveillantes avant les signalements publics.

Exemple de logique d’alerte à forte confiance

• Combo faible bruit: nouveaux domains + nouvelles détections d’analyse statique + background/service worker mis à jour + content scripts mis à jour ou ajoutés.
• Détection plus large: nouveau domain + background/service worker nouveau ou mis à jour (rappel plus élevé, bruit plus élevé).

Services Assemblyline clés pour ce workflow :

• Extract: décompresse l’extension et fournit des hashs par fichier.
• Characterize: calcule les caractéristiques des fichiers (par exemple, l’entropie).
• JsJAWS / FrankenStrings / URLCreator: font ressortir les heuristiques JS, les strings et les domains à différencier entre versions.

Security Audit Checklist

Même si les Browser Extensions ont une surface d’attaque limitée, certaines peuvent contenir des vulnerabilities ou des améliorations de hardening potentielles. Les suivantes sont les plus courantes :

• Limiter autant que possible les permissions demandées
• Limiter autant que possible les host_permissions
• Utiliser une forte content_security_policy
• Limiter autant que possible les externally_connectable ; si rien n’est nécessaire et possible, ne pas le laisser par défaut, spécifier {}
• Si une URL vulnérable à XSS ou à takeover est mentionnée ici, un attaquant pourra envoyer des messages directement aux scripts background. Bypass très puissant.
• Refuser les wildcard ou les suffix trust comme *.example.com pour les gestionnaires de messages externes privileged.
• Vérifier si une origin autorisée sert des vendor-hosted widgets, du user content, ou des legacy assets versionnés qui pourraient restaurer l’exécution de code sur un sous-domaine de confiance.
• Limiter autant que possible les web_accessible_resources, même vide si possible.
• Si web_accessible_resources n’est pas none, vérifier ClickJacking
• Si une communication a lieu de l’extension vers la web page, vérifier les vulnérabilités XSS causées dans la communication
• Si des Post Messages sont utilisés, vérifier les Post Message vulnerabilities.
• Si le Content Script accède aux détails du DOM, vérifier qu’il n’introduit pas de XSS s’il est modifié par le web
• Mettre un accent particulier si cette communication intervient aussi dans la communication Content Script -> Background script
• Si le background script communique via native messaging, vérifier que la communication est sûre et assainie
• Les informations sensibles ne devraient pas être stockées dans le code de la Browser Extension
• Les informations sensibles ne devraient pas être stockées dans la mémoire de la Browser Extension
• Les informations sensibles ne devraient pas être stockées dans le file system sans protection

Browser Extension Risks

L’application https://crxaminer.tech/ analyse certaines données comme les permissions demandées par une browser extension pour attribuer un niveau de risque à son utilisation.

Tools

Tarnish

• Récupère n’importe quelle extension Chrome à partir d’un lien Chrome webstore fourni.
• Visionneur manifest.json : affiche simplement une version JSON prettified du manifest de l’extension.
• Fingerprint Analysis : détection de web_accessible_resources et génération automatique de JavaScript de fingerprinting pour extension Chrome.
• Potential Clickjacking Analysis : détection des pages HTML de l’extension avec la directive web_accessible_resources définie. Elles sont potentiellement vulnérables au clickjacking selon l’objectif des pages.
• Visionneur des Permission Warning(s) : affiche la liste de tous les avertissements du prompt de permission Chrome qui seront présentés lorsqu’un utilisateur tentera d’installer l’extension.
• Dangerous Function(s) : affiche l’emplacement des fonctions dangereuses qui pourraient potentiellement être exploitées par un attaquant (par exemple, des fonctions comme innerHTML, chrome.tabs.executeScript).
• Entry Point(s) : montre où l’extension prend des entrées utilisateur/externes. C’est utile pour comprendre la surface de l’extension et repérer des points potentiels pour envoyer des données malformées à l’extension.
• Les analyseurs Dangerous Function(s) et Entry Point(s) ont les éléments suivants pour leurs alertes générées :
• Extrait de code pertinent et ligne ayant déclenché l’alerte.
• Description du problème.
• Bouton “View File” pour afficher le fichier source complet contenant le code.
• Chemin du fichier alerté.
• URI Chrome extension complète du fichier alerté.
• Type de fichier, comme Background Page script, Content Script, Browser Action, etc.
• Si la ligne vulnérable est dans un fichier JavaScript, les chemins de toutes les pages où il est inclus ainsi que le type de ces pages et le statut web_accessible_resource.
• Content Security Policy (CSP) analyzer and bypass checker : met en évidence les faiblesses dans le CSP de votre extension et toute manière potentielle de le bypass à cause de CDN whitelisted, etc.
• Known Vulnerable Libraries : utilise Retire.js pour vérifier l’usage de bibliothèques JavaScript connues comme vulnérables.
• Télécharger l’extension et les versions formatées.
• Télécharger l’extension originale.
• Télécharger une version beautified de l’extension (HTML et JavaScript automatiquement prettified).
• Cache automatique des résultats d’analyse : lancer un scan d’extension prendra pas mal de temps la première fois. En revanche, la deuxième fois, en supposant que l’extension n’a pas été mise à jour, ce sera presque instantané grâce au cache des résultats.
• URLs de rapports partageables, pour facilement envoyer quelqu’un vers un rapport d’extension généré par tarnish.

Neto

Project Neto est un package Python 3 conçu pour analyser et dévoiler les fonctionnalités cachées des plugins et extensions de browser pour des browsers connus comme Firefox et Chrome. Il automatise le processus de décompression des fichiers packagés afin d’extraire ces fonctionnalités depuis les ressources pertinentes d’une extension comme manifest.json, les dossiers de localisation ou les fichiers source Javascript et HTML.

References

• 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/reference/manifest/externally-connectable
• 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/
• https://www.koi.ai/blog/shadowprompt-how-any-website-could-have-hijacked-anthropic-claude-chrome-extension

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

• Vérifiez les plans d’abonnement !
• Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des astuces de hacking en soumettant des PR au HackTricks et HackTricks Cloud dépôts github.