Введение

В настоящих реалиях всё более сложная структура киберугроз. Корпоративные информационные системы нуждаются в многоуровневой защите, включающей не только стандартные средства сетевой защиты и межсетевые экраны (firewalls), но также специализированные механизмы, подстраиваемые под сценарии работы приложений.

Пользовательские правила (custom rules) в PT AF PRO — это инструкции, которые помогают выявлению, блокировке или иному: обработке подозрительных запросов, шаблонов трафика или аномальных действий, которые не охватываются предустановленными стандартными наборами сигнатур. Основная цель таких правил заключается в том, чтобы:

Вывести защищу за пределы стандартных WAF‑сигнатур (например, OWASP ModSecurity Core Rule Set), адаптировав её под бизнес‑логику и особенности конкретного приложения.
Влиять на специфические техники атаки, которые были выявлены в ходе предварительных тестов (этичного хакинга) или реального инцидента, но отсутствуют в универсальных сигнатурах.
Минимизировать ложноположительные срабатывания, поскольку правила могут быть точно настроены под уникальные параметры работы приложения, URL‑политики, методы входа данных и JSON/XML‑структуры.

Пользовательские правила PT AF PRO представляют один из важных элементов защиты современных веб‑приложений и сервисов. Они позволяют увеличить эффективность работы SOC‑аналитиков за счёт снижения ложноположительных срабатываний.

Защита от продвинутых SQLi атак

В современных веб‑приложениях атаки типа SQL‑инъекции (SQLi) считаются одним из распространённых и опасных векторов компрометации. Несмотря на свое долгое существование и развитие средств защиты, злоумышленники продолжают модернизировать методы обхода WAF‑правил и базовых фильтров.

Основная цель данного правила — обнаруживать и блокировать сложные шаблоны SQL‑инъекции, когда злоумышленник использует несколько этапов кодирования (URL‑кодирование, HTML‑энтити, Base64) для сокрытия вредоносной полезной нагрузки. Правило предназначено для защиты критически важных эндпоинтов («точек входа») веб‑приложения, где наибольший риск компрометации: /api/auth (аутентификация пользователей) и /payment (обработка финансовых транзакций).

Приступим к созданию правила, заполнив его карточку (см. Рисунок 1).

Рисунок 1 – Создание карточки правила «Блокировка SQL-инъекций с декодированным payload». — Рисунок 1 — Создание карточки правила «Блокировка SQL‑инъекций с декодированным payload».

В поле название мы указали «DetectAdvancedSQLi», в поле «Описание» детализировали название правило и его функционал.

Не забыли про Теги, Тип и Уровень опасности, которые будут отображаться при срабатывании правила на дашборде.

Обратимся к самому правилу. Наше правило, как и все последующие блокируется и записывается в базу данных. Разберем его код (см. Рисунок 2).

Рисунок 2 – Код правила «Блокировка SQL-инъекций с декодированным payload» — Рисунок 2 — Код правила «Блокировка SQL‑инъекций с декодированным payload»

Таблица 1 — Разбор правила PT AF Pro: SQL Injection Protection

