Как не пустить подменённый плагин на сайт

Проверяйте происхождение расширения до установки: берите архив у автора или из официального каталога, сверяйте доступные контрольные суммы, тестируйте на копии сайта и записывайте результат. Это не доказывает, что код безопасен, но помогает не ставить неизвестный пакет вслепую и заметить подмену.

Почему плагин с форума опаснее устаревшего ядра

В прошлой статье серии мы разбирали CVE-2026-60137 и CVE-2026-63030 в WordPress. Эти уязвимости исправлены в выпусках WordPress 6.8.6, 6.9.5 и 7.0.2 для затронутых веток: детали зависят от версии. Но уязвимость в известном коде и намеренная подмена пакета — разные проблемы. В первом случае помогает установленное исправление, во втором нужно выяснить происхождение файлов. Поэтому проверка расширений для меня — часть информационной безопасности сайта, рядом с обновлениями и учётом компонентов.

Начинаю с перечня компонентов: ядро, тема, плагины и модули, их версии и ответственные за сопровождение. Если у расширения нельзя установить автора и канал получения обновлений, его сложнее проверить и поддерживать. Отдельная проблема — заброшенные компоненты: исправление может задерживаться или вовсе не выйти. Тогда даже честный авторский код становится нашей ответственностью. Я проверяю, есть ли у проекта актуальные версии и понятный способ сообщить об ошибке, а при сомнениях планирую замену.

Представим, что администратор скачал «премиум бесплатно» из случайного архива и загрузил через панель. Сайт может продолжить работать как обычно, хотя внутри пакета уже лежит код, который создаёт учётную запись или меняет содержимое страниц. Это не неизбежный результат каждого неофициального скачивания, но проверить автора и происхождение такого архива значительно труднее. Снаружи сайт может выглядеть нормально; отсутствие явных симптомов ничего не доказывает. Проверка начинается до загрузки на рабочий сайт.

Какие источники расширений считать допустимыми

Для WordPress я начинаю с каталога wordpress.org/plugins или сайта коммерческого разработчика, у которого организация получила лицензию. Для 1С-Битрикс — с Marketplace и канала поставщика, указанного в документах покупки. Для Joomla — с Joomla Extensions Directory (JED) и страницы автора, на которую ведёт карточка расширения. Для OpenCart проверяю официальный маркетплейс и страницу разработчика. Форум, файлообменник, зеркало или ZIP из переписки не становятся доверенными только потому, что расширение там скачивается быстрее.

Запись в официальном каталоге — не сертификат безопасности. Это понятный источник, карточка автора и обычный канал обновления, но у опубликованного кода тоже бывают ошибки, а заброшенные расширения могут оставаться доступными. В правилах каталога WordPress указаны требования к публикации и дальнейшему сопровождению, однако они не заменяют проверку именно вашей версии и настроек сайта. Я использую каталог как проверяемую исходную точку, а не как обещание безошибочности.

Список допустимых источников держу коротким и письменным. Назначаю того, кто может одобрить исключение, и записываю для него основание, срок пересмотра и ответственного. Иначе «временный» архив из чата со временем превращается в постоянный компонент без владельца. Правило должно отвечать на два простых вопроса: откуда берём пакет и кто принимает решение, если стандартный источник недоступен.

• WordPress: каталог wordpress.org и сайты разработчиков с купленной лицензией
• 1С-Битрикс: Marketplace и партнёры по договору
• Joomla: Joomla Extensions Directory и сайт автора из карточки JED
• OpenCart: официальный маркетплейс и сайт автора
• Запрещено по умолчанию: форумы, файлообменники, «пересборки», присланные архивы

Как сверить автора и сам пакет перед установкой

Проверяю карточку расширения: кто разработчик, где его сайт, как давно выходила версия, с какими версиями CMS заявлена совместимость, отвечает ли автор на вопросы. Смена владельца сама по себе не доказывает проблему, но это повод посмотреть журнал изменений и понять, кто теперь выпускает обновления. Если у проекта давно нет релизов и поддержки, отмечаю его как кандидат на замену и проверяю, есть ли поддерживаемая альтернатива. Решение зависит от функции и риска конкретного сайта.

Затем смотрю сам архив, полученный из разрешённого источника. Проверяю состав и структуру файлов, неожиданные PHP-файлы в каталогах изображений, длинные закодированные строки, динамическое выполнение кода и внешние обращения, не нужные функции расширения. Каждый такой признак требует разбора, но сам по себе ещё не доказывает вредоносность: похожие конструкции встречаются и в обычном коде. Быстрая проверка глазами не заменяет полноценный аудит. На копии сайта проверяю основные сценарии и журналы ошибок до выпуска.

