Главная › Блог › Проверка сайта на уязвимости: как интернет-магазину найти слабые места до распро

Проверка сайта на уязвимости: как интернет-магазину найти слабые места до распродаж

27 октября 2026 · 11 мин чтения

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

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

Коротко

Начните с инвентаризации: ядро CMS, каждый модуль или плагин, шаблон, версия PHP. Без списка версий сканировать бессмысленно.
Сверьте каждое стороннее расширение с базами уязвимостей: БДУ ФСТЭК для решений на 1С-Битрикс, Patchstack и аналоги для WordPress.
PHP 8.1 не получает исправлений безопасности с 31 декабря 2025 года, у PHP 8.2 поддержка заканчивается 31 декабря 2026 года.
Встроенные инструменты бесплатны: «Сканер безопасности» в 1С-Битрикс и «Здоровье сайта» в WordPress.
Проверьте снаружи, не отдаёт ли сайт .git, .env, архивы и логи отладки.
Онлайн-сканер по адресу видит только то, что видно снаружи. Уязвимость в модуле за авторизацией он обычно не найдёт.

Почему это важно сейчас

До «Чёрной пятницы», которая в 2026 году приходится на 27 ноября, остаётся месяц. Обновлять модули в разгар распродажи рискованно. Значит, найти и закрыть уязвимости стоит в ближайшие две-три недели, пока есть время протестировать изменения.

Свежие примеры показывают, где обычно находятся дыры. 2 марта 2026 года команда WooCommerce сообщила об уязвимости в версиях с 5.4 по 10.5.2: через подделку межсайтового запроса (CSRF) можно было создать учётную запись администратора, если вошедший администратор открывал вредоносную ссылку. Исправления выпустили для всех 52 затронутых версий, магазинам с включённым автообновлением их установили автоматически. Остальным нужно было обновиться вручную. Следов реальной эксплуатации команда, по её словам, не обнаружила.

В 2026 году в Банк данных угроз ФСТЭК внесли уязвимость модуля «Универсальный импорт» компании «Акрит» для 1С-Битрикс (BDU:2026-08076, оценка CVSS 8,6). Причина в отсутствии аутентификации для критичной функции: удалённый злоумышленник мог выполнять операции через административный интерфейс. Это сторонний модуль импорта, а такие расширения обновляют реже, чем ядро.

Старые уязвимости тоже живут годами. В октябре 2025 года CyberOK сообщила, что из примерно миллиона активных установок 1С-Битрикс около 150 тысяч по внешним признакам уязвимы к BDU:2023-05857 в модуле landing (CVSS 10). Исправление вышло в сентябре 2023 года в версии 23.850.0.

Последний повод касается сервера. По данным php.net, PHP 8.1 перестал получать исправления 31 декабря 2025 года, а PHP 8.2 получает только исправления безопасности до 31 декабря 2026 года. Если магазин работает на 8.1 или старше, новые уязвимости самого PHP уже никто не закроет. Если на 8.2, переход нужно планировать сейчас: в январе праздники, а потом будет поздно.

План проверки на один день

Шаг 1. Составьте список всего, что установлено (1 час)

1С-Битрикс. Откройте «Marketplace → Установленные решения» и «Настройки → Обновление платформы». Выпишите редакцию и версию главного модуля, версии модулей ядра, все решения из Marketplace и шаблон. Отдельно отметьте сторонние модули обмена, импорта, оплаты и доставки.

WordPress/WooCommerce. Откройте «Инструменты → Здоровье сайта → Информация». Там есть версия WordPress, активные и неактивные плагины и темы с версиями и состоянием автообновления, а также данные сервера. Кнопка копирования отчёта сохранит всё одним текстом.

Самописный сайт. Попросите разработчика выгрузить список зависимостей с версиями (например, composer.lock или package-lock.json) и версию PHP.

Шаг 2. Сверьте версии с базами уязвимостей (1–2 часа)

Для каждого стороннего расширения найдите его название в базах:

БДУ ФСТЭК (bdu.fstec.ru) и её зеркала с поиском: российские модули и решения для 1С-Битрикс попадают сюда.
Patchstack Database: база уязвимостей плагинов и тем WordPress. В каждой записи есть диапазон уязвимых версий, тип уязвимости и оценка риска.
Новости разработчика модуля и раздел обновлений в Marketplace: иногда исправление выходит раньше, чем запись в базе.

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

