Работа с XML правилами

Используйте XML-условие, когда нужно проверить конкретное значение внутри XML-тела запроса: узел, атрибут, элемент списка или значение по XPath.

Если данные находятся внутри XML-документа, выберите Содержание запроса → XML. Для обычного текста, форм и multipart-запросов используйте другие типы условий.

Таблица 1. Когда выбирать XML-условие

Сценарий	Что выбрать
Нужно проверить значение внутри XML-документа	Содержание запроса → XML
Нужно проверить обычный текст без XML-структуры	Содержание запроса → Тело запроса
Нужно проверить форму application/x-www-form-urlencoded	Содержание запроса → Поле формы
Нужно проверить файл или часть multipart-запроса	Содержание запроса → Multipart

XML-условие применяется только к запросам с XML Content-Type. Перед настройкой проверьте заголовок Content-Type, чтобы правило срабатывало на нужные запросы.

Таблица 2. Content-Type для XML-условий

Заголовок Content-Type	Подходит для XML-условия
text/xml	Да
application/xml	Да
application/soap+xml	Да
application/*+xml	Да, например application/vnd.company.order+xml
application/json	Нет
multipart/form-data	Нет. Используйте Multipart
application/x-www-form-urlencoded	Нет. Используйте Поле формы

 

Где и как добавить XML-условие

XML-условие добавляется при создании или редактировании правила WAF.

В блоке условий выберите Область проверки → Содержание запроса, затем в поле Тип тела выберите XML.

После выбора типа тела появятся поля для настройки XML-проверки: XPath, Оператор и поле значения.

Действия правила для XML-условия

Для XML-условий доступны те же действия, что и для других условий. Выбирайте действие в зависимости от задачи: заблокировать запрос, разрешить легитимный сценарий или отключить отдельные WAF ID.

Таблица 3. Действия правила для XML-условия

Действие	Когда использовать	Что важно учесть
Запретить	Нужно заблокировать XML-запрос по значению узла или атрибута.	Указывайте точный XPath, чтобы правило не срабатывало на лишние XML-запросы.
Разрешить	Нужно убрать ложное срабатывание для легитимного XML-запроса.	Добавляйте узкие условия: приложение, URL, метод, источник запроса и точный XPath.
Отключить правила по ID	В событии атаки указаны конкретные WAF ID, которые ошибочно сработали на XML-запрос.	Этот вариант обычно безопаснее широкого разрешающего правила, потому что остальные проверки WAF продолжают работать.

Если один и тот же XML-запрос подходит и под правило Разрешить, и под правило Запретить, приоритет имеет Разрешить. Поэтому разрешающие правила должны быть максимально точными.

Важно: если приложение работает в режиме Мониторинг, правило фиксирует срабатывания, но не блокирует запросы. Для блокировки нужен режим Активная защита.

 

XPath

XPath указывает, где именно в XML-документе находится значение для проверки. XPath должен быть абсолютным и начинаться с /.

Примеры корректных XPath приведены в таблице 4.

Таблица 4. Примеры XPath

Что нужно проверить	XPath	Пример значения
Значение узла	/Envelope/Body/Login/User	admin
Вложенный узел заказа	/order/customer/id	100500
Узлы списка	/order/items/item/name	Phone
Первый элемент списка	/order/items/item[1]/name	Phone
Элемент с атрибутом	/order/items/item[@type="digital"]/name	License
Значение атрибута	/Envelope/Header/@token	abc123
SOAP action внутри тела	/Envelope/Body/CreateOrder/action	create
SOAP с префиксами	/soap:Envelope/soap:Body/CreateOrder/action	create
Любой узел на одном уровне	/Envelope/Body/*/User	admin

Как выбрать XPath по XML-телу

Перед настройкой правила возьмите пример реального XML-запроса и определите путь к нужному значению. Путь строится от корневого элемента к нужному узлу или атрибуту.

Примеры выбора XPath приведены в таблице 5.

Таблица 5. Как выбрать XPath по XML-телу

