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

También es posible enviar mensajes desde un background script a un content script ubicado en una pestaña específica llamando a **`chrome.tabs.sendMessage`** donde necesitarás indicar el **ID de la pestaña** a la que enviar el mensaje.

### Desde `externally_connectable` permitido a la extensión

**Aplicaciones web y extensiones de navegador externas permitidas** en la configuración `externally_connectable` pueden enviar solicitudes usando :
```javascript
chrome.runtime.sendMessage(extensionId, ...

Cuando sea necesario mencionar el extension ID.

Native Messaging

Es posible que los scripts en segundo plano se comuniquen con binarios dentro del sistema, lo que podría ser susceptible a vulnerabilidades críticas como RCEs si esta comunicación no está adecuadamente asegurada. More on this later.

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

Web ↔︎ Comunicación con content scripts

Los entornos donde operan los content scripts y donde existen las páginas host están separados entre sí, garantizando aislamiento. A pesar de este aislamiento, ambos pueden interactuar con el Document Object Model (DOM) de la página, un recurso compartido. Para que la página host se comunique con el content script, o indirectamente con la extensión a través del content script, es necesario utilizar el DOM accesible por ambas partes como canal de comunicación.

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 comunicación Post Message segura debe comprobar la autenticidad del mensaje recibido; esto se puede hacer verificando:

• event.isTrusted: Esto es True solo si el evento fue desencadenado por una acción del usuario
• El content script podría esperar un mensaje solo si el usuario realiza alguna acción
• origin domain: podría esperar un mensaje solo de una allowlist de dominios.
• Si se usa un regex, ten mucho cuidado
• Source: received_message.source !== window puede usarse para comprobar si el mensaje fue from the same window donde el Content Script está escuchando.

Las comprobaciones anteriores, incluso si se realizan, podrían ser vulnerables, así que revisa en la siguiente página potential Post Message bypasses:

PostMessage Vulnerabilities

Iframe

Otra posible vía de comunicación puede ser mediante Iframe URLs, puedes encontrar un ejemplo en:

BrowExt - XSS Example

DOM

Esto no es “exactamente” una forma de comunicación, pero el la web y el content script tendrán acceso al web DOM. Entonces, si el content script está leyendo información de él, confiando en el web DOM, la web podría modificar estos data (porque la web no debería ser confiada, o porque la web es vulnerable a XSS) y comprometer el Content Script.

También puedes encontrar un ejemplo de un DOM based XSS to compromise a browser extension en:

BrowExt - XSS Example

Content Script ↔︎ Background Script Communication

Un Content Script puede usar las funciones runtime.sendMessage() or tabs.sendMessage() para enviar un mensaje one-time JSON-serializable.

Para manejar la response, usa la Promise retornada. Aunque, por compatibilidad hacia atrás, aún puedes pasar un callback como último argumento.

Enviar una solicitud desde un content script se ve así:

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

Enviando una petición desde la extension (usualmente un background script). Ejemplo de cómo enviar un mensaje al content script en la selected tab:

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

En el lado receptor, necesitas configurar un runtime.onMessage event listener para manejar el mensaje. Esto es igual tanto desde un content script como desde 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" })
})

En el ejemplo destacado, sendResponse() se ejecutó de forma síncrona. Para modificar el manejador del evento onMessage para la ejecución asíncrona de sendResponse(), es imperativo incorporar return true;.

Una consideración importante es que en escenarios donde varias páginas están configuradas para recibir eventos onMessage, la primera página que ejecute sendResponse() para un evento específico será la única capaz de entregar la respuesta de forma efectiva. Cualquier respuesta posterior al mismo evento no será tenida en cuenta.

Al crear nuevas extensiones, se debe dar preferencia a promises en lugar de callbacks. Respecto al uso de callbacks, la función sendResponse() se considera válida solo si se ejecuta directamente dentro del contexto síncrono, o si el manejador de eventos indica una operación asíncrona devolviendo true. Si ninguno de los manejadores devuelve true o si la función sendResponse() es eliminada de la memoria (garbage-collected), el callback asociado a la función sendMessage() se ejecutará por defecto.

Native Messaging

Browser extensions also allow to communicate with binaries in the system via stdin. The application must install a json indicating so in a json like:

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

Donde el name es la cadena pasada a runtime.connectNative() o runtime.sendNativeMessage() para comunicarse con la aplicación desde los background scripts de la extensión del navegador. El path es la ruta al binario, solo hay 1 type válido que es stdio (use stdin y stdout) y los allowed_origins indican las extensiones que pueden acceder a él (y no pueden tener comodín).

Chrome/Chromium buscará este json en algunas claves del registro de Windows y en algunas rutas en macOS y Linux (más info en los docs).

Tip

La extensión del navegador también necesita declarar el permiso nativeMessaing para poder usar esta comunicación.

Así es como se ve el código de un background script enviando mensajes a una aplicación nativa:

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

In this blog post, se propone un patrón vulnerable que abusa de native messages:

1. Browser extension tiene un patrón wildcard para content script.
2. Content script pasa mensajes postMessage al background script usando sendMessage.
3. Background script pasa el mensaje a la aplicación nativa usando sendNativeMessage.
4. La aplicación nativa maneja el mensaje de forma peligrosa, llevando a code execution.

Y dentro de ello se explica un ejemplo de cómo ir de cualquier página a RCE abusando de una extensión del navegador.

Información sensible en memoria/código/portapapeles

Si una extensión del navegador almacena información sensible en su memoria, esto podría ser volcado (especialmente en máquinas Windows) y buscado para encontrar dicha información.

Por lo tanto, la memoria de la extensión del navegador no debería considerarse segura y la información sensible como credenciales o frases mnemónicas no debería almacenarse.

Por supuesto, no pongas información sensible en el código, ya que será pública.

Para volcar la memoria del navegador podrías dump the process memory o ir a los settings de la extensión del navegador y hacer click en Inspect pop-up -> En la sección Memory -> Take a snaphost y usar CTRL+F para buscar dentro del snapshot información sensible.

Además, información altamente sensible como mnemonic keys o contraseñas no debería permitirse copiarse en el clipboard (o al menos eliminarla del clipboard en unos segundos) porque entonces procesos que monitorizan el clipboard podrán obtenerlas.

Loading an Extension in the Browser

1. Descargar la extensión del navegador y descomprimirla
2. Ve a chrome://extensions/ y activa el Developer Mode
3. Haz click en el botón Load unpacked

En Firefox ve a about:debugging#/runtime/this-firefox y haz click en el botón Load Temporary Add-on.

Getting the source code from the store

El código fuente de una extensión de Chrome puede obtenerse mediante varios métodos. A continuación están las explicaciones e instrucciones detalladas para cada opción.

Download Extension as ZIP via Command Line

El código fuente de una extensión de Chrome puede descargarse como un archivo ZIP usando la línea de comandos. Esto implica usar curl para obtener el archivo ZIP desde una URL específica y luego extraer el contenido del ZIP a un directorio. Aquí están los pasos:

1. Reemplaza “extension_id” con el ID real de la extensión.
2. Ejecuta los siguientes comandos:

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"

Usar el sitio web CRX Viewer

https://robwu.nl/crxviewer/

Usar la extensión CRX Viewer

Otro método conveniente es usar Chrome Extension Source Viewer, que es un proyecto open-source. Se puede instalar desde el Chrome Web Store. El source code del viewer está disponible en su GitHub repository.

Ver el source de una extensión instalada localmente

También se pueden inspeccionar las Chrome extensions instaladas localmente. Aquí está cómo:

1. Accede al directorio de tu perfil local de Chrome visitando chrome://version/ y localizando el campo “Profile Path”.
2. Navega a la subcarpeta Extensions/ dentro del directorio del perfil.
3. Esta carpeta contiene todas las extensiones instaladas, típicamente con su source code en un formato legible.

Para identificar extensiones, puedes mapear sus IDs a nombres:

• Activa Developer Mode en la página about:extensions para ver los IDs de cada extensión.
• Dentro de la carpeta de cada extensión, el archivo manifest.json contiene un campo name legible que te ayuda a identificar la extensión.

Usar un File Archiver o Unpacker

Ve a la Chrome Web Store y descarga la extensión. El archivo tendrá la extensión .crx. Cambia la extensión del archivo de .crx a .zip. Usa cualquier file archiver (como WinRAR, 7-Zip, etc.) para extraer el contenido del archivo ZIP.

Usar Developer Mode en Chrome

Abre Chrome y ve a chrome://extensions/. Activa “Developer mode” en la esquina superior derecha. Haz clic en “Load unpacked extension…”. Navega al directorio de tu extensión. Esto no descarga el source code, pero es útil para ver y modificar el código de una extensión ya descargada o en desarrollo.

Chrome extension manifest dataset

Para intentar detectar browser extensions vulnerables puedes usar el https://github.com/palant/chrome-extension-manifests-dataset y revisar sus manifest files en busca de indicios potencialmente vulnerables. Por ejemplo, para buscar extensiones con más de 25000 usuarios, content_scripts y el permiso 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)

Técnica sigilosa para backdoorear Chromium editando directamente las Preferences por usuario y forjando HMACs válidos, provocando que el navegador acepte y active una extensión unpacked arbitraria sin prompts ni flags.

Forced Extension Load Preferences Mac Forgery Windows

Detección de actualizaciones maliciosas de extensiones (Static Version Diffing)

Los compromisos en la supply-chain a menudo llegan como actualizaciones maliciosas a extensiones previamente benignas. Un enfoque práctico y de bajo ruido es comparar un nuevo paquete de extensión contra la última versión conocida buena usando análisis estático (por ejemplo, Assemblyline). El objetivo es alertar sobre deltas de alta señal en lugar de sobre cualquier cambio.

Workflow

• Enviar ambas versiones (antigua + nueva) al mismo perfil de análisis estático.
• Marcar background/service worker scripts nuevos o actualizados (persistencia + lógica privilegiada).
• Marcar content scripts nuevos o actualizados (acceso al DOM y recolección de datos).
• Marcar nuevos permissions / host_permissions añadidos en manifest.json.
• Marcar nuevos dominios extraídos del código (potenciales endpoints C2/exfil).
• Marcar nuevas detecciones de análisis estático (p. ej., base64 decode, cookie harvesting, network-request builders, patrones de obfuscation).
• Marcar anomalías estadísticas como saltos bruscos de entropy o z-scores atípicos en scripts cambiados.

Detectar cambios en scripts con precisión

• Nuevo script añadido → detectar vía diff de manifest.json.
• Script existente modificado (manifest sin cambios) → comparar hashes por archivo desde el árbol de archivos extraído (p. ej., salida Extract de Assemblyline). Esto detecta actualizaciones sigilosas en workers o content scripts existentes.

Detecciones pre-divulgación

Para evitar detecciones “modo fácil” basadas en IOCs ya conocidos, deshabilita servicios alimentados por threat-intel y confía en señales intrínsecas (dominios, firmas heurísticas, deltas de scripts, anomalías de entropy). Esto aumenta las probabilidades de detectar actualizaciones maliciosas antes de su reporte público.

Ejemplo de lógica de alerta de alta confianza

• Combo de bajo ruido: nuevos dominios + nuevas detecciones de análisis estático + background/service worker actualizado + content scripts añadidos o actualizados.
• Captura más amplia: nuevo dominio + background/service worker nuevo o actualizado (mayor recall, mayor ruido).

Servicios clave de Assemblyline para este workflow:

• Extract: desempaqueta la extensión y produce hashes por archivo.
• Characterize: calcula características de los archivos (p. ej., entropy).
• JsJAWS / FrankenStrings / URLCreator: exponen heurísticas JS, strings y dominios para diferenciar entre versiones.

Security Audit Checklist

Aunque las Browser Extensions tienen una superficie de ataque limitada, algunas pueden contener vulnerabilidades o mejoras de hardening potenciales. Las siguientes son las más comunes:

• Limitar tanto como sea posible los permissions solicitados
• Limitar tanto como sea posible los host_permissions
• Usar una fuerte content_security_policy
• Limitar tanto como sea posible el externally_connectable; si no se necesita y es posible, no dejarlo por defecto, especificar {}
• Si se menciona una URL vulnerable a XSS o a takeover, un atacante podrá enviar mensajes directamente a los background scripts. Bypass muy potente.
• Limitar tanto como sea posible los web_accessible_resources, incluso vacíos si es posible.
• Si web_accessible_resources no es ninguno, comprobar ClickJacking
• Si cualquier comunicación ocurre desde la extension hacia la web page, comprobar XSS vulnerabilidades causadas en la comunicación.
• Si se usan Post Messages, comprobar por Post Message vulnerabilities.
• Si el Content Script accede al DOM, verificar que no estén introduciendo XSS si son modificados por la web
• Poner especial énfasis si esta comunicación también está involucrada en la Content Script -> Background script communication
• Si el background script se comunica vía native messaging, comprobar que la comunicación sea segura y esté sanitizada
• Información sensible no debe almacenarse dentro del código de la Browser Extension
• Información sensible no debe almacenarse dentro de la memoria de la Browser Extension
• Información sensible no debe almacenarse en el file system sin protección

Browser Extension Risks

• La app https://crxaminer.tech/ analiza algunos datos como los permissions que la extensión de browser solicita para dar un nivel de riesgo al usar la extensión.

Tools

Tarnish

• Recupera cualquier Chrome extension desde un enlace proporcionado de Chrome webstore.
• manifest.json viewer: simplemente muestra una versión JSON-prettified del manifest de la extensión.
• Fingerprint Analysis: Detección de web_accessible_resources y generación automática de JavaScript para fingerprinting de Chrome extension.
• Potential Clickjacking Analysis: Detección de páginas HTML de la extensión con la directiva web_accessible_resources establecida. Estas pueden ser potencialmente vulnerables a clickjacking dependiendo del propósito de las páginas.
• Permission Warning(s) viewer: muestra una lista de todos los avisos de permissions de Chrome que se mostrarán cuando un usuario intente instalar la extensión.
• Dangerous Function(s): muestra la ubicación de funciones peligrosas que podrían ser explotadas por un atacante (p. ej. funciones como innerHTML, chrome.tabs.executeScript).
• Entry Point(s): muestra dónde la extensión recibe input de usuario/externo. Esto es útil para entender la superficie de la extensión y buscar puntos potenciales para enviar datos maliciosamente construidos a la extensión.
• Tanto los escáneres de Dangerous Function(s) como Entry Point(s) generan para sus alertas:
• Fragmento de código relevante y línea que causó la alerta.
• Descripción del problema.
• Un botón “View File” para ver el archivo fuente completo que contiene el código.
• La ruta del archivo alertado.
• El URI completo de la Chrome extension del archivo alertado.
• El tipo de archivo que es, como Background Page script, Content Script, Browser Action, etc.
• Si la línea vulnerable está en un archivo JavaScript, las rutas de todas las páginas donde está incluido así como el tipo de esas páginas y el estado de web_accessible_resource.
• Content Security Policy (CSP) analyzer and bypass checker: Señala debilidades en la CSP de tu extensión e ilumina posibles formas de bypass debido a CDNs en listas blancas, etc.
• Known Vulnerable Libraries: Usa Retire.js para comprobar el uso de librerías JavaScript con vulnerabilidades conocidas.
• Descargar extensión y versiones formateadas.
• Descargar la extensión original.
• Descargar una versión beautified de la extensión (HTML y JavaScript auto-prettified).
• Caché automática de resultados de escaneo; ejecutar un scan de extensión tomará bastante tiempo la primera vez. Sin embargo la segunda vez, asumiendo que la extensión no fue actualizada, será casi instantáneo debido al cache de resultados.
• URLs de reportes enlazables, facilita compartir el reporte generado por tarnish.

Neto

Project Neto es un paquete Python 3 concebido para analizar y desentrañar funcionalidades ocultas de plugins y extensiones de navegador conocidos como Firefox y Chrome. Automatiza el proceso de descomprimir los archivos empaquetados para extraer estas funcionalidades de recursos relevantes en una extensión como manifest.json, carpetas de localización o archivos fuente Javascript y 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

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

• Revisa los planes de suscripción!
• Únete al 💬 grupo de Discord o al grupo de telegram o síguenos en Twitter 🐦 @hacktricks_live.
• Comparte trucos de hacking enviando PRs a los HackTricks y HackTricks Cloud repositorios de github.