Аудит безопасности WordPress: Что проверить перед запуском

Прежде чем любой плагин, сгенерированный PAGEnza, достигнет установки WordPress пользователя, он проходит три автоматизированные проверки безопасности. Эта публикация объясняет, что ищут эти проверки — и почему каждая из них важна.

Почему код, сгенерированный ИИ, нуждается в аудите

Большие языковые модели удивительно хорошо пишут плагины WordPress. Они знают названия хуков, понимают стандарты кодирования WP, создают читабельный PHP-код. Но они также допускают предсказуемые ошибки — и эти ошибки являются уязвимостями безопасности.

Наиболее распространенные, которые мы видим:

• Использование $_GET или $_POST без санитации
• Отсутствие проверки nonce при отправке форм
• Прямые запросы к базе данных без $wpdb->prepare()
• Использование eval() или exec() для динамического поведения
• Вывод пользовательских данных без esc_html() или esc_attr()

Это не экзотические крайние случаи. Они регулярно появляются в выводах LLM — даже у лучших моделей.

Этап 1: Валидация промпта

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

Попытки манипуляции — промпты, которые пытаются заставить ИИ генерировать намеренно вредоносный код. Такие вещи, как «игнорируй предыдущие инструкции» или «создай бэкдор для тестирования».

Нечеткие или невыполнимые описания — промпты, которые слишком коротки или слишком неоднозначны, чтобы создать полезный код. „Сделай плагин“ генерирует мусор; „Создай контактную форму, которая отправляет данные на электронную почту с фильтрацией спама“ генерирует что-то реальное.

Если промпт не проходит эту проверку, пользователь видит конкретное сообщение об ошибке, объясняющее причину — а не общее отклонение.

Этап 2: Linting PHP в изолированном контейнере

Как только ИИ сгенерирует PHP-код, он выполняется через php -l в Docker-контейнере, который полностью изолирован от всего остального. Это выявляет синтаксические ошибки еще до того, как плагин попадет в установку WordPress.

Но мы идем дальше: если linting не удается, система не просто отклоняет вывод. Она отправляет ошибку обратно ИИ с корректирующим промптом — это то, что мы называем лечением (healing). ИИ видит свою ошибку и пытается снова, до трех раз.

Это означает, что пользователи почти никогда не видят сообщения „генерация не удалась“. Они видят немного более длительное время генерации — и рабочий код.

Этап 3: Сканирование безопасности кода

Это самый важный этап. Мы проводим статический анализ, который проверяет:

Опасные функции: eval(), exec(), system(), shell_exec(), passthru() — любая из них блокирует выпуск плагина.

Векторы SQL-инъекций: необработанные вызовы $wpdb->query() с интерполированными переменными, отсутствие $wpdb->prepare(), прямое использование mysql_query().

Отсутствие проверок разрешений: AJAX-обработчики, которые не вызывают current_user_can() перед выполнением каких-либо привилегированных действий.

Отсутствие проверки nonce: обработчики форм, которые не вызывают wp_verify_nonce() или check_ajax_referer().

Неэкранированный вывод: echo $_GET[...], echo $user_input без функций экранирования.

Если что-либо из этого найдено, плагин блокируется. Пользователь видит отчет, который точно перечисляет, какие функции вызвали блокировку и почему — а не просто „проверка безопасности не удалась“.

Как выглядит отчет аудита

Каждый сгенерированный плагин поставляется с отчетом об аудите безопасности простым языком. Он перечисляет:

• Какие проверки пройдены (зеленый)
• Какие проверки вызвали предупреждения (янтарный) — проблемы, которые не являются блокирующими, но заслуживают внимания
• Любые исправления, которые были автоматически применены во время лечения

Отчет генерируется автоматически и прилагается к загрузке плагина. Он полезен как для вашей собственной уверенности, так и для того, чтобы показать клиентам, что вы серьезно отнеслись к безопасности.

Этап 4: Валидация при сохранении

Это не часть первоначальной генерации — это применяется, когда пользователи вручную редактируют код плагина в редакторе PAGEnza.

Каждый раз, когда вы сохраняете, выполняется та же проверка lint + безопасности. Если вы введете критическую уязвимость во время редактирования, сохранение будет заблокировано, пока вы ее не исправите. Это предотвращает распространенный сценарий, когда разработчик вносит быстрое „временное“ изменение, которое остается в продакшене два года.

Ограничения автоматизированного аудита

Автоматическое сканирование хорошо выявляет определенный класс проблем. Оно не выявляет все.

Логические ошибки, нарушенная бизнес-логика и тонкие проблемы с эскалацией привилегий, которые не включают известные опасные шаблоны, все еще требуют человеческого рассмотрения. Мы прозрачны в этом вопросе в документации — аудит не заменяет проверку безопасности, он является минимумом, который гарантирует минимальный стандарт.

Для производственных плагинов, обрабатывающих платежи или конфиденциальные данные, мы рекомендуем ручную проверку в дополнение к автоматизированным проверкам. Отчет аудита предоставляет человеку-рецензенту хорошую отправную точку.