XML-фрагмент	Что проверить	XPath
<order><customer><id>100500</id></customer></order>	ID клиента	/order/customer/id
<order id="42"><status>paid</status></order>	Атрибут заказа	/order/@id
<item type="digital"><name>License</name></item>	Имя цифрового товара	/item[@type="digital"]/name
<items><item><name>Phone</name></item><item><name>Case</name></item></items>	Любой товар с именем Phone	/items/item/name
<items><item><name>Phone</name></item><item><name>Case</name></item></items>	Только первый товар	/items/item[1]/name
<soap:Envelope><soap:Body><CreateOrder><action>create</action></CreateOrder></soap:Body></soap:Envelope>	SOAP action	/soap:Envelope/soap:Body/CreateOrder/action

Примечание: если в XML используются префиксы, указывайте такие же префиксы в XPath. Например, для SOAP-запроса с префиксом soap: путь должен содержать этот префикс.

 

Некорректные XPath-варианты

Для XML-условий используйте простые абсолютные пути. Не используйте слишком широкие или сложные XPath: такие условия сложнее контролировать, и они могут сработать не на тех запросах.

Таблица 6. Некорректные XPath-варианты

Не используйте	Почему	Как заменить
//User	Такой путь ищет User по всему XML-документу и может сработать слишком широко.	/Envelope/Body/Login/User
contains(/order/name, "test")	Функции в XPath не поддерживаются.	XPath /order/name + оператор Содержит + значение test
/Envelope/Body/descendant::User	Оси XPath не поддерживаются.	/Envelope/Body/Login/User
order/customer/id	XPath должен начинаться с /.	/order/customer/id
/Envelope/Body/*/*/*/*/User	В пути слишком много wildcard-сегментов *.	Укажите точный путь к нужному узлу.
/item[@type="очень длинное значение ..."]/name	Значение внутри предиката атрибута слишком длинное.	Проверяйте значение через оператор и поле значения правила.

Операторы для XML-условий

Оператор определяет, как правило будет сравнивать найденное XML-значение. Выберите оператор в зависимости от того, нужно ли полное совпадение, поиск фрагмента, проверка по регулярному выражению или проверка наличия узла.

Таблица 7. Операторы XML-условий

Оператор	Когда использовать	Пример
=	Значение должно совпасть полностью.	XPath /order/status, значение blocked
≠	Значение не должно совпадать.	XPath /order/status, значение paid
Содержит	Нужно найти фрагмент внутри значения.	XPath /comment/text, значение <script
Не содержит	Нужно проверить, что в значении нет указанного фрагмента.	XPath /order/source, значение test
Регулярное выражение	Нужно проверить значение по шаблону.	XPath /user/email, значение @example\\.com$
Существует	Нужно проверить наличие узла или атрибута.	XPath /Envelope/Header/@token
Не существует	Нужно проверить отсутствие узла или атрибута.	XPath /debug

Примечание: для операторов Существует и Не существует поле значения не заполняется.

Учет регистра

Переключатель Учитывать регистр влияет только на сравниваемое значение. Он не изменяет XPath и не влияет на имена XML-узлов.

Таблица 8. Как работает учет регистра в XML

XPath	Значение в правиле	Значение в запросе	Если регистр учитывается
/user/role	Admin	Admin	Совпадет
/user/role	Admin	admin	Не совпадет
/User/Role	Admin	Admin	XPath останется /User/Role. Учет регистра значения не влияет на имя узла.

Ограничения XML-условий

Перед сохранением правила проверьте ограничения XML-условий. Это особенно важно для сложных XML-документов и длинных XPath.

Таблица 9. Ограничения XML-условий

Что ограничено	Ограничение
XPath	До 512 символов
Глубина XPath	До 32 сегментов
Предикаты в XPath	До 4 предикатов
Значение внутри предиката атрибута	До 128 символов
Wildcard-сегменты *	До 2 сегментов
Значение для сравнения	До 4096 символов
Регулярное выражение	До 1024 символов
Content-Type	XML-условие применяется только к XML-запросам из таблицы 2

Примечание: Для сложного XML лучше создать несколько точных правил, чем одно правило с широким XPath. Так правило проще проверить и сопровождать.

 

Примеры настройки

Пример 1. Запретить XML-запрос с пользователем admin

В этом примере правило блокирует XML-запрос, если в узле /Envelope/Body/Login/User указано значение admin.

Параметры правила:

• Название: DENY XML admin user.
• Действие: Запретить.
• Условия:
  • Приложения = нужное приложение.
  • Путь URL-адреса = /api/xml/login.
  • HTTP-метод = POST.
  • Область проверки = Содержание запроса.
  • Тип тела = XML.
  • XPath = /Envelope/Body/Login/User.
  • Оператор = =.
  • Значение = admin.
• Включено: да.

Пример 2. Запретить XML-заказ по атрибуту

В этом примере правило блокирует XML-заказ, если в запросе есть товар с атрибутом type="digital" и именем License.

Параметры правила:

• Название: DENY digital license order.
• Действие: Запретить.
• Условия:
  • Приложения = нужное приложение.
  • Путь URL-адреса = /api/orders/import.
  • HTTP-метод = POST.
  • Область проверки = Содержание запроса.
  • Тип тела = XML.
  • XPath = /order/items/item[@type="digital"]/name.
  • Оператор = =.
  • Значение = License.
• Включено: да.

Пример 3. Проверить наличие XML-атрибута

В этом примере правило проверяет, есть ли в XML атрибут token. Для оператора Существует значение не указывается.

Параметры правила:

• Название: DENY XML token header.
• Действие: Запретить.
• Условия:
  • Приложения = нужное приложение.
  • Область проверки = Содержание запроса.
  • Тип тела = XML.
  • XPath = /Envelope/Header/@token.
  • Оператор = Существует.
• Включено: да.

Пример 4. Отключить WAF ID для одного XML-сценария

Этот вариант подходит, если ложное срабатывание связано с конкретными WAF ID из события атаки. Правило отключит только указанные WAF ID и только для заданного XML-сценария.

Параметры правила:

• Название: Исключение WAF ID для XML import.
• Действие: Отключить правила по ID.
• ID правил для отключения: 150000123, 150000456.
• Условия:
  • Приложения = нужное приложение.
  • Путь URL-адреса = /api/orders/import.
  • HTTP-метод = POST.
  • Область проверки = Содержание запроса.
  • Тип тела = XML.
  • XPath = /order/source.
  • Оператор = =.
  • Значение = trusted-partner.
• Включено: да.

Пример 5. Разрешить легитимный XML-запрос

Используйте разрешающее правило только для ложных срабатываний. Добавляйте точные условия, чтобы правило не разрешало лишние запросы.

Параметры правила:

• Название: ALLOW trusted XML import.
• Действие: Разрешить.
• Условия:
  • Приложения = нужное приложение.
  • Путь URL-адреса = /api/orders/import.
  • HTTP-метод = POST.
  • IP-адрес источника → В группе IP-адресов = группа доверенного сервиса.
  • Область проверки = Содержание запроса.
  • Тип тела = XML.
  • XPath = /order/source.
  • Оператор = =.
  • Значение = trusted-partner.
• Включено: да.

Как проверить правило после создания

После сохранения проверьте правило по чек-листу из таблицы 10.

Таблица 10. Чек-лист проверки XML-правила

Что проверить	Ожидаемый результат
Приложение	Выбрано только нужное приложение
URL	Указан точный путь, если правило не должно быть глобальным
Метод	Указан нужный метод, обычно POST
Content-Type запроса	Соответствует XML-типу из таблицы 2
XPath	Начинается с / и не использует некорректные конструкции из таблицы 6
Оператор	Соответствует цели проверки
Значение	Заполнено только для операторов, которым требуется значение
Учет регистра	Настроен осознанно и применяется только к сравниваемому значению
Режим приложения	Для блокировки используется режим Активная защита, а не Мониторинг

 

Частые ошибки

• Слишком широкий XPath. Например, //User или путь с большим количеством *. Такое правило может сработать на запросы, для которых оно не предназначено. Используйте точный абсолютный путь.
• Широкое разрешающее правило. Если известны WAF ID из события атаки, чаще безопаснее выбрать Отключить правила по ID и добавить точные условия.
• Ожидание блокировки в режиме мониторинга. В режиме Мониторинг правило только фиксирует срабатывание. Для блокировки нужен режим Активная защита.
• Неверный Content-Type. Если запрос пришел не как XML, XML-условие не подойдет. Проверьте Content-Type по таблице 2.
• Значение указано для оператора «Существует». Для операторов Существует и Не существует поле значения должно быть пустым.
• Смешение регистра значения и XPath. Переключатель Учитывать регистр влияет на сравниваемое значение, но не меняет имя XML-узла в XPath.
• Слишком сложный XPath. Не используйте функции, оси и глубокие пути с wildcard. Укажите точный путь и выберите подходящий оператор.