Проактивная защита блокирует легитимный запрос администратора или разработчика — частая ситуация, особенно при работе с большими текстовыми полями или нестандартными символами в контенте. Разберём, почему это происходит и как настроить защиту, не отключая её полностью.
Как работает веб-антивирус и защита от XSS/SQL-инъекций
Модуль проактивной защиты анализирует входящие запросы на паттерны,
характерные для атак, — специфичные SQL-конструкции, теги
<script>, определённые последовательности
символов. Проблема в том, что легитимный контент иногда содержит
похожие паттерны без злого умысла: технический текст статьи
о программировании с примерами SQL или JavaScript-кода выглядит
для фильтра почти неотличимо от реальной попытки инъекции.
Типичный случай: статья с примерами кода
Публикация технической статьи, содержащей код на PHP, SQL или JavaScript (собственно, эта самая статья — характерный пример), через форму с включённой строгой проверкой веб-антивируса иногда блокируется с сообщением о потенциальной угрозе — сам контент безопасен, но по формальным признакам похож на инъекцию.
Нужна помощь с Битрикс?
Просмотр журнала срабатываний
Раздел Настройки → Инструменты разработчика → Проактивная защита → журнал атак показывает, что именно было заблокировано и по какому правилу — это первый шаг перед любой настройкой: понять, какое конкретно правило сработало и на каком именно фрагменте данных, а не отключать защиту вслепую в расчёте, что проблема исчезнет.
Исключения для конкретных полей или разделов
Вместо полного отключения проверки для всего сайта, в настройках проактивной защиты можно исключить конкретные поля формы или разделы административной панели из строгой проверки — например, поле полного текста материала в разделе, где заведомо публикуются статьи с примерами кода, при этом остальные формы сайта остаются под полной защитой.
Настройка уровня строгости фильтра
Проактивная защита обычно поддерживает несколько уровней чувствительности — более строгий уровень ловит больше потенциальных угроз, но и больше ложных срабатываний на легитимный контент, более мягкий снижает число ложных блокировок ценой чуть большего риска пропустить реальную попытку атаки. Выбор уровня — компромисс, который стоит принимать осознанно, а не оставлять значение по умолчанию без понимания, что оно означает для конкретного проекта.
Проверка для авторизованных администраторов
Часть настроек проактивной защиты позволяет ослабить проверку именно для авторизованных пользователей с правами администратора, сохраняя строгую проверку для анонимных посетителей и публичных форм, — это разумный компромисс для сайтов, где основная угроза идёт снаружи, а не от собственных редакторов контента, случайно вставляющих код в статью.
Не отключать защиту полностью
Полное отключение проактивной защиты ради избавления от ложных срабатываний — решение, которое устраняет симптом, но создаёт реальную уязвимость для всего сайта. Правильный путь — точечная настройка исключений для конкретных легитимных сценариев, а не отказ от защиты как таковой из-за неудобства при работе с техническим контентом.
Тестирование после изменения настроек
После настройки исключений стоит явно протестировать как легитимный сценарий (публикация статьи с примерами кода теперь проходит без блокировки), так и то, что защита продолжает срабатывать на реальные попытки инъекции через те же поля, — проверка только одной стороны риска ложных срабатываний и не проверка обратной стороны (реальной защиты) оставляет сайт уязвимым при неверно настроенном исключении.
Частые ошибки
- Защита отключается полностью вместо точечной настройки. Устраняет неудобство, но создаёт реальную уязвимость сайта.
- Журнал срабатываний не проверяется перед настройкой. Изменения вносятся вслепую без понимания, какое правило реально сработало.
- Исключение не протестировано на сохранение реальной защиты. Проверяется только устранение ложного срабатывания, но не то, что опасный контент по-прежнему блокируется.
Итог
Ложные срабатывания проактивной защиты на технический контент — ожидаемый побочный эффект строгих правил фильтрации, а не признак неисправности системы. Решение — точечные исключения для конкретных полей и разделов после анализа журнала срабатываний, а не полное отключение защиты, которое избавляет от неудобства ценой реальной безопасности сайта.