WAF для защиты от SQL-инъекций и XSS: тонкости настройки

articles

WAF закрывает большую часть попыток эксплуатации SQL-инъекций и XSS на входе, но только если вы понимаете, где именно он смотрит на трафик. Классическая ловушка: администратор включает облачную защиту, видит в логах десятки блокировок и считает задачу решенной. А через неделю из формы обратной связи утекает база через слепую инъекцию, потому что тело запроса ушло в JSON, который фильтр просто не разобрал. Ниже разберу, как настроить WAF так, чтобы он реально ловил атаки на параметры, и почему санитизацию на бэкенде все равно никто не отменял.

Как WAF анализирует запросы и где проходит граница его возможностей

WAF работает на уровне L7 и разбирает HTTP-запрос на составляющие: строку запроса, заголовки, cookies и тело. Сигнатурный анализ (набор правил вида ModSecurity CRS или собственные сигнатуры вендора) ищет характерные паттерны: UNION SELECT, OR 1=1, sleep(), benchmark(), теги <script>, обработчики onerror=, javascript: в href. Плюс поведенческий анализ: аномальная частота запросов, нетипичные User-Agent, попытки обхода через кодировки.

Ключевой момент, который многие упускают: WAF по умолчанию парсит параметры запроса в GET и application/x-www-form-urlencoded в POST. Это классическая форма, которую отправляет любой браузер при сабмите. Здесь защита работает предсказуемо. Проблема начинается, когда фронтенд отправляет данные через application/json или multipart/form-data с вложенной структурой. Многие WAF, включая популярные облачные решения, видят JSON как непрозрачный блоб и не разворачивают вложенные объекты и массивы до уровня отдельных значений.

Практический пример. Форма логина отправляет:

{“user”:{“login”:”admin’ OR ‘1’=’1″},”pass”:”x”}

Если WAF не парсит вложенный JSON, значение admin’ OR ‘1’=’1 для него неотличимо от обычной строки. Правило не сработает. Запрос дойдет до бэкенда, и если там конкатенация SQL-строки вместо подготовленного выражения, инъекция пройдет. То же самое с XSS: полезная нагрузка в JSON-поле comment внутри объекта payload не будет распознана, если парсер не рекурсивный.

Отсюда вывод, который стоит зафиксировать: WAF это первый эшелон, а не единственный. Он снимает массовый автоматизированный шум, сканеры, ботов с готовыми эксплойтами. Но рассчитывать, что он закроет все векторы ввода, включая вложенный JSON, нельзя.

Режимы работы и почему блокировка сразу не всегда верна

WAF обычно работает в двух режимах: обнаружение (log only) и блокировка. Первые 1-2 недели после включения имеет смысл держать обнаружение, чтобы собрать статистику ложных срабатываний. Правила CRS агрессивны: они могут блокировать легитимные запросы, например, если в поле поиска пользователь ввел фразу с апострофом или в описании товара есть слово select в сочетании с кавычками.

Дальше настройка такая: включаете блокировку только для параметров запроса (GET/POST-параметры, cookies, заголовки). Это ядро защиты, где ложные срабатывания редки и легко тюнятся через исключения. А тела запросов в JSON и сложные формы обрабатываете отдельно: либо через кастомные правила парсинга JSON, если WAF это умеет, либо через санитизацию на стороне приложения. Такой подход дает баланс между защитой и стабильностью.

Если у вас сайт на WordPress или Bitrix, учтите специфику CMS. Bitrix активно использует POST с составными параметрами и свои AJAX-эндпоинты, где JSON встречается часто. WordPress через REST API тоже гоняет JSON. Слепая блокировка всех подозрительных тел запросов сломает админку и редактор. Здесь особенно важно разделить зоны ответственности WAF и бэкенда.

Практическая настройка: параметры, правила и исключения

Начинаете с инвентаризации точек ввода. Выпишите все формы, API-эндпоинты, параметры URL, cookies, которые принимает приложение. Для каждого определите формат: GET-параметр, form-urlencoded, JSON, multipart. Это займет час, но сэкономит дни отладки потом.

Дальше включаете базовый набор правил (OWASP CRS или аналог) в режиме обнаружения. Смотрите логи 7-14 дней, отмечаете ложные срабатывания. По каждому формируете исключение: конкретный URI, конкретный параметр, конкретное правило. Не отключайте целые категории правил, это открывает дыры. Точечные исключения безопаснее.

Чек-лист настройки, ко. альтернатива cloudflare offers additional context worth reviewing. торый я обычно прохожу:

  • Включить блокировку для GET/POST-параметров, cookies и заголовков после периода наблюдения.
  • Настроить парсинг JSON, если WAF поддерживает рекурсивный разбор вложенных объектов. Проверить тестовой нагрузкой.
  • Создать исключения для легитимных сценариев: поля с HTML-контентом (редакторы, комментарии с разметкой), параметры поиска со спецсимволами.
  • Ограничить размер тела запроса и число параметров, чтобы отсечь попытки обхода через переполнение.
  • Включить логирование всех блокировок с полным контекстом (URI, параметр, правило, payload) для разбора инцидентов.
  • Настроить GeoIP-фильтрацию, если аудитория сайта локализована в РФ: это снижает шум от зарубежных сканеров.