Элемент кода	Тип	Подробное описание
with	Секция	Объявляет локальные переменные, используемые в правиле. Переменные вычисляются один раз при инициализации правила.
@sql_pattern = ~”...	Переменная + Регулярное выражение	Паттерн для поиска SQL‑инъекций: — (?i) — игнорирование регистра. — union[\\s\\+]+select — union + пробелы/+ + select. — drop\\s+table — drop + пробелы + table. — sleep\\(\\d+\\) — вызов sleep(N). — benchmark\\( — вызов benchmark. — 1\\s=\\s1 — 1=1 с любыми пробелами.
@sensitive_endpoints = [...]	Переменная + Список	Критические эндпоинты приложения: — [«/api/auth», «/payment»] — пути, где проверяются инъекции.
if	Секция	Основное условие срабатывания правила. Логика: «если путь критический И (есть SQLi в GET‑параметрах ИЛИ в POST‑параметрах)».
REQUEST_PATH in @sensitive_endpoints	Условие + Оператор in	Проверяет, что путь запроса содержится в списке @sensitive_endpoints: — Пример: /api/auth → true, /home → false.
REQUEST_GET.extract(values)	Функция extract	Извлекает значения GET‑параметров: — Вход: [(«param1»,»val1»), («param2»,»val2»)] — Выход: [«val1», «val2»] (ранк 1).
map(url_decode, html_entity_decode)	Функция map	Цепочка декодирования для каждого значения: 1. url_decode: преобразует%20 → пробел. 2. html_entity_decode: преобразует & → &.
any()	Функция any	Проверяет, что хотя бы один элемент списка соответствует условию.
matches @sql_pattern	Оператор matches	Сравнивает элемент с регулярным выражением @sql_pattern.
REQUEST_POST.extract(values)	Функция extract	Извлекает значения POST‑параметров. Аналогично REQUEST_GET.
map(base64_decode, url_decode)	Функция map	Цепочка декодирования для POST: 1. base64_decode: декодирует Base64 → бинарные данные. 2. url_decode: декодирует URL‑кодирование.
or	Логический оператор	Объединяет условия: срабатывает при SQLi в GET или POST.

В рамках пентеста веб‑приложения мы выполнили SQL‑инъекцию, направленную на API‑эндпоинт авторизации. Трафик был зафиксирован и проанализирован с помощью Burp Suite. Firewall PT AF PRO сработал на пользовательское правило «Advanced SQLi Detection», адаптированное под нетипичные и закодированные векторы инъекций. (см. Рисунок 3).

Рисунок 3 – Срабатывание правила «Защита от продвинутых SQLi атак» — Рисунок 3 — Срабатывание правила «Защита от продвинутых SQLi атак»

Парсинг:

REQUEST_PATH = "/api/auth" → true для in @sensitive_endpoints.
REQUEST_POST = [("data", "YWRtaW4lMjcnJSUyME9SJTIwMSUzRDElM0MlM0Qx")].

Обработка:

extract(values) → ["YWRtaW4lMjcnJSUyME9SJTIwMSUzRDElM0MlM0Qx"].
map(base64_decode) → ["admin%27%25%20OR%201%3D1%3C%3D1"].
map(url_decode) → ["admin'% OR 1=1<=1"].
any() matches @sql_pattern) → true (совпадение с 1\\s*=\\s*1).

Результат: Срабатывание правила → блокировка.

Защита от цепочечных XSS-атак

Цепочечные (chained) XSS‑атаки подразумевают неоднократное вредоносных отрывков кода (например, <iframe>, javascript:// или event‑позиционеров наподобие onmouseover=) в различную цепочку запросов и ответов. Злоумышленники могут скрыть основной payload в громоздких запросах, обойти традиционные фильтры WAF и доставить скрипт исключительно целевым клиентам, используя специфические клиентские характеристики. Обычные сигнатурные фильтры часто не выявляют такие сложные комбинации, поэтому требуется продвинутый механизм на уровне прикладного firewall.

Карточка правила (см. Рисунок 4).

Рисунок 4 – Создание карточки правила «Защита от цепочечных XSS-атак». — Рисунок 4 — Создание карточки правила «Защита от цепочечных XSS‑атак».

Код правила (см. Рисунок 5).

Рисунок 5 – Пользовательское правило «Защита от цепочечных XSS-атак». — Рисунок 5 — Пользовательское правило «Защита от цепочечных XSS‑атак».

Талица 2 — Разбор правила PT AF Pro «Защита от цепочечных XSS‑атак»

Элемент	Тип данных	Описание	Профессиональное назначение
with	Блок объявления	Определение переменных для повторного использования в условиях	Улучшает читаемость и управление сложными паттернами
@xss_vectors	Регулярное выражение	~”<iframe\\s\|javascript:\\/\\/\|onmouseover=)”	Паттерн для детектирования XSS‑векторов: <iframe, javascript://, onmouseover=
@size_threshold	Целое число без знака	10 000 (10 КБ)	Порог размера тела запроса для фильтрации крупных данных
REQUEST_BODY.length()	Функция + целое число	Возвращает длину тела запроса в байтах	Выявление атак, скрытых в больших payload (обход сканеров)
> @size_threshold	Реляционный оператор	Сравнение длины тела запроса с порогом	Фильтрация объемных запросов, характерных для сложных XSS
REQUEST_HEADERS.select(“Referer”)	Функция + строка	Выбор заголовка Referer из всех headers	Точечный анализ контекста источника запроса
extract(values)	Функция	Извлечение значений заголовка (не ключей)	Фокусировка на содержимом Referer, игнорируя метаданные
any()	Функция‑агрегатор	Проверка хотя бы одного элемента на соответствие условию	Эффективное сканирование без полного перебора
matches @xss_vectors	Оператор + regex	Сопоставление значения Referer с XSS‑паттернами	Детектирование инъекций в источнике перехода
CLIENT_OS_NAME	Строка	Название ОС клиента (Android)	Контекстная привязка к мобильным уязвимостям
CLIENT_BROWSER_VERSION	Строка	Версия браузера (< «120.0»)	Целевая защита уязвимых версий (Chromium < 120)
and	Логический оператор	Комбинирование условий

