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

È anche possibile inviare messaggi da uno script di background a uno script di contenuto presente in una scheda specifica chiamando **`chrome.tabs.sendMessage`**, dove sarà necessario indicare l'**ID of the tab** a cui inviare il messaggio.

### Dalle origini consentite in `externally_connectable` all'estensione

**Web app e estensioni del browser esterne consentite** nella configurazione `externally_connectable` possono inviare richieste usando :
```javascript
chrome.runtime.sendMessage(extensionId, ...

Dove è necessario menzionare l’extension ID.

Native Messaging

È possibile che i background scripts comunichino con binari all’interno del sistema, i quali potrebbero essere soggetti a vulnerabilità critiche come le RCEs se questa comunicazione non è adeguatamente protetta. More on this later.

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

Web ↔︎ Comunicazione con Content Script

Gli ambienti in cui operano i content scripts e quelli in cui risiedono le pagine host sono separati l’uno dall’altro, garantendo isolamento. Nonostante questo isolamento, entrambi possono interagire con il Document Object Model (DOM) della pagina, una risorsa condivisa. Affinché la pagina host comunichi con il content script, o indirettamente con l’estensione tramite il content script, è necessario utilizzare il DOM accessibile a entrambe le parti come canale di comunicazione.

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
)

Una comunicazione Post Message sicura dovrebbe verificare l’autenticità del messaggio ricevuto, ciò può essere fatto verificando:

• event.isTrusted: This is True only if the event was triggered by a users action
• Il Content Script potrebbe aspettarsi un messaggio solo se l’utente esegue qualche azione
• origin domain: potrebbe aspettarsi un messaggio solo da una allowlist di domini.
• If a regex is used, be very careful
• Source: received_message.source !== window può essere usato per verificare se il messaggio era dalla stessa window dove il Content Script sta ascoltando.

I controlli precedenti, anche se eseguiti, potrebbero essere vulnerabili, quindi controlla nella pagina seguente i potenziali bypass di Post Message:

PostMessage Vulnerabilities

Iframe

Un altro possibile modo di comunicazione può essere tramite Iframe URLs, trovi un esempio in:

BrowExt - XSS Example

DOM

Questo non è “esattamente” un modo di comunicazione, ma il web e il Content Script avranno accesso al web DOM. Quindi, se il Content Script legge alcune informazioni da esso, fidandosi del web DOM, il web potrebbe modificare questi dati (perché il web non dovrebbe essere considerato affidabile, o perché il web è vulnerabile a XSS) e compromettere il Content Script.

Puoi anche trovare un esempio di una DOM based XSS to compromise a browser extension in:

BrowExt - XSS Example

Content Script ↔︎ Background Script Comunicazione

Un Content Script può usare le funzioni runtime.sendMessage() or tabs.sendMessage() per inviare un messaggio monouso serializzabile in JSON.

Per gestire la risposta, usa la Promise restituita. Tuttavia, per compatibilità retroattiva, puoi ancora passare una callback come ultimo argomento.

Esempio di invio di una richiesta da un content script:

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

Invio di una richiesta dall’extension (di solito un background script). Esempio di come inviare un messaggio al content script nella scheda selezionata:

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

Sul lato ricevente, devi impostare un runtime.onMessage event listener per gestire il messaggio. Funziona allo stesso modo sia da un content script che da una extension page.

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

Nell’esempio evidenziato, sendResponse() è stato eseguito in modo sincrono. Per modificare l’event handler onMessage per l’esecuzione asincrona di sendResponse(), è necessario includere return true;.

Una considerazione importante è che, in scenari in cui più pagine sono impostate per ricevere eventi onMessage, la prima pagina che esegue sendResponse() per uno specifico evento sarà l’unica in grado di consegnare efficacemente la risposta. Qualsiasi risposta successiva allo stesso evento non verrà presa in considerazione.

Quando si sviluppano nuove estensioni, è preferibile usare promises piuttosto che callbacks. Per quanto riguarda l’uso di callbacks, la funzione sendResponse() è considerata valida solo se viene eseguita direttamente nel contesto sincrono, oppure se l’event handler indica un’operazione asincrona restituendo true. Se nessuno degli handler restituisce true o se la funzione sendResponse() viene rimossa dalla memoria (garbage-collected), il callback associato a sendMessage() verrà eseguito di default.

Native Messaging

Le estensioni del browser consentono inoltre di comunicare con binaries in the system via stdin. L’applicazione deve installare un json che lo dichiari in un json del tipo:

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

Dove il name è la stringa passata a runtime.connectNative() o a runtime.sendNativeMessage() per comunicare con l’applicazione dagli background scripts dell’estensione. Il path è il percorso al binario, esiste un solo type valido che è stdio (use stdin and stdout) e gli allowed_origins indicano le estensioni che possono accedervi (e non possono avere wildcard).

Chrome/Chromium cercherà questo json in alcune chiavi del registro di Windows e in alcuni percorsi su macOS e Linux (maggiori info nella docs).

Tip

L’estensione del browser necessita anche del permesso nativeMessaing dichiarato per poter usare questa comunicazione.

Ecco un esempio di codice di background script che invia messaggi a un’applicazione nativa:

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

In this blog post, è proposto un pattern vulnerabile che abusa dei native messages:

1. Browser Extension ha un pattern wildcard per il content script.
2. Il content script passa messaggi postMessage allo background script usando sendMessage.
3. Lo background script passa il messaggio all’applicazione native usando sendNativeMessage.
4. L’applicazione native gestisce il messaggio in modo pericoloso, portando a code execution.

E al suo interno è spiegato un esempio di come passare da qualsiasi pagina a RCE abusando di un browser extension.

Sensitive Information in Memory/Code/Clipboard

Se una Browser Extension memorizza informazioni sensibili nella sua memoria, queste possono essere dumpate (soprattutto su macchine Windows) e ricercate per ottenere tali informazioni.

Pertanto, la memoria della Browser Extension non dovrebbe essere considerata sicura e le informazioni sensibili come credenziali o frasi mnemoniche non dovrebbero essere memorizzate.

Ovviamente, non mettere informazioni sensibili nel codice, poiché saranno pubbliche.

Per dumpare la memoria dal browser puoi dumpare la memoria del processo oppure andare nelle impostazioni dell’estensione del browser cliccare su Inspect pop-up -> Nella sezione Memory -> Take a snaphost e usare CTRL+F per cercare all’interno dello snapshot informazioni sensibili.

Inoltre, informazioni altamente sensibili come chiavi mnemonic o password non dovrebbero poter essere copiate negli appunti (o almeno rimosse dagli appunti dopo pochi secondi) perché allora processi che monitorano gli appunti potranno recuperarle.

Loading an Extension in the Browser

1. Scarica la Browser Extension e decomprimila
2. Vai a chrome://extensions/ e abilita la Developer Mode
3. Clicca sul pulsante Load unpacked

In Firefox vai su about:debugging#/runtime/this-firefox e clicca sul pulsante Load Temporary Add-on.

Getting the source code from the store

Il sorgente di una Chrome extension può essere ottenuto tramite vari metodi. Qui sotto sono fornite spiegazioni dettagliate e istruzioni per ogni opzione.

Download Extension as ZIP via Command Line

Il sorgente di una Chrome extension può essere scaricato come file ZIP usando la command line. Questo implica l’uso di curl per recuperare il file ZIP da una URL specifica e poi estrarre il contenuto del ZIP in una directory. Ecco i passaggi:

1. Sostituisci "extension_id" con l’ID reale dell’estensione.
2. Esegui i seguenti comandi:

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"

Usa il sito CRX Viewer

https://robwu.nl/crxviewer/

Usa l’estensione CRX Viewer

Un altro metodo comodo è usare il Chrome Extension Source Viewer, che è un progetto open-source. Può essere installato dal Chrome Web Store. Il codice sorgente del viewer è disponibile nel suo GitHub repository.

Visualizza il sorgente di un’estensione installata localmente

Chrome extensions installate localmente possono anche essere ispezionate. Ecco come:

1. Accedi alla directory del profilo locale di Chrome visitando chrome://version/ e individuando il campo “Profile Path”.
2. Vai nella sottocartella Extensions/ all’interno della directory del profilo.
3. Questa cartella contiene tutte le estensioni installate, di solito con il codice sorgente in un formato leggibile.

Per identificare le estensioni, puoi mappare i loro ID ai nomi:

• Abilita Developer Mode nella pagina about:extensions per vedere gli ID di ciascuna estensione.
• All’interno della cartella di ogni estensione, il file manifest.json contiene un campo leggibile name, che aiuta a identificare l’estensione.

Usa un archiviatore di file o un unpacker

Vai al Chrome Web Store e scarica l’estensione. Il file avrà estensione .crx. Cambia l’estensione del file da .crx a .zip. Usa un qualsiasi archiviatore (come WinRAR, 7-Zip, ecc.) per estrarre il contenuto del file ZIP.

Usa Developer Mode in Chrome

Apri Chrome e vai su chrome://extensions/. Abilita “Developer mode” in alto a destra. Clicca su “Load unpacked extension…”. Naviga fino alla directory della tua estensione. Questo non scarica il codice sorgente, ma è utile per visualizzare e modificare il codice di un’estensione già scaricata o sviluppata.

Chrome extension manifest dataset

Per provare a individuare estensioni del browser vulnerabili potresti usare il https://github.com/palant/chrome-extension-manifests-dataset e controllare i loro file manifest per segni potenzialmente vulnerabili. Ad esempio, per controllare estensioni con più di 25000 utenti, content_scripts e il permesso 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)

Tecnica stealth per inserire un backdoor in Chromium modificando direttamente le Preferences per utente e forgiando HMACs validi, facendo sì che il browser accetti e attivi un unpacked extension arbitrario senza prompt o flag.

Forced Extension Load Preferences Mac Forgery Windows

Detecting Malicious Extension Updates (Static Version Diffing)

Le compromissioni della supply-chain spesso si presentano come malicious updates a estensioni precedentemente benigni. Un approccio pratico e a basso rumore è confrontare un nuovo pacchetto di estensione con l’ultima versione conosciuta come buona usando analisi statica (per esempio, Assemblyline). L’obiettivo è allertare su delta ad alto segnale piuttosto che su qualsiasi cambiamento.

Workflow

• Inviare entrambe le versioni (old + new) allo stesso profilo di static-analysis.
• Segnalare nuovi o aggiornati background/service worker scripts (persistenza + logica privilegiata).
• Segnalare nuovi o aggiornati content scripts (accesso al DOM e raccolta dati).
• Segnalare nuove permissions/host_permissions aggiunte in manifest.json.
• Segnalare nuovi domini estratti dal codice (possibili endpoint C2/exfil).
• Segnalare nuove rilevazioni di static-analysis (es. base64 decode, cookie harvesting, network-request builders, pattern di obfuscation).
• Segnalare anomalie statistiche come improvvisi aumenti di entropy o z-score anomali negli script modificati.

Detecting script changes accurately

• Nuovo script aggiunto → rilevare tramite diff di manifest.json.
• Script esistente modificato (manifest invariato) → confrontare gli hash per-file dell’albero dei file estratti (es. output Extract di Assemblyline). Questo cattura aggiornamenti stealth a worker esistenti o content scripts.

Pre-disclosure detections

Per evitare rilevamenti “easy mode” basati su IOCs già noti, disabilitare servizi alimentati da threat-intel e fare affidamento su segnali intrinseci (domini, firme euristiche, delta degli script, anomalie di entropy). Questo aumenta le probabilità di catturare aggiornamenti malevoli prima della segnalazione pubblica.

Example high-confidence alert logic

• 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 (maggiore recall, più rumore).

Servizi chiave di Assemblyline per questo workflow:

• Extract: disimballa l’estensione e fornisce hash per-file.
• Characterize: calcola caratteristiche dei file (es. entropy).
• JsJAWS / FrankenStrings / URLCreator: estraggono euristiche JS, stringhe e domini da differenziare tra le versioni.

Security Audit Checklist

Anche se le estensioni del browser hanno una superficie di attacco limitata, alcune potrebbero contenere vulnerabilità o possibili miglioramenti di hardening. Le seguenti sono le più comuni:

• Limitare il più possibile le richieste di permissions
• Limitare il più possibile le host_permissions
• Usare una strong content_security_policy
• Limitare il più possibile externally_connectable; se non necessario, non lasciarlo di default, specificare {}
• Se è menzionata un URL vulnerabile a XSS o a takeover, un attaccante potrà inviare messaggi direttamente ai background scripts. Bypass molto potente.
• Limitare il più possibile le web_accessible_resources, anche vuote se possibile.
• Se web_accessible_resources non è none, controllare per ClickJacking
• Se qualsiasi comunicazione avviene dall’extension alla web page, controllare XSS vulnerabilities causate nella comunicazione.
• Se vengono usati Post Messages, controllare per Post Message vulnerabilities.
• Se il Content Script accede ai dettagli del DOM, verificare che non introduca XSS se viene modificato dalla pagina web
• Dare particolare attenzione se questa comunicazione coinvolge anche la Content Script -> Background script communication
• Se il background script comunica via native messaging verificare che la comunicazione sia sicura e sanitizzata
• Informazioni sensibili non dovrebbero essere memorizzate all’interno del codice dell’extension
• Informazioni sensibili non dovrebbero essere memorizzate nella memoria dell’extension
• Informazioni sensibili non dovrebbero essere memorizzate nel file system non protetto

Browser Extension Risks

• L’app https://crxaminer.tech/ analizza alcuni dati come le permissions richieste dall’estensione del browser per fornire un livello di rischio nell’uso dell’estensione.

Tools

Tarnish

• Recupera qualsiasi Chrome extension da un link fornito del Chrome webstore.
• manifest.json viewer: mostra semplicemente una versione prettified JSON del manifest dell’estensione.
• Fingerprint Analysis: rilevamento di web_accessible_resources e generazione automatica di JavaScript per fingerprinting delle Chrome extension.
• Potential Clickjacking Analysis: rilevamento di pagine HTML dell’estensione con la direttiva web_accessible_resources impostata. Queste possono essere potenzialmente vulnerabili a clickjacking a seconda dello scopo delle pagine.
• Permission Warning(s) viewer: mostra la lista di tutti gli avvisi di permission prompt di Chrome che verranno visualizzati quando un utente tenta di installare l’estensione.
• Dangerous Function(s): mostra la posizione di funzioni pericolose che potrebbero essere sfruttate da un attaccante (es. innerHTML, chrome.tabs.executeScript).
• Entry Point(s): mostra dove l’estensione riceve input dall’utente/esterno. Utile per comprendere la superficie dell’estensione e cercare punti potenzialmente sfruttabili per inviare dati malevolmente crafted all’estensione.
• Sia lo scanner Dangerous Function(s) che Entry Point(s) forniscono per gli avvisi generati:
  • Snippet di codice rilevante e la riga che ha causato l’avviso.
  • Descrizione dell’issue.
  • Un pulsante “View File” per visualizzare il file sorgente completo contenente il codice.
  • Il path del file segnalato.
  • L’URI completo dell’estensione Chrome del file segnalato.
  • Il tipo di file, come Background Page script, Content Script, Browser Action, ecc.
  • Se la riga vulnerabile è in un file JavaScript, i path di tutte le pagine dove è incluso e il tipo di queste pagine, e lo stato di web_accessible_resource.
• Content Security Policy (CSP) analyzer and bypass checker: indica debolezze nella CSP dell’estensione e illumina eventuali modi per bypassarla dovuti a CDN whitelistate, ecc.
• Known Vulnerable Libraries: usa Retire.js per verificare l’uso di librerie JavaScript note come vulnerabili.
• Download dell’estensione e versioni formattate.
• Download dell’estensione originale.
• Download di una versione beautified dell’estensione (HTML e JavaScript auto-prettified).
• Caching automatico dei risultati della scansione; eseguire una scansione richiederà tempo la prima volta, mentre una seconda esecuzione sarà quasi istantanea se l’estensione non è stata aggiornata.
• URL di report linkabili, per condividere facilmente il report generato da tarnish.

Neto

Project Neto è un package Python 3 concepito per analizzare e svelare funzionalità nascoste di plugin ed extension per browser noti come Firefox e Chrome. Automatizza il processo di unzip dei file confezionati per estrarre queste funzionalità da risorse rilevanti in un’estensione come manifest.json, cartelle di localizzazione o file sorgente Javascript e 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/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

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

• Controlla i piani di abbonamento!
• Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @hacktricks_live.
• Condividi trucchi di hacking inviando PR ai HackTricks e HackTricks Cloud repos github.