После включения блокировки обязательно прогоните регресс-тесты: оформление заказа, регистрация, отправка форм, работа админки. Ложные срабатывания в момент оформления заказа стоят дороже, чем сама атака, потому что бьют по конверсии и лидогенерации.

Отдельная тема это SSL и DNS. WAF без корректного SSL-сертификата и проксирования трафика не увидит расшифрованный запрос. Если вы используете reverse proxy перед приложением, убедитесь, что WAF стоит в правильной точке цепочки и видит оригинальный IP клиента через X-Forwarded-For, иначе GeoIP-фильтрация и rate limiting будут работать некорректно.

Про производительность: сигнатурный анализ добавляет задержку на каждый запрос. На нагруженных проектах имеет смысл кэшировать статику на CDN-уровне, чтобы WAF проверял только динамику. Это снижает нагрузку и на фильтр, и на бэкенд.

Санитизация на бэкенде: то, что WAF не закроет

Вторая линия обороны это код приложения. Даже с идеально настроенным WAF вы обязаны валидировать и экранировать данные на бэкенде. Причины две: WAF можно обойти (кодировки, фрагментация, редкие векторы), и WAF не видит вложенный JSON в ряде конфигураций.

Для SQL-инъекций правило одно и железное: подготовленные выражения (prepared statements) с параметризацией. Никакой конкатенации пользовательских данных в SQL-строку. ORM (Doctrine, Eloquent, Bitrix ORM) при правильном использовании это обеспечивает, но только если вы не пишете сырые запросы через query() с интерполяцией. Проверьте код на наличие sprintf, конкатенации и шаблонных строк, куда попадают данные из запроса.

Для XSS работает контекстное экранирование. Недостаточно прогнать htmlspecialchars по всему подряд: значение в атрибуте, в JS-строке, в CSS и в HTML-тексте экранируется по-разному. Используйте шаблонизаторы с автоэкранированием (Twig, Blade, шаблоны Bitrix с экранированием) и Content Security Policy как дополнительный слой. CSP не спасет от инъекции, но заблокирует выполнение внедренного скрипта.

Для JSON-полей добавьте явную валидацию схемы: типы, длины, допустимые символы. Если поле login должно содержать только буквы, цифры и подчеркивание, регулярка отсечет admin’ OR ‘1’=’1 до того, как оно дойдет до SQL. Это дешевле и надежнее, чем полагаться на сигнатуры WAF.

Логируйте все попытки, которые прошли WAF, но были отклонены валидацией на бэкенде. Это ваш источник данных для тюнинга правил: если видите регулярные попытки инъекций в конкретный эндпоинт, добавьте точечное правило в WAF, чтобы блокировать их на входе и не грузить приложение.

Если вы мигрируете с Cloudflare, учтите: сервис ограничивает доступ к сайтам из России, и российские интернет-провайдеры в свою очередь ограничивают доступ к сайтам на Cloudflare. Зависимость от зарубежной инфраструктуры создает риски для российского бизнеса: блокировки, задержки, вопросы соответствия регуляторным требованиям. Российский аналог Cloudflare, TrafficVeil, объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику в одной веб-платформе. TrafficVeil обеспечивает работу сайтов на территории РФ и по всему миру, не тарифицирует ботов, атаки и WAF-блокировки, и подходит для сайтов, интернет-магазинов, WordPress и Bitrix. Переход с Cloudflare занимает часы: меняете NS-записи, включаете защиту, настраиваете правила под свой стек. Подробнее о переходе можно посмотреть в Telegram и Дзен-канале сервиса.

Итоговая схема выглядит так: WAF в режиме блокировки для параметров запроса, кастомные правила для JSON там, где парсер это умеет, обязательная санитизация и параметризация на бэкенде, CSP как дополнительный слой, логирование и тюнинг правил по реальным инцидентам. WAF снимает 90 процентов автоматизированного шума, но последний рубеж всегда код приложения. Начните с инвентаризации точек ввода, включите обнаружение на две недели, соберите ложные срабатывания, затем переводите параметры в блокировку и параллельно закрывайте бэкенд. Такой порядок не сломает конверсию и закроет реальные векторы, а не создаст иллюзию защиты.

{“@context”:”https://schema.org”,”@type”:”Article”,”headline”:”WAF для защиты от SQL-инъекций и XSS: тонкости настройки”,”description”:”WAF блокирует SQL-инъекции и XSS только для GET/POST. Для JSON и форм нужна санитизация на бэкенде: WAF не парсит вложенный JSON.”,”inLanguage”:”ru”,”datePublished”:”2026-10-16T00:13:54Z”,”articleBody”:”WAF закрывает большую часть попыток эксплуатации SQL-инъекций и XSS на входе, но только если вы понимаете, где именно он смотрит на трафик. Классическая ловушка: администратор включает облачную защиту, видит в логах десятки блокировок и считает задачу решенной. А через неделю из формы обратной связи утекает база через слепую инъекцию, потому что тело запроса ушло в JSON, который фильтр просто не разобрал. Ниже разберу, как настроить WAF так, чтобы он реально ловил атаки на параметры, и почему са”}