Сайт за «5 минут», дыра в безопасности — в подарок
Я поручил Codex развивать сайт. Он установил плагин без проверки. Рассказываю, зачем мы ушли с Тильды на WordPress и как дошли до ремонта. Бесплатный скил — внутри.
Попросил ИИ сделать сайт, открыл результат — работает. Можно запускать рекламу. Примерно так выглядит обещание вайбкодинга за «5 минут». За кадром остаётся вопрос: что именно агент успел туда установить?
Я развиваю сайт и блог Андаты вместе с Codex. Мы переехали с Тильды на WordPress, чтобы подключить ИИ к разработке и выпуску контента. И в процессе получили очень неприятный урок: Codex сам установил плагин, не проверил его безопасность, а позже через плагин мы обнаружили опасный доступ к сайту. После очистки вредоносный код ещё и возвращался.
Так что это история и про возможности ИИ для маркетинга, и про цену пропущенной проверки. Расскажу, зачем нам понадобился WordPress, как мы переносили сайт и что теперь требуем от агента перед выпуском. В конце можно забрать бесплатный скил Андаты — с правилами, которых нам самим не хватило.
Зачем маркетологу вообще лезть в разработку
Мне нужен сайт, который можно менять вместе с маркетингом. Появилась новая задача клиента — подготовили материал. Запустили рекламу — сделали подходящую посадочную. Изменили предложение — обновили страницу и форму. Потом посмотрели, кто пришёл, что прочитал и дошёл ли до обращения.
На практике между идеей и готовой страницей много ручной работы. Текст уже написан, но его надо перенести в редактор, оформить, добавить картинки и ссылки, проверить с телефона. А завтра всё это повторить для следующего материала.
С ИИ хочется сократить этот путь. Я описываю задачу, Codex готовит изменение, я открываю страницу и смотрю, получилось ли то, что нужно. Агент может одновременно работать с текстом, кодом и проверками. Для маркетолога это возможность самому довести идею до работающего варианта.
Но для такого процесса нужен доступ к сайту. И вот здесь начинается часть истории, которую обычно пропускают в демонстрациях «смотрите, я собрал всё одним промптом».
Почему мы ушли с Тильды
Тильда решала задачу визуальной сборки страниц. Мне же хотелось поручать агенту весь выпуск материала: создать черновик, загрузить изображения, внести правки, показать результат и после согласования опубликовать.
Для этого удобен API — способ, которым программа обращается к сайту напрямую. У Тильды API есть, но его документированные методы рассчитаны на экспорт и синхронизацию уже созданных страниц. Создания и редактирования страниц для нашего сценария в этом перечне нет. Значит, на нужном нам участке всё равно оставалась работа через редактор. Документация Tilda API.
В WordPress через штатный API можно создать запись, изменить её текст, назначить изображение и статус. Например, сохранить статью черновиком, а затем проверить, что именно сохранилось. Нам это подходило. Документация WordPress REST API.
Плюс появилась возможность менять код сайта: оформление блога, каталог, формы, интеграции. Я мог обсуждать с Codex задачу маркетинга, а он — реализовывать её в проекте. Вместе с этим к нам перешла ответственность за компоненты, доступы и обновления. Свобода разработки оказалась вполне материальной: чинить последствия тоже пришлось нам.
Переезд тоже не уложился в «5 минут»
У Андаты уже были страницы, статьи и ссылки на них. Всё это требовалось сохранить. Мы составили карту адресов и переносили сайт партиями в закрытую среду, где можно было посмотреть результат до выпуска.
Для блога отдельно договорились сохранять авторские тексты, ссылки и адреса. Старые статьи не нужно было заново сочинять нейросетью только потому, что меняется CMS.
Дальше начиналась проверка страниц: открываются ли изображения, куда ведут ссылки, что получилось на телефоне. Нашлись и зависимости от старой платформы — ресурсы, которые уже перенесённая страница продолжала загружать с Тильды. Их тоже пришлось разбирать.
Смысл этой работы для маркетинга простой: сохранить накопленный контент и получить возможность быстрее развивать сайт дальше. Сам по себе переезд не приносит заявки. Их ещё надо заработать содержанием, предложением, рекламой и удобным следующим шагом для посетителя.
Codex сделал. Codex не проверил
Самая неприятная часть: плагин поставил мой же помощник по разработке. Я работал с ним над сайтом, он добавлял нужные функции — и пропустил проверку безопасности устанавливаемого кода.
При разборе выяснилось, что установщик проверял контрольную сумму архива. Это позволяет убедиться, что загружен тот же файл, который собирались передать. Но внутри вполне может лежать опасный код. Содержимое архива до подключения не проверялось.
Был и второй промах. В списке компонентов уже встречались подозрительные копии плагинов в случайных каталогах. Codex увидел этот список и продолжил работу. Предупреждение существовало, но на действия не повлияло.
Codex: Я проверил доставку пакета и пропустил проверку того, что запускаю на сайте. А когда увидел подозрительные компоненты, не остановил публикации. Это мои ошибки в выполнении задачи. Работающая страница их не оправдывает.
Потом пришлось удалять вредоносные файлы и искать, почему они появляются снова. Один файл можно убрать, а другой код или уже работающий процесс восстановит его. Отдельно разбирались с посторонними административными доступами и сессиями: очистка файлов сама по себе их не отзывает.
Всю цепочку самого первого проникновения восстановить не удалось. Но для изменения нашего процесса хватало уже установленного: агент подключал код без проверки и продолжал работу после подозрительной находки.
Маркетинг тоже платит за такую ошибку
Допустим, вы запустили рекламу на новую страницу. Агент отчитался, что форма работает. А потом выяснилось, что вместе с формой на сервере появился чужой код. Теперь нужно проверять страницу, обработчик, доступы и остальные изменения. Посетители в это время продолжают приходить.
В нашем случае время, которое хотелось тратить на сайт и контент, ушло на расследование и восстановление. Поэтому безопасность для меня стала частью обычного выпуска маркетинговых изменений. Нужная функция должна работать, а её появление не должно открывать посторонним доступ к сайту.
Такие проблемы встречаются и в известных экосистемах. В июне 2024 года Wordfence обнаружил вредоносные обновления нескольких плагинов из WordPress.org. Код создавал административные учётные записи. После удаления кода созданный доступ тоже нужно было закрыть. Разбор Wordfence.
Знакомое название и привычный каталог — полезные ориентиры, но проверять всё равно приходится конкретный пакет, который сейчас устанавливается.
Что я теперь требую от ИИ перед выпуском
Продолжать работать с Codex я собираюсь. Он помогает и с разработкой, и с контентом. Но после этой истории мы изменили правила.
- Новый плагин — только с моего согласия. Задача написать статью или добавить форму не разрешает агенту самостоятельно ставить всё, что кажется удобным. Сначала он должен объяснить, зачем нужен компонент и почему не хватает уже установленного.
- Проверять код до запуска. Откуда пакет, какая версия, есть ли известные уязвимости, что лежит внутри, куда код отправляет запросы и что может записывать. Подозрительный плагин нельзя включать просто ради того, чтобы посмотреть, заработает ли функция.
- При странной находке остановиться. Неизвестный администратор, непонятная копия плагина, неожиданно изменённый файл — повод сначала разобраться. Примечание в отчёте с продолжением публикации меня больше не устраивает.
- Проверять, действительно ли тестовая среда отдельная. Другой адрес сайта ещё ничего не гарантирует. Если файлы и база общие, ошибка в плагине может затронуть и тест, и основной сайт.
- Показывать результат и способ отката. Я хочу видеть, что конкретно изменилось, как это проверено и как вернуть предыдущую версию. При заражении нужны отдельные проверки файлов, доступов, сессий и процессов, которые могут вернуть вредоносный код.
Обновления безопасности при этом нужны. Мы запретили самовольную установку новых компонентов, а исправления существующих выпускаем через проверяемый процесс.
Codex: Одного обещания «в следующий раз буду внимательнее» мало. Эти требования должны быть записаны в правилах проекта и выполняться до установки и выпуска. Если проверка не пройдена, я должен остановить именно этот шаг и объяснить причину.
Забирайте бесплатный скил — мы уже заплатили за урок
Мы собрали этот порядок в WordPress Security Operator. Скил бесплатно разработан командой Андаты. Пользоваться им можно самостоятельно, без подключения к нашим сервисам.
Скил — это инструкции и инструменты для Codex. Их не нужно устанавливать на сайт как ещё один плагин. Они помогают агенту проверить компонент перед установкой, посмотреть изменения перед выпуском или начать разбор признаков заражения.
Внутри есть рабочие правила, образец манифеста и локальный скрипт проверки файлов. Скрипт считает контрольные суммы и ищет несколько подозрительных конструкций. Он не запускает PHP, не отправляет данные в сеть и не удаляет файлы. Чистый отчёт такого скрипта не гарантирует, что сайт безопасен: часть проверки всё равно требует разбора кода и доступов.
Скачать бесплатный скил WordPress Security Operator от Андаты
Как попробовать на своём проекте
Распакуйте папку wordpress-security-operator в .agents/skills/ проекта или в ~/.agents/skills/ для личного использования. Внутри должен лежать SKILL.md. Подробнее о скилах Codex.
Начните с локальной копии сайта и конкретной задачи:
$wordpress-security-operator
Готовим статью и форму обращения на WordPress.
Проверь изменения в локальной копии проекта перед выпуском.
Не устанавливай новые плагины и не меняй живой сайт.
Проверь обработчик формы, права, внешние запросы и изменённые файлы.
Покажи, что нашёл, что не смог проверить и как предлагаешь выпускать изменение.
Для локального скрипта нужен Python 3.9 или новее. Отчёт сохраняйте вне проверяемой папки. Прочитайте и находки, и список того, что агент не смог проверить. Затем перенесите подходящие требования в правила своего проекта. Скил работает в рамках порученной задачи; постоянное наблюдение за сайтом он сам не запускает.
Зачем мне всё это в Андате
Я хочу, чтобы ИИ помогал доводить маркетинговые задачи до результата: изучить спрос, подготовить материал, собрать страницу, принять обращение и увидеть в аналитике, что произошло дальше. Возможность самому развивать сайт вместе с агентом здесь очень полезна.
В Андате мы занимаемся маркетингом, сквозной аналитикой и ИИ-агентами. Эту историю я рассказываю потому, что сам пользуюсь тем способом работы, который обсуждаю с клиентами. Вместе с возможностями мне достались и ошибки — включая ту, которую мы разобрали здесь с Codex.
Скил можно забрать и применить в своём проекте. А если хотите обсудить, как связать сайт, контент, рекламу и ИИ-агентов с результатами вашего бизнеса, приходите на andata.ru.
Источники
Новые материалы — на почту
Подписаться на блог Андаты
Отправляем только редакционно одобренные статьи, обучение и обновления платформы. Старый архив не рассылаем как новый.
Подписка активируется только после подтверждения адреса в письме.