Во время тестирования уязвимости хранения пользовательского ввода в базе данных (Stored XSS), была отправлена цепочечная XSS‑атака. PT AF PRO активировал пользовательское правило, ориентированное на XSS‑атаки, включающие обход фильтров и delayed execution через DOM, base64 и обфускацию (см. Рисунок 6).

Рисунок 6 – Заголовки при цепочке XSS-атаки. — Рисунок 6 — Заголовки при цепочке XSS‑атаки.

Разбор цепочки атаки:

1. Первый вектор: XSS через Referer

Содержимое:

javascript://eval(String.fromCharCode(97,108,...))
Декодировано:
javascript://alert(document.cookie)
Обфускация:
ASCII‑коды скрывают alert(document.cookie)
Механизм:
Если сервер отражает Referer в ответе, код выполнится при рендеринге страницы.

2. Второй вектор: XSS в теле запроса

Часть 1: Мусорные данные

<section id=»temp»>AAAAAAAAAAAAAA...[15,000+ байт]...</section>

Назначение: превысить порог @size_threshold = 10 000
Скрывает основной payload от поверхностного сканирования

Часть 2: Основной XSS‑вектор

Расшифровка:

iframe загружает base64-код:

<scipt>alert('Session: '+document.cookie)</script>

· При загрузке (onload):

2. Заменяет элемент #temp на:

<img src=x>

3) onerror срабатывает (из‑за невалидного src=x), отправляя куки на сервер злоумышленника.

Как определили, что цепочечная атака:

Таблица 3 — Поэтапный разбор цепочечной XSS‑атаки

Механизм обхода / Действие	Ключевые особенности / Компоненты
Эшелон 1 Обход WAF через размер
Отправка запроса большого объема	15 025 байт: Объем, отключающий глубокий анализ в некоторых WAF.
Маскировка вредоносных векторов	Мусорные данные: Заполняют объем и скрывают вредоносную нагрузку.
Эшелон 2 Разделение payload (полезной нагрузки)
Простой тест уязвимости в заголовке	Referer: Содержит простой алерт (например, alert(1)) для проверки наличия уязвимости.
Простой тест уязвимости в заголовке	Тело запроса: Содержит сложную, многоступенчатую вредоносную нагрузку.
Основная эксплойтация в теле запроса	Base64 кодирование: Используется для обхода сигнатур WAF.
Основная эксплойтация в теле запроса	Цепочка выполнения: iframe → событие onload → манипуляция outerHTML → img с событием onerror → exfil (вывод данных).
Эшелон 3 Клиент‑специфичная доставка
Доставка эксплойта только целевым устройствам	Целевая платформа: Android.
Целевой браузер: Chrome версии ниже 120.
Использование специфичных уязвимостей рендеринга	Уязвимости: Используются известные уязвимости рендеринга в указанных версиях.
Эксплуатация особенностей обработки URI	data: URI: Используются особенности обработки схемы data: URI в мобильных браузерах.

