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

Також можливо надсилати повідомлення з фонового скрипта до контент-скрипта, розташованого в певній вкладці, викликавши **`chrome.tabs.sendMessage`**, де потрібно вказати **ідентифікатор вкладки** для надсилання повідомлення.

### Від дозволених `externally_connectable` до розширення

**Дозволені web-додатки та зовнішні розширення браузера** у конфігурації `externally_connectable` можуть надсилати запити, використовуючи :
```javascript
chrome.runtime.sendMessage(extensionId, ...

Де потрібно вказувати extension ID.

Native Messaging

Фонові скрипти можуть спілкуватися з бінарними файлами в системі, що може призвести до критичних вразливостей, таких як RCEs, якщо ця комунікація не буде належним чином захищена. More on this later.

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

Взаємодія Web ↔︎ Content Script

Середовища, в яких працюють content scripts, та де існують host pages, є відокремленими одне від одного, що забезпечує ізоляцію. Незважаючи на цю ізоляцію, обидва мають змогу взаємодіяти з Document Object Model (DOM) сторінки — спільним ресурсом. Щоб host page могла встановити зв’язок з content script, або опосередковано з розширенням через content script, потрібно використовувати DOM, доступний обом сторонам як канал комунікації.

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
)

Безпечна Post Message комунікація повинна перевіряти автентичність отриманого повідомлення, це можна зробити перевіряючи:

• event.isTrusted: Це True тільки якщо подія була викликана дією користувача
• Контент-скрипт може очікувати повідомлення лише якщо користувач виконує певну дію
• origin domain: може очікувати повідомлення лише від allowlist доменів.
• Якщо використовується regex, будьте дуже обережні
• Source: received_message.source !== window можна використати, щоб перевірити, чи повідомлення було з того ж вікна, де слухає Content Script.

Попередні перевірки, навіть якщо виконані, можуть бути уразливими, тому перегляньте на наступній сторінці potential Post Message bypasses:

PostMessage Vulnerabilities

Iframe

Ще один можливий спосіб комунікації — через Iframe URLs, приклад можна знайти в:

BrowExt - XSS Example

DOM

Це не зовсім спосіб комунікації, але web й content script матимуть доступ до web DOM. Тому, якщо content script читає якусь інформацію з нього, довіряючи web DOM, web може змінити ці дані (бо web не слід довіряти, або бо web уразливий до XSS) і компрометувати Content Script.

Приклад DOM based XSS to compromise a browser extension також можна знайти в:

BrowExt - XSS Example

Content Script ↔︎ Background Script Communication

Content Script може використовувати функції runtime.sendMessage() or tabs.sendMessage() щоб відправити one-time JSON-serializable повідомлення.

Щоб обробити response, використовуйте повернутий Promise. Проте, для зворотної сумісності, ви все ще можете передати callback як останній аргумент.

Відправка запиту з content script виглядає так:

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

Надсилання запиту з розширення (зазвичай із фонового скрипту). Приклад того, як надіслати повідомлення до content script у вибраній вкладці:

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

На приймаючому боці, вам потрібно налаштувати runtime.onMessage обробник подій для обробки повідомлення. Це виглядає однаково як у content script, так і у 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" })
})

У наведеному прикладі sendResponse() виконувалася синхронно. Щоб змінити обробник події onMessage для асинхронного виконання sendResponse(), необхідно додати return true;.

Важливо пам’ятати, що якщо декілька сторінок налаштовані на отримання подій onMessage, перша сторінка, яка виконає sendResponse() для конкретної події, буде єдиною, що зможе ефективно доставити відповідь. Будь-які наступні відповіді на ту саму подію враховані не будуть.

При створенні нових розширень слід віддавати перевагу promises замість callbacks. Що стосується використання callbacks, функція sendResponse() вважається дійсною лише якщо вона виконується безпосередньо в синхронному контексті, або якщо обробник події вказує на асинхронну операцію, повертаючи true. Якщо ж жоден із обробників не поверне true або функція sendResponse() буде видалена з пам’яті (garbage-collected), callback, пов’язаний з sendMessage(), буде викликаний за замовчуванням.

Native Messaging

Розширення браузера також дозволяють спілкуватися з бінарними файлами в системі через stdin. Додаток має встановити json, що це вказує, у json подібного вигляду:

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

Де name — це рядок, який передається в runtime.connectNative() або runtime.sendNativeMessage() для спілкування з додатком з фонових скриптів розширення браузера. path — це шлях до бінарного файлу, існує лише 1 дійсний type, який — stdio (use stdin and stdout), а allowed_origins вказують розширення, які можуть отримати доступ (і не можуть мати wildcard).

Chrome/Chromium шукатиме цей json у реєстрі Windows та в деяких шляхах на macOS і Linux (більше інформації в docs).

Tip

Розширенню браузера також потрібно задекларувати дозвіл nativeMessaing, щоб мати можливість використовувати цю комунікацію.

Ось як виглядає код фонового скрипта, який надсилає повідомлення нативному додатку:

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

In this blog post, a vulnerable pattern abusing native messages is proposed:

1. Browser extension has a wildcard pattern for content script.
2. Content script passes postMessage messages to the background script using sendMessage.
3. Background script passes the message to native application using sendNativeMessage.
4. Native application handles the message dangerously, leading to code execution.

And inside of it an example of going from any page to RCE abusing a browser extension is explained.

Sensitive Information in Memory/Code/Clipboard

If a Browser Extension stores sensitive information inside it’s memory, this could be dumped (specially in Windows machines) and searched for this information.

Therefore, the memory of the Browser Extension shouldn’t be considered secure and sensitive information such as credentials or mnemonic phrases shouldn’t be stored.

Of course, do not put sensitive information in the code, as it will be public.

To dump memory from the browser you could dump the process memory or to go to the settings of the browser extension click on Inspect pop-up -> In the Memory section -> Take a snaphost and CTRL+F to search inside the snapshot for sensitive info.

Moreover, highly sensitive information like mnemonic keys or passwords shouldn’t be allowed to be copied in the clipboard (or at least remove it from the clipboard in a few seconds) because then processes monitoring the clipboard will be able to get them.

Loading an Extension in the Browser

1. Download the Browser Extension & unzipped
2. Go to chrome://extensions/ and enable the Developer Mode
3. Click the Load unpacked button

In Firefox you go to about:debugging#/runtime/this-firefox and click Load Temporary Add-on button.

Getting the source code from the store

The source code of a Chrome extension can be obtained through various methods. Below are detailed explanations and instructions for each option.

Download Extension as ZIP via Command Line

The source code of a Chrome extension can be downloaded as a ZIP file using the command line. This involves using curl to fetch the ZIP file from a specific URL and then extracting the contents of the ZIP file to a directory. Here are the steps:

1. Replace "extension_id" with the actual ID of the extension.
2. Execute the following commands:

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

https://robwu.nl/crxviewer/

Використовуйте розширення CRX Viewer

Ще один зручний спосіб — використати Chrome Extension Source Viewer, який є проектом з відкритим вихідним кодом. Його можна встановити з Chrome Web Store. Вихідний код viewer доступний у його GitHub repository.

Переглянути вихідний код локально встановленого розширення

Локально встановлені розширення Chrome також можна інспектувати. Ось як це зробити:

1. Отримайте доступ до локального каталогу профілю Chrome, перейшовши на chrome://version/ і знайшовши поле “Profile Path”.
2. Перейдіть до підпапки Extensions/ у каталозі профілю.
3. Ця папка містить усі встановлені розширення, зазвичай із їхнім вихідним кодом у читабельному форматі.

Щоб ідентифікувати розширення, можна зіставити їхні ID з іменами:

• Увімкніть Developer Mode на сторінці about:extensions, щоб бачити ID кожного розширення.
• У папці кожного розширення файл manifest.json містить читабельне поле name, яке допомагає ідентифікувати розширення.

Використовуйте архіватор або розпакувальник файлів

Зайдіть у Chrome Web Store і скачайте розширення. Файл матиме розширення .crx. Змініть розширення файлу з .crx на .zip. Використайте будь-який файл-архіватор (наприклад WinRAR, 7-Zip тощо), щоб витягти вміст ZIP-файлу.

Використовуйте Developer Mode у Chrome

Відкрийте Chrome і перейдіть до chrome://extensions/. Увімкніть “Developer mode” у верхньому правому куті. Натисніть “Load unpacked extension…”. Перейдіть до каталогу вашого розширення. Це не завантажує вихідний код, але корисно для перегляду та модифікації коду вже завантаженого або розробленого розширення.

Chrome extension manifest dataset

Щоб спробувати виявити вразливі розширення браузера, ви можете використати thehttps://github.com/palant/chrome-extension-manifests-dataset і перевірити їхні manifest файли на потенційні ознаки вразливостей. Наприклад, щоб перевірити розширення з більш ніж 25000 користувачів, content_scripts та дозвіл 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)

Stealthy technique to backdoor Chromium by directly editing per-user Preferences and forging valid HMACs, causing the browser to accept and activate an arbitrary unpacked extension without prompts or flags.

Forced Extension Load Preferences Mac Forgery Windows

Виявлення шкідливих оновлень розширень (Статичне порівняння версій)

Supply-chain compromises often arrive as malicious updates to previously benign extensions. Практичний, малошумний підхід — порівняти новий пакет розширення з останньою відомо-правильною версією за допомогою статичного аналізу (наприклад, Assemblyline). Мета — сигналізувати про значущі відмінності, а не про будь-яку зміну.

Workflow

• Submit both versions (old + new) to the same static-analysis profile.
• Flag new or updated background/service worker scripts (персистентність + привілейована логіка).
• Flag new or updated content scripts (доступ до DOM і збір даних).
• Flag new permissions/host_permissions added in manifest.json.
• Flag new domains extracted from code (потенційні C2/exfil endpoints).
• Flag new static-analysis detections (наприклад, base64 decode, cookie harvesting, network-request builders, обфускаційні патерни).
• Flag statistical anomalies such as sharp entropy jumps or outlier z-scores in changed scripts.

Detecting script changes accurately

• New script added → detect via manifest.json diff.
• Existing script modified (manifest unchanged) → compare per-file hashes from the extracted file tree (e.g., Assemblyline Extract output). Це ловить приховані оновлення існуючих workers або content scripts.

Pre-disclosure detections

Щоб уникнути «easy mode» виявлень, що базуються на вже відомих IOC, відключіть сервіси, що живляться threat-intel, і покладайтеся на внутрішні сигнали (домені, евристичні сигнатури, дельти скриптів, аномалії ентропії). Це підвищує шанси виявити шкідливі оновлення до публічного розкриття.

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 (вища recall, вищий шум).

Ключові сервіси Assemblyline для цього workflow:

• Extract: розпаковує розширення і видає per-file hashes.
• Characterize: обчислює характеристики файлів (наприклад, entropy).
• JsJAWS / FrankenStrings / URLCreator: витягують JS-евристики, рядки та домени для дифу між версіями.

Security Audit Checklist

Хоча Browser Extensions мають обмежену поверхню атаки, деякі з них можуть містити vulnerabilities або вимагати посилення безпеки. Нижче наведено найпоширеніші пункти:

• Limit as much as possible requested permissions
• Limit as much as possible host_permissions
• Use a strong content_security_policy
• Limit as much as possible the externally_connectable, if none is needed and possible, do not leave it by default, specify {}
• If URL vulnerable to XSS or to takeover is mentioned here, an attacker will be able to send messages to the background scripts directly. Very powerful bypass.
• Limit as much as possible the web_accessible_resources, even empty if possible.
• If web_accessible_resources is not none, check for ClickJacking
• If any communication occurs from the extension to the web page, check for XSS vulnerabilities caused in the communication.
• If Post Messages are used, check for Post Message vulnerabilities.
• If the Content Script access DOM details, check that they aren’t introducing a XSS if they get modified by the web
• Make a special emphasis if this communication is also involved in the Content Script -> Background script communication
• If the background script is communicating via native messaging check the communication is secure and sanitized
• Sensitive information shouldn’t be stored inside the Browser Extension code
• Sensitive information shouldn’t be stored inside the Browser Extension memory
• Sensitive information shouldn’t be stored inside the file system unprotected

Browser Extension Risks

• The app https://crxaminer.tech/ analyzes some data like the permissions browser extension requests to give a risk level of using the browser extension.

Tools

Tarnish

• Pulls any Chrome extension from a provided Chrome webstore link.
• manifest.json viewer: simply displays a JSON-prettified version of the extension’s manifest.
• Fingerprint Analysis: Detection of web_accessible_resources and automatic generation of Chrome extension fingerprinting JavaScript.
• Potential Clickjacking Analysis: Detection of extension HTML pages with the web_accessible_resources directive set. These are potentially vulnerable to clickjacking depending on the purpose of the pages.
• Permission Warning(s) viewer: which shows a list of all the Chrome permission prompt warnings which will be displayed upon a user attempting to install the extension.
• Dangerous Function(s): shows the location of dangerous functions which could potentially be exploited by an attacker (e.g. functions such as innerHTML, chrome.tabs.executeScript).
• Entry Point(s): shows where the extension takes in user/external input. This is useful for understanding an extension’s surface area and looking for potential points to send maliciously-crafted data to the extension.
• Both the Dangerous Function(s) and Entry Point(s) scanners have the following for their generated alerts:
• Relevant code snippet and line that caused the alert.
• Description of the issue.
• A “View File” button to view the full source file containing the code.
• The path of the alerted file.
• The full Chrome extension URI of the alerted file.
• The type of file it is, such as a Background Page script, Content Script, Browser Action, etc.
• If the vulnerable line is in a JavaScript file, the paths of all of the pages where it is included as well as these page’s type, and web_accessible_resource status.
• Content Security Policy (CSP) analyzer and bypass checker: This will point out weaknesses in your extension’s CSP and will also illuminate any potential ways to bypass your CSP due to whitelisted CDNs, etc.
• Known Vulnerable Libraries: This uses Retire.js to check for any usage of known-vulnerable JavaScript libraries.
• Download extension and formatted versions.
• Download the original extension.
• Download a beautified version of the extension (auto prettified HTML and JavaScript).
• Automatic caching of scan results, running an extension scan will take a good amount of time the first time you run it. However the second time, assuming the extension hasn’t been updated, will be almost instant due to the results being cached.
• Linkable Report URLs, easily link someone else to an extension report generated by tarnish.

Neto

Project Neto is a Python 3 package conceived to analyse and unravel hidden features of browser plugins and extensions for well-known browsers such as Firefox and Chrome. It automates the process of unzipping the packaged files to extract these features from relevant resources in a extension like manifest.json, localization folders or Javascript and HTML source files.

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

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks

• Перевірте плани підписки!
• Приєднуйтесь до 💬 групи Discord або групи telegram або слідкуйте за нами в Twitter 🐦 @hacktricks_live.
• Діліться хакерськими трюками, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв на github.