Почему ваш сайт может быть заражён изнутри — и как это предотвратить
Наткнулся на разбор, как 25 популярных менеджеров пакетов не проверяют целостность кода — и это не просто техническая погрешность. Это риск для любого сайта, где используется внешний код.
О чём речь и почему я считаю это важным для сайта
Речь не о том, что кто-то взломал сайт вчера. Речь о том, что уязвимость может быть в самом коде, который вы используете — и вы даже не знаете, что он заражён. Каждый пакет, который вы скачиваете, может быть подменён. И если он входит в ваш сайт — он уже не ваш.
Я считаю это важным, потому что заражение не всегда видно. Не всегда появляется вредоносный скрипт или майнер. Иногда — просто баг, который работает не так, как должен. А потом — утечка, взлом, блокировка поисковиками. И всё это началось с одного пакета, который вы не проверяли.
Как это устроено — что тут вообще происходит
Когда вы устанавливаете библиотеку, например, через npm или Composer, система скачивает код с репозитория. Но если репозиторий взломан — код может быть подменён. А проверка целостности? Она есть, но работает только в двух из 25 менеджеров по умолчанию.
Самое страшное — это не то, что кто-то взломал ваш сайт. Это то, что вы не знаете, что ваш сайт уже заражён. Боты сканируют уязвимости, а не выбирают «цели». И если у вас есть слабое звено — они туда влезут. Даже если вы не смотрели в репозиторий.
Как понять, что это касается вашего сайта
Я проверяю это первым делом: смотрю, какие пакеты используются, и проверяю, есть ли у них lock-файл с хешами. Если его нет — риск высок. Если есть, но хеши не проверяются — тоже риск.
Сайт может быть заражён и без явных признаков. Я ищу в логах нестандартные вызовы, в коде скрипты, которые не должны быть там. А потом — проверяю, не был ли код подменён в процессе установки. Это не про «я не знаю, как это работает» — это про то, что у вас может быть уязвимость, которую вы не видите.
Что с этим делать
Я начинаю с резервной копии. Потом — проверяю все зависимости, смотрю, какие пакеты были установлены, и как они проверяются. Если нет проверки целостности — добавляю её.
Потом — удаляю всё подозрительное, проверяю, не осталось ли следов. Но главное — не просто почистить. Надо закрыть причину. Иначе вернётся. Я включаю мониторинг изменений в коде, проверяю, кто и когда что добавил. Это не разовая работа — это постоянная защита.
Что здесь даёт поддержка
Мы закрываем эту задачу на постоянной поддержке так: не просто убираем вредоносный код, а ищем, откуда он пришёл, и блокируем точку входа. Проверяем все зависимости, включая те, что не используются. Устанавливаем проверку целостности по умолчанию.
Проверяем, не был ли код подменён в процессе установки. Следим за изменениями в репозиториях. И если что-то подозрительно — сразу реагируем. Потому что уязвимость — это не «может быть», это «уже есть». И мы не ждём, пока поисковик заблокирует сайт.