Обнаружение скрытых сканеров через HTTP/2

В современных сценариях атак на веб‑приложения злоумышленники используют скрытые сканеры, способные маскировать свои запросы под легитимный трафик. Особенно, такие коммерческие сканеры как Acunetix, Netsparker, которые поддерживают протокол HTTP/2 и настраивают нестандартные порты (например, 8443 или 4430) для обхода традиционных межсетевых экранов. Приведённое ниже правило демонстрирует, как Positive Technologies Application Firewall PRO (PT AF PRO) способен выявлять такие продвинутые попытки разведки уязвимостей.

Карточка правила (см. Рисунок 7).

Рисунок 7 – Создание карточки правила для «Обнаружение скрытых сканеров через HTTP/2» — Рисунок 7 — Создание карточки правила для «Обнаружение скрытых сканеров через HTTP/2»

Код правила (см. Рисунок 8).

Рисунок 8 – Код пользовательского правила «Обнаружение скрытых сканеров через HTTP/2» — Рисунок 8 — Код пользовательского правила «Обнаружение скрытых сканеров через HTTP/2»

Таблица 4 — Объяснение синтаксиса пользовательского правила «Обнаружение скрытых сканеров через HTTP/2»

Компонент	Синтаксическая роль	Логическая функция	Профессиональный комментарий
with	Объявление переменных	Инициализация параметров	Оптимизирует производительность: вычисляется 1 раз при загрузке правила
@scanner_fingerprints = ~”(Acunetix\|Nessus\|Netsparker)”	Переменная с регулярным выражением	Паттерн названий сканеров	(?i) отсутствует → регистрозависимый поиск.
@http2_ports = [8443, 4430]	Список портов	Фильтр нестандартных HTTPS‑портов	8443/4430 — популярные порты для обхода корпоративных фаерволов
@custom_header = [“x‑scan‑signature”, “x‑probe‑id”]	Список строк	Детектирование фирменных заголовков сканеров	Acunetix использует x‑scan‑signature, Netsparker — x‑probe‑id
if (REQUEST_HTTP_VERSION == “HTTP/2”)	Проверка версии протокола	Фильтрация HTTP/2 трафика	85% сканеров используют HTTP/2 для снижения заметности
and	Комбинация условий	Обязательное требование	Группирует условия «версия протокола И (сигнатура1 ИЛИ сигнатура2)»
(CLIENT_BROWSER_NAME == “Other”	Детектирование неизвестных UA	Выявление сканеров	PT AF помечает неизвестные UA как «Other» (например, Acunetix)
REQUEST_SIZE between 5000 and 10 000	Проверка размера запроса	Обнаружение fuzzing‑атак	Типичный размер запросов при сканировании уязвимостей
or	Альтернативное условие	Расширение детекции	Ловит сканеры даже без аномального размера запроса
REQUEST_HEADERS.extract(keys)	Извлечение ключей заголовков	Преобразование заголовков → список	Конвертирует [(«header1»,»val1»),...] → [«header1»,...]
contains @custom_header	Проверка вхождения	Поиск специфичных заголовков	Срабатывает при наличии ЛЮБОГО заголовка из списка

Многие современные автоматизированные сканеры (например, Acunetix, Netsparker, Burp Scanner) перешли на использование HTTP/2 не ради производительности, а с тактической целью:

Обход детекторов, ориентированных на HTTP/1.1
Асинхронные запросы с «молчащим» multiplexing'ом
Использование нестандартных портов (например, 8443, 4430) в попытке уйти от контроля традиционного HTTPS (порт 443)

Пользовательское правило PT AF PRO предназначено для ловли таких маскирующихся активностей, при этом оно ориентировано не только на протокол, но и на сигнатуры поведения сканеров (см. Рисунок 9).

Рисунок 9 – Перехваченный запроса с помощью BurpSuite. — Рисунок 9 — Перехваченный запроса с помощью BurpSuite.

AdvancedBrutforceProtection

В современном веб‑пространстве попытки перебора учётных данных (Brute‑Force) по‑прежнему остаются одним из наиболее распространённых способов несанкционированного доступа. Несмотря на внедрение сложных механизмов двухфакторной аутентификации и рейт‑лимитирование, злоумышленники развивают методы обхода классических защит. Представленное ниже правило в PT AF PRO объединяет геоконтекстную аналитику с проверкой энтропии (длины) пароля и регулярными выражениями для точного определения эндпоинтов входа, что позволяет дойти до более высокого уровня безопасности.

Карточка правила (см. Рисунок 10).

Рисунок 10 – Создание карточки правила «Защита от продвинутых BrutForce-аттак». — Рисунок 10 — Создание карточки правила «Защита от продвинутых BrutForce‑аттак».

Код правила (см. Рисунок 11).

Рисунок 11 – Код пользовательского правила. — Рисунок 11 — Код пользовательского правила.

Таблица 5 — Объяснение синтаксиса пользовательского правила по защите от продвинутых BrutForce‑аттак.

Компонент	Синтаксис	Тип данных	Описание
Секция with	Объявление локальных переменных
@geo_risk_zones	= [“IR”, “KP”, “CN”]	Список строк	Список кодов рискованных стран (ISO 3166–1 alpha-2)
@login_pattern	= ~”^/(?:auth\|login)(/.*)?$”	Регулярное выражение	Паттерн для путей авторизации: — ^/(?:auth\|login) — начало пути с /auth или /login — (/.*)?$ — опциональный слэш и любые символы после
Секция if Базовые условия	Условия срабатывания правила
REQUEST_PATH	Контекстная переменная	Строка	Путь URI запроса (напр. /auth/login)
matches	Оператор	→ Булево	Проверка соответствия регулярному выражению
@login_pattern	Локальная переменная	Регулярное выражение	Сравнение пути с паттерном авторизации
RESPONSE_STATUS_CODE	Контекстная переменная	Целое число	HTTP‑статус ответа
==	Оператор (eg)	→ Булево	Проверка равенства значения (401 — Unauthorized)
Составное условие (OR)	Триггеры атаки
CLIENT_COUNTRY	Контекстная переменная	Строка	Код страны клиента (напр. «IR»)
in	Оператор	→ Булево	Проверка вхождения в список @geo_risk_zones
Цепочка методов (POST)	Обработка параметров формы
REQUEST_POST	Контекстная переменная	Вектор пар	POST‑параметры запроса (ключ‑значение)
select(“password”)	Метод	→ Вектор	Фильтрация параметров по ключу password
extract(values)	Метод	→ Вектор строк	Извлечение значений параметров (напр. [«12 345», «qwerty»])
map(length)	Метод + функция	→ Вектор целых чисел	Применение функции length() к каждому значению (длины паролей)
all()	Агрегатор	→ Булево	Проверка условия для всех элементов вектора
between 1 and 10	Оператор диапазона	→ Булево	Проверка, что все длины паролей ∈ [1; 10] (короткие пароли — индикатор брутфорса)

Ниже приведен пример сценария перехваченного HTTP‑запроса и ответа от сервера, описывающие работу пользовательского правила AdvancedBruteforceProtection в PT AF PRO. При этом обращается внимание на то, как сочетание HTTP‑маршрута /auth/login, проверки кода ответа 401 Unauthorized и ступепнчатой верификации параметров (геолокация клиента и длина поля password) позволяют блокировать попытки автоматизированного перебора учётных данных (см. Рисунок 12).

Рисунок 12 – Пример сценария перехваченного HTTP-запроса и ответа от сервера. — Рисунок 12 — Пример сценария перехваченного HTTP‑запроса и ответа от сервера.

Защита от целенаправленных атак на API

В современных архитектурах микросервисов и API‑driven приложений целенаправленные атаки на API‑эндпоинты являются одной из наиболее серьёзных угроз. Злоумышленники прибегают к продвинутым техникам обхода, комбинируя попытки несанкционированного доступа с анализом сетевых рисков, чтобы оставаться в тени.

Карточка правила (см. Рисунок 13)

Рисунок 13 – Создание карточки правила «Защита от целенаправленных атак на API». — Рисунок 13 — Создание карточки правила «Защита от целенаправленных атак на API».

Талица 7 — Разбор синтаксиса пользовательского правила «Защита от целенаправленных атак на API»

Компонент	Синтаксис/Пример	Тип данных	Описание
Объявление правила	rule APIProtection:	-	Название правила (APIProtection)
Секция with	Инициализация локальных переменных
@jwt_pattern	~”^eyJ[A‑Za‑z0–9_‑]+\.eyJ[A‑Za‑z0–9_‑]+\.[A‑Za‑z0–9_‑]+$”	Регулярное выражение	Паттерн для валидации JWT‑токенов (начинается с eyJ, содержит три части, разделенные точками)
@suspicious_ips	@@global_blacklist	Глобальный список	Ссылка на внешний параметр правила (список IP)
Секция if Базовое условие	Условия срабатывания
REQUEST_PATH	Контекстная переменная	Строка	Путь запроса
matches	Оператор	→ Булево	Проверка соответствия регулярному выражению
~”^/v[1–3]/”	Регулярное выражение	-	Путь должен начинаться с /v1/, /v2/ или /v3/ (версионированное API)
Составное условие (OR)	Триггеры атаки
Подусловие 1	not REQUEST_HEADERS.select(...)	→ Булево	Отсутствие валидного JWT
REQUEST_HEADERS	Контекстная переменная	Вектор пар	Заголовки запроса
select(“Authorization”)	Метод	→ Вектор	Фильтрация заголовков по ключу Authorization
extract(values)	Метод	→ Вектор строк	Извлечение значений заголовков
any(matches(@jwt_pattern))	Агрегатор + оператор	→ Булево	Проверяет, что хотя бы одно значение соответствует @jwt_pattern
not	Логическое отрицание	→ Булево	Инвертирует результат (срабатывает при отсутствии валидного JWT)
Подусловие 2	(CLIENT_IP in... and CLIENT_PROTO ==...)	→ Булево	Рискованное соединение
CLIENT_IP	Контекстная переменная	IP‑адрес	IP‑адрес клиента
in @suspicious_ips	Оператор	→ Булево	Проверка вхождения IP в черный список
CLIENT_PROTO	Контекстная переменная	Строка	Протокол соединения (HTTP/HTTPS)
== “HTTP”	Оператор (eg)	→ Булево	Проверка использования незащищенного протокола

Правило эффективно блокирует как попытки брутфорса, так и целевые атаки на уязвимые точки API, сочетая анализ учетных данных и сетевых параметров (см. Таблица 8).

Ключевые механизмы защиты

1. Валидация JWT:

o Проверка формата токена через регулярное выражение.

o Требование наличия токена для доступа к API.

2. Контроль доступа по IP:

o Использование динамического черного списка (@@global_blacklist).

3. Принудительное шифрование:

o Блокировка запросов с подозрительных IP при использовании HTTP.

4. Фокусировка на API:

o Целевой мониторинг версионированных путей (/v[1–3]/).

Сценарии срабатывания

Таблица 8 — Пример сценария срабатывания правила.

Атака	Пример запроса	Почему сработает
Попытка доступа без токена	`GET /v2/users` без `Authorization`	Условие 1: `not ... any(matches(@jwt_pattern))`
Взломщик из черного списка	`HTTP`‑запрос с IP `5.188.210.10`	Условие 2: `CLIENT_IP in @suspicious_ips and CLIENT_PROTO == "HTTP"`
Перехват данных через HTTP	`POST /v1/auth` с токеном по `HTTP`	Сработает, если IP в черном списке (даже с валидным токеном!)

Ниже приведён пример перехваченного через Burp Suite POST‑запроса и ответа, показывающего срабатывание правила «Защита от целенаправленных атак на API» в PT AF PRO. Подобная сочетание сигнатурного (регулярные выражения для JWT) и поведенческого (IP‑фильтрация, проверка протокола, таргетинг на версии API) анализа обеспечивает надежную защиту критичных эндпоинтов от сложных, целенаправленных атак (см. Рисунок 14).

Рисунок 14 — Пример сценария перехваченного HTTP‑запроса и ответа от сервера.

Детектирование цепочек эксплойтов через файлы

Современные злоумышленники обладают знаниями в области разработки эксплойтов часто пытаются внедрить вредоносный код не одним, а несколькими этапами, чтобы пройти стандартные СЗИ. Если говорить о веб‑приложених эти этапы обычно проводят злоумышленника через следующие шаги:

1. Этап 1 — доставка эксплойта (обход базовой валидации файлов),

2. Этап 2 — активация эксплойта (внедрение серверного кода или скриптов для удалённого выполнения команд),

3. Этап 3 — эскалация привилегий и дальнейшее распространение (например, установка бекдора).

Карточка правила (см. Рисунок 15).

Рисунок 15 – Создание карточки правила «Детектирование цепочек эксплойтов через файлы» — Рисунок 15 — Создание карточки правила «Детектирование цепочек эксплойтов через файлы»

Разбор правила «Детектирование цепочек эксплойтов через файлы» (см. Таблица 9)

Таблица 9 — Разбор синтаксиса правила «Детектирование цепочек эксплойтов через файлы».

Компонент	Синтаксис	Описание
Локальные переменные
@php_pattern	~”\.php$”	Соответствует именам файлов с расширением.php
@asp_pattern	~”\.asp$”	Соответствует именам файлов с расширением.asp
@php_code	~”<\?php\s+system\(\\$_GET\\['cmd'\\]”	Ищет вредоносный PHP‑код: <?php system($_GET['cmd']
@asp_code	~”<%@\s+Language=VBScript”	Ищет директиву ASP: <%@ Language=VBScript
@malicious_combinations_*	[“.php”, “<?php system(...);?>”]	Не используются в условии (резерв для будущих версий)
Условие срабатывания
REQUEST_FILES	Контекстная переменная	Информация о загруженных файлах: (ключ, значение, имя_файла)
extract(filenames)	Метод	Извлекает имена файлов (3-й элемент кортежа)
extract(values)	Метод	Извлекает содержимое файлов (2-й элемент кортежа)
any()	Агрегатор	Проверяет хотя бы один элемент в векторе
matches	Оператор	Проверка соответствия регулярному выражению
Логические блоки	(A and B) or (C and D)	Комбинация для двух типов атак (PHP/ASP)

Во время тестирования веб‑приложения был перехвачен HTTP‑запрос, который триггерил пользовательское правило Web Application Firewall — PT Application Firewall PRO. Для анализа поведения правила мы использовали Burp Suite как MITM‑прокси (man‑in‑the‑middle), что позволило рассмотреть трафик в момент срабатывания WAF (см. Рисунок 16).

Рисунок 16 – Триггер правила «Детектирование цепочек эксплойтов» на PT AF PRO. — Рисунок 16 — Триггер правила «Детектирование цепочек эксплойтов» на PT AF PRO.

Заключение

Пользовательские правила PT AF PRO представляют собой критический элемент защиты современных веб‑приложений и сервисов. Они позволяют увеличить эффективность работы SOC‑аналитиков (и не только для blue team) за счёт снижения ложноположительных срабатываний. При правильном внедрении и регулярном обновлении подобных правил можно существенно повысить защищённость веб‑приложений, предотвращая утечки конфиденциальных данных и сохраняя целостность критических бизнес‑процессов.

WAF (гав-гав): гибкая настройка пользовательских правил PT AF PRO