У плагинов WordPress из каталога wordpress.org WP-CLI сверяет файлы с контрольными суммами, опубликованными для соответствующей версии. Команда не проверяет коммерческие и собственные плагины, если для них нет эталонных сумм, и чистый результат не доказывает безопасность замысла автора. Для коммерческого ZIP сохраняю SHA-256 исходного архива, источник, версию и дату. Позже этот хэш поможет сравнить архив с сохранённым оригиналом; он не скажет, что авторский код добросовестен. Если файлы на сайте отличаются от проверенного пакета, выясняю причину, прежде чем делать вывод об инциденте.

• Автор: сайт, другие продукты, ответы в поддержке
• Дата последней версии и совместимость с ядром
• Смена владельца плагина — повод читать изменения
• Лишние PHP в каталогах ресурсов, eval, длинный base64
• Хэш архива — в журнал проверки

Как запретить установку расширений из админки

Если администраторы могут ставить ZIP из панели, письменный список источников легко обойти. В WordPress DISALLOW_FILE_EDIT отключает встроенный редактор файлов тем и плагинов. DISALLOW_FILE_MODS запрещает операции установки и обновления файлов через админку, в том числе для плагинов и тем; он также блокирует фоновые обновления, поскольку WordPress не может менять файлы. Это настройка процесса, а не кнопка «сделать сайт безопасным»: обновления нужно выполнять отдельно, например через контролируемый WP-CLI или деплой, и проверять после выпуска.

Ограничиваю и права на файловой системе. Код сайта должен изменять только тот процесс или пользователь, которому это нужно для установки и выпуска. Если веб-процесс имеет запись во все каталоги кода, компрометация этого процесса упрощает подмену файлов. Загрузки отделяю по правам и настройкам веб-сервера так, чтобы загруженные пользователями скрипты не исполнялись. Конкретные правила зависят от CMS, веб-сервера и способа деплоя; копировать чужую директиву вслепую не стоит.

Для Joomla и Битрикса настройки отличаются, но принцип тот же: право добавлять расширения оставляю ограниченному кругу ответственных людей. Контент-менеджеру обычно не нужны права на установку кода, чтобы публиковать текст и изображения. Разделение ролей снижает вероятность случайной установки, но не отменяет журнал изменений, резервную копию и проверку того, что именно попало на сайт. Учётная запись администратора — часть цепочки поставки, поэтому общие логины здесь особенно мешают разбору.

Журнал проверки: что записывать перед выпуском

Запись о проверке нужна до установки, пока можно восстановить происхождение пакета. Фиксирую название и версию расширения, автора, URL источника, дату загрузки, хэш архива, результаты просмотра, ответственного и дату выпуска. Для контрольной суммы WordPress отмечаю, что именно проверялось и были ли предупреждения. Журнал храню отдельно от сайта, чтобы после сбоя или компрометации осталась независимая история. Это может быть таблица с ограниченным доступом: сложная система сама по себе дисциплину не создаёт.

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

Пересматриваю перечень по расписанию и при заметных изменениях: смене владельца проекта, прекращении поддержки или предупреждении о безопасности. Слежу за выпусками и уведомлениями разработчика: если выходит исправление, проверяю его на копии сайта и планирую обновление, а не оставляю уязвимую версию без срока. Версию после выпуска записываю в журнал. Удаляю расширения, которые не используются, предварительно проверив зависимость сайта от них. Чем меньше лишнего кода, тем меньше компонентов приходится учитывать и обновлять. Но число плагинов само по себе не измеряет безопасность: один необходимый, но заброшенный модуль может требовать больше внимания, чем несколько поддерживаемых.

• Название, версия, источник, автор
• SHA-256 архива
• Что проверили в коде и на копии сайта
• Кто одобрил и дата выпуска
• Список администраторов и плагинов до и после

Разбор на условном сайте-портфолио

Возьмём типовой WordPress-сайт, где владелец обнаружил незнакомого администратора и PHP-файл в загрузках. Эти признаки требуют проверки, но не позволяют сразу назвать виновником плагин. Сначала сохраняю список файлов и учётных записей, журналирую время обнаружения, ограничиваю доступ к панели и делаю копию для разбора. Затем сопоставляю изменения с журналом выпусков и проверяю, не было ли легитимной работы подрядчика.

Если выясняется, что часть расширений пришла из архивов неизвестного происхождения, не пытаюсь «лечить» их выборочным удалением подозрительной строки. Сверяю состав сайта с известными исходными пакетами и контрольными суммами там, где они доступны, проверяю резервные копии и заменяю сомнительные компоненты официальными копиями или поддерживаемыми аналогами. Перед восстановлением проверяю данные и доступы: просто распаковать чистый WordPress поверх неизвестного набора файлов недостаточно.

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

Проверка происхождения отвечает на вопрос «какой код мы установили», а разграничение ролей — на вопрос «кто может добавить новый». В следующем материале серии — [cms-least-privilege-admin-accounts](cms-least-privilege-admin-accounts) — разбираем отдельные учётные записи и минимальные права. Правила без разграничения доступа быстро становятся памяткой, которую никто не обязан соблюдать.

Частые вопросы