Шаг 3. Запустите встроенные проверки CMS (30 минут)

1С-Битрикс. В разделе «Безопасность сайта → Проактивная защита → Сканер безопасности» нажмите «Запустить сканирование». По документации курса администратора сканер проверяет окружение (например, как хранятся файлы сессий), настройки сайта (включён ли WAF, задан ли пароль к базе данных), права доступа к файлам, ищет потенциальные уязвимости в коде статическим анализом и проводит внешнее сканирование. Внешнее сканирование работает, только если сайт доступен из интернета и в настройках главного модуля указан правильный «URL сайта». Для анализа кода нужно расширение PHP Tokenizer.

WordPress. На вкладке «Состояние» в «Здоровье сайта» смотрите критические проблемы с типом «Безопасность». Среди них устаревшая версия PHP, плагины, ожидающие обновления, вывод ошибок посетителям (WP_DEBUG_DISPLAY) и запись ошибок в файл, который может быть доступен всем (WP_DEBUG_LOG). Здесь же видно, работают ли фоновые обновления.

Шаг 4. Проверьте версию PHP (15 минут)

Версию видно в «Здоровье сайта» WordPress, в «Проверке системы» 1С-Битрикс и в панели хостинга. Сравните её с таблицей поддерживаемых версий на php.net. На октябрь 2026 года поддерживаются ветки 8.2, 8.3, 8.4 и 8.5, причём 8.2 и 8.3 получают только исправления безопасности. Перед переходом проверьте совместимость модулей на копии сайта.

Шаг 5. Посмотрите на сайт снаружи (30 минут)

Проверьте, что сервер не отдаёт служебные файлы: каталог .git, файл .env, архивы бэкапов в корне, дампы базы, phpinfo.php, лог отладки WordPress. Такие находки встречаются после ручного переноса сайта или работы подрядчика прямо на боевом сервере. Команда для проверки приведена ниже.

Тут же убедитесь, что сайт открывается только по HTTPS, а HTTP-версия перенаправляет на защищённую.

Шаг 6. Проверьте, у кого есть ключи (30 минут)

Откройте список пользователей с правами администратора в CMS, учётные записи FTP/SFTP и SSH, доступы к панели хостинга. Удалите бывших сотрудников и подрядчиков. Включите двухфакторную аутентификацию там, где она есть. Удалите неактивные плагины, темы и решения, которые не планируете включать: выключенный код всё равно лежит на сервере.

Шаг 7. Закройте найденное и перепроверьте

Обновляйте на копии сайта, затем на боевом, а после каждого обновления проходите путь покупателя: каталог, корзина, оформление, оплата, письмо о заказе. Как обновлять 1С-Битрикс без поломки магазина, мы разобрали в отдельной статье.

Кто и как часто проверяет

Риск	Ответственный	Как проверить	Частота
Уязвимый сторонний модуль или плагин	Подрядчик на поддержке	Сверка списка версий с БДУ ФСТЭК / Patchstack	Раз в неделю и после новостей об уязвимостях
Устаревшее ядро CMS	Подрядчик	«Обновление платформы» в Битрикс, «Обновления» в WordPress	Раз в месяц
PHP без поддержки	Подрядчик + хостинг	Таблица на php.net, версия в панели хостинга	Раз в квартал, обязательно до конца года
Открытые служебные файлы	Подрядчик	Запрос к путям снаружи (команда ниже)	После каждого переноса и релиза
Лишние администраторы и доступы	Владелец магазина	Список пользователей CMS, FTP, SSH, хостинга	Раз в месяц и при смене подрядчика
Ошибки настройки	Подрядчик	«Сканер безопасности» Битрикс, «Здоровье сайта» WordPress	Раз в месяц

Артефакт: команда для проверки открытых файлов

Запускайте только для своего сайта или сайта клиента, с которым у вас договор на поддержку. Команда отправляет по одному GET-запросу на каждый путь и выводит HTTP-код ответа.

#!/usr/bin/env bash
# Проверка: не отдаёт ли сайт служебные файлы. Использование: ./exposed.sh https://shop.example.ru
SITE="${1%/}"
PATHS=(
  "/.git/HEAD"
  "/.env"
  "/.htpasswd"
  "/backup.zip"
  "/backup.tar.gz"
  "/dump.sql"
  "/db.sql"
  "/phpinfo.php"
  "/info.php"
  "/wp-content/debug.log"
  "/composer.lock"
)
for p in "${PATHS[@]}"; do
  code=$(curl -s -o /dev/null -w "%{http_code}" --max-time 10 "$SITE$p")
  printf "%s  %s\n" "$code" "$p"
done
echo "--- HTTP -> HTTPS:"
curl -s -o /dev/null -w "%{http_code} -> %{redirect_url}\n" --max-time 10 "http://${SITE#https://}/"

Как читать результат: код 200 у любого пути, кроме последней строки, требует разбора. Откройте адрес в браузере и посмотрите, что внутри. Некоторые сайты отвечают 200 на любой адрес и показывают свою страницу 404, это ложное срабатывание. Коды 403 и 404 нормальны. В последней строке ожидается 301 или 308 с адресом на https://.

Список путей дополните своими: названия архивов, которые делает ваш хостинг, и старые копии сайта вроде /old/ или /test/.

Пример разбора

Пример условный, собран для иллюстрации.

Магазин на 1С-Битрикс, поддержку ведёт фрилансер. В конце октября владелец просит проверить сайт перед распродажей. Инвентаризация показывает девять решений из Marketplace, два из них выключены, у модуля импорта из прайсов поставщика последнее обновление было полтора года назад. Сверка с БДУ находит для этого модуля запись об отсутствии аутентификации в административной функции, версия магазина попадает в уязвимый диапазон.

«Сканер безопасности» отмечает отключённый WAF. Команда проверки файлов возвращает 200 на /backup.zip: архив остался после переезда на новый хостинг год назад. PHP на сервере версии 8.1.

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

Частые ошибки

Проверить только онлайн-сканером. Сканер по адресу видит заголовки, сертификат, открытые файлы и версию CMS, если она торчит наружу. Уязвимость в модуле за авторизацией он не увидит. Без списка версий проверка неполная.
Обновить ядро и забыть про сторонние модули. Ядро 1С-Битрикс и WordPress обновляются централизованно. Решения из Marketplace и коммерческие плагины часто обновляются отдельно, а иногда требуют продления лицензии.
Оставить выключенные расширения. Выключенный модуль не работает в магазине, но его файлы лежат на сервере.
Обновлять в день распродажи. Любое обновление может сломать оформление заказа. Окно для изменений заканчивается за одну-две недели до пика.
Считать, что хостинг всё сделает. Хостинг обычно отвечает за сервер и иногда за версию PHP. Модули, плагины и пользователи CMS остаются на вас и вашем подрядчике.

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

Вопросы и ответы

Можно ли проверить сайт на уязвимости онлайн бесплатно?

Частично. Онлайн-сканеры и команда из этой статьи покажут то, что видно снаружи: открытые файлы, HTTPS, иногда версию CMS. Встроенный «Сканер безопасности» 1С-Битрикс и «Здоровье сайта» WordPress тоже бесплатны и видят больше, потому что работают изнутри. Сверка версий с БДУ ФСТЭК или Patchstack занимает время, но денег не стоит.

Чем проверка на уязвимости отличается от проверки на вирусы?

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

Как часто проверять интернет-магазин на уязвимости?

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

Как не пропустить последствия

Шаги 1–6 выполняет человек: сервис мониторинга не обновит модуль и не сверит версии с БДУ. Но если уязвимостью всё-таки воспользовались, это часто видно снаружи раньше, чем изнутри. Pingvera проверяет сайт раз в минуту, в том числе из разных регионов и с мобильным User-Agent, следит за неожиданными редиректами на чужие домены, признаками взлома WordPress и сроком SSL-сертификата. CMS-коннекторы для WordPress и 1С-Битрикс показывают состояние сайта изнутри. Бесплатный тариф покрывает до 5 сайтов.

Источники

Проверено: 27 октября 2026 года

Узнавайте о проблеме раньше клиента

Pingvera следит за сайтами клиентов «снаружи и изнутри» — доступность из регионов, формы, оплата, домен, SSL, сервер — и предупреждает в Telegram, email и Max раньше, чем напишет клиент.

Попробовать Pingvera бесплатно

← Все статьи · Политика конфиденциальности · pingvera.ru · Telegram-канал