Эволюция методов обхода межсетевых экранов веб-приложений

Межсетевые экраны веб-приложений (Web Application Firewall, WAF) — фундаментальный компонент обеспечения безопасности современных информационных систем, функционирующий на уровне приложений модели OSI. Исторически WAF развивались как средства сигнатурного анализа и фильтрации трафика, призванные блокировать наиболее распространённые угрозы, такие как SQL-инъекции, межсайтовый скриптинг (XSS) и локальное подключение файлов (LFI). Но усложнение архитектуры современных веб-приложений, повсеместное внедрение API-интерфейсов выявили системные ограничения традиционных подходов к инспекции трафика.

Олег Лебедев, эксперт по кибербезопасности Angara Security, провел глубокий технический анализ векторов уклонения, архитектурных уязвимостей и стратегий противодействия межсетевым экранам веб-приложений.

Современные векторы обхода WAF сместились от тривиальной обфускации вредоносных строк в сторону эксплуатации архитектурных лимитов, десинхронизации протоколов, логических несоответствий парсеров и состязательных атак на модели машинного обучения.

Архитектурные ограничения инспекции и атака Padding Evasion

В основе функционирования большинства коммерческих и облачных WAF лежит компромисс между глубиной инспекцией сетевых пакетов и задержкой (latency) при обработке запросов. Для поддержания высокой пропускной способности разработчики WAF вынуждены вводить жёсткие ограничения на объём проверяемого тела запроса — лимиты буферизации, которые обычно составляют от 8 КБ до 128 КБ.

Атака с заполнением полезной нагрузки (Payload Padding, или Padding Evasion) нацелена непосредственно на эксплуатацию этих ограничений. Её суть заключается в искусственном увеличении размера HTTP-запроса с помощью добавления избыточных, но синтаксически корректных данных (например, пустых JSON-массивов, комментариев или длинных строк Base64). Маскирующий буфер («мусорные данные») помещается в начало тела запроса, а вредоносный код — в самый конец, за пределы инспекционной границы WAF.

Практическим катализатором исследования этой проблемы стала критическая уязвимость удалённого выполнения кода React2Shell (CVE-2025-55182) с максимальной оценкой CVSS 10.0. Эксплойты для уязвимости обладают значительным размером, что позволяет им легко преодолевать стандартные ограничения WAF на размер проверяемых данных.

Реакция различных архитектур WAF на получение запроса, размер которого превышает установленный лимит инспекции, разделяет рынок на три категории, каждая из которых несёт определенные риски для организации:

Протокольная десинхронизация и манипуляции с парсерами

Современные веб-инфраструктуры строятся на основе многоуровневых цепочек серверов, где трафик от пользователя последовательно проходит через прокси-серверы, балансировщики нагрузки и WAF, прежде чем попасть на бэкенд. Если эти компоненты по-разному интерпретируют границы входящих HTTP-запросов, возникает угроза протокольной десинхронизации (HTTP Request Smuggling, HRS).

Классическая и клиентская контрабанда запросов (HRS)

В спецификации HTTP/1.1 длина запроса может определяться двумя заголовками: Content-Length (CL), указывающим точный размер в байтах, и Transfer-Encoding: chunked (TE), разделяющим тело на шестнадцатеричные фрагменты (чанки). Атака HRS реализуется путём одновременной отправки обоих заголовков, один из которых может быть слегка обфусцирован. Разница в приоритетах обработки данных заголовков на фронтенде и бэкенде приводит к двум классическим сценариям десинхронизации:

• Сценарий CL.TE. Фронтенд (WAF) обрабатывает запрос на основе CL, считывая его целиком и передавая дальше. Бэкенд ориентируется на TE, завершает обработку на нулевом чанке, а оставшуюся часть полезной нагрузки («контрабандный» запрос) оставляет в сокете соединения, где она автоматически приплюсовывается к началу следующего запроса легитимного пользователя.

• Сценарий TE.CL. Фронтенд считывает запрос по правилам чанковой передачи, а бэкенд обрабатывает строго то количество байт, которое указано в Content-Length. В результате часть чанка зависает в буфере бэкенда, искажая последующий входящий трафик.

Клиентская вариация десинхронизации (Browser-Powered Desync) заставляет браузер жертвы отправлять некорректно размеченные запросы через стандартные кросс-доменные механизмы (такие как CORS или HTML-формы). Поскольку браузер жёстко контролирует заголовки, атакующие используют альтернативные примитивы уклонения: манипуляции с путями, инъекции в строки запросов и формирование структуры тела через multipart-формы, нацеливаясь на кэширующие прокси-серверы.

Расхождения в парсинге Multipart-данных и заголовков (Parser Differentials)

Уязвимости рассогласования парсеров возникают из-за различий в грамматических правилах, реализуемых WAF и бэкенд-платформами при разборе сложных форматов. Например, при отправке запросов в формате multipart/form-data WAF может извлекать и сканировать только те поля, которые соответствуют его внутреннему синтаксическому анализатору. Если бэкенд поддерживает альтернативный синтаксис (например, игнорирует некорректные символы в границах разделов или использует первый параметр boundary вместо последнего), WAF проанализирует безопасную интерпретацию трафика, тогда как бэкенд соберёт и выполнит эксплойт.

Аналогично, манипуляции с заголовками позволяют обойти правила фильтрации. Отправка невалидного с точки зрения спецификации заголовка может привести к тому, что WAF не сможет разобрать строку и проигнорирует её содержимое. В то же время бэкенд-сервер (например, на базе Node.js или IIS) успешно нормализует заголовок и обработает содержащуюся в нём инъекцию.

Данный тип расхождений также наблюдается при обходе списков контроля доступа (ACL) веб-серверов путём pathname-манипуляций. В таблице ниже систематизированы символы, использование которых приводит к рассогласованию нормализации путей между Nginx (выполняющим функции WAF/обратного прокси) и популярными бэкенд-фреймворками:

Логические дефекты парсинга характерны также для классических WAF-систем. Так, в ModSecurity v3 (до версии 3.0.12) существовала критическая ошибка в обработке переменных REQUEST_FILENAME и PATH_INFO. Из-за того что ModSecurity декодировал URL для извлечения пути до разделения параметров, запрос вида /foo%3f';alert(1);foo= воспринимался им как путь /foo (анализатор считал, что путь заканчивается на декодированном символе «?»), тогда как бэкенд обрабатывал всю строку целиком, исполняя внедрённый XSS-код. В ModSecurity v2 аналогичный обход правил защиты файлов (например, запрет на доступ к резервным копиям .bak) реализовывался путём URL-кодирования точки как %2e.

Логические атаки и загрязнение параметров (HTTP Parameter Pollution)

Метод загрязнения HTTP-параметров (HTTP Parameter Pollution, HPP) основан на отсутствии жёстких стандартов RFC в отношении обработки повторяющихся параметров с одинаковыми именами в рамках одного запроса. Каждая серверная платформа и веб-фреймворк используют собственную логику парсинга таких структур, что позволяет злоумышленникам дробить вредоносную нагрузку между несколькими параметрами, обходя сигнатурный анализ WAF.

Обход WAF с использованием HPP и JavaScript-инъекций

Практические исследования эффективности современных облачных WAF-решений (включая AWS WAF, Azure WAF, Google Cloud Armor и Cloudflare) показывают высокую результативность HPP-атак. Если простые сигнатурные полезные нагрузки блокируются в большинстве случаев, то применение HPP позволяет повысить процент успешных обходов.

Наиболее эффективный вектор эксплуатации HPP нацелен на платформу ASP.NET и использует её алгоритм comma-конкатенации в сочетании с оператором запятой в синтаксисе JavaScript. Запрос формируется следующим образом: /?q=1'&q=alert(1)&q='2.

WAF анализирует каждое вхождение параметра q независимо. Ни один из фрагментов (1', alert(1), '2) сам по себе не содержит полноценной сигнатуры межсайтового скриптинга, поэтому запрос пропускается. Однако на стороне IIS метод HttpUtility.ParseQueryString() объединяет значения в единую строку: 1',alert(1),'2.

В контексте выполнения JavaScript этот результат интерпретируется как три независимых выражения, разделённых запятыми. Браузер последовательно выполняет их все, что приводит к успешному срабатыванию функции alert(1). Данный метод также успешно применяется для обхода проверок безопасности в API-интерфейсах, логике авторизации OAuth (например, в сервисах Digits) и финансовых транзакциях, где дублирование параметров приводит к несанкционированному изменению валют или лимитов. 

Обфускация, семантическое уклонение и логические уязвимости

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

Статические пути инспекции и кэширование

Иногда архитектуры CDN и WAF снижают уровень инспекции контента или полностью отключают правила безопасности для GET-запросов, направленных на получение статических ресурсов (например, путей, оканчивающихся на .js). Это ограничение может быть использовано для доставки вредоносной нагрузки.

Злоумышленник отправляет GET-запрос к файлу .js (/static/main.js), помещая вредоносную нагрузку во второстепенные заголовки (такие как User-Agent или Referer), которые отражаются в теле ответа. Сразу после этого с помощью пакетной отправки (в Burp Repeater используется функция Send group in parallel) отправляется запрос к основному HTML-ресурсу. Это провоцирует отравление кэша (Cache Poisoning) или децепцию кэша (Cache Deception), в результате чего вредоносная копия файла сохраняется на уровне CDN и отдаётся последующим пользователям без повторной проверки WAF.

Многократное декодирование в контекстных WAF

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

• Bypass Akamai — использование избыточного URL-кодирования угловых скобок и специальных символов внутри обработчиков событий для обхода многократного цикла декодирования: <x/%u003e/tabindex=1 autofocus/onfocus=x=self;x['ale'%2b'rt'](999)>.

• Bypass AWS / CloudFront — применение HTML-сущностей (>) внутри тегов, заставляющих парсер WAF считать элемент закрытым и безопасным: <x/%26%23x3e;/tabindex=1 autofocus/onfocus=alert(999)>.

• Bypass Cloudflare — эксплуатация прототипов JavaScript и особенностей транзитных переходов CSS для выполнения кода при фокусировке элемента: <x tabindex=1 autofocus/onfocus="style.transition='0.1s';style.opacity=0;self.ontransitionend=alert;Object.prototype.toString=x=>999">.

Логические уязвимости и специфичный для приложений контекст

Универсальные правила WAF не способны защитить приложения от логических ошибок. Например, уязвимости аутентификации в плагинах WordPress или механизмах SAML часто используют легитимные с точки зрения HTTP-протокола запросы.

Примером служит дефект логики OAuth-авторизации, когда приложение доверяет клиентским идентификаторам при отсутствии данных от провайдера и вызывает функцию wp_set_auth_cookie(). Злоумышленник отправляет стандартный POST-запрос к admin-ajax.php, умышленно исключая или повреждая токен провайдера (Facebook или Google). Внутренний обработчик переходит к блоку default, где выполнение продолжается с использованием переданного в теле POST-запроса идентификатора пользователя. Для WAF данный запрос выглядит как стандартный сессионный трафик, поскольку он не содержит классических признаков SQLi или XSS, что обеспечивает полный обход контроля доступа.

К аналогичной категории относятся новые методы эксплуатации SAML и векторы SSRF, использующие петли HTTP-перенаправлений (HTTP Redirect Loops), которые маскируют конечный целевой хост от проверок WAF на этапе инициации запроса.

Высокотехнологичные цепочки PHP-фильтров (LFI to RCE)

Традиционная эксплуатация уязвимостей локального подключения файлов (Local File Inclusion, LFI) с целью чтения конфиденциальных файлов (таких как /etc/passwd или .env) или записи веб-шеллов через отравление логов (Log Poisoning) легко детектируется сигнатурными правилами WAF. Однако использование цепочек PHP-фильтров через обёртку php://filter позволяет преобразовать пассивное чтение файлов в полноценное удалённое выполнение кода (RCE) исключительно в оперативной памяти процесса, исключая необходимость записи файлов на диск или генерации подозрительных путей traversal.

Механизм атаки базируется на последовательном применении встроенных конвертеров и кодеков PHP, доступных через функцию stream_get_filters(). Процесс посимвольного воссоздания вредоносного кода в памяти основывается на следующих этапах:

1. Инициация и масштабирование памяти. Использование кодека UCS-4LE позволяет экспоненциально увеличить размер обрабатываемой строки и разместить управляющие байты в начале текстового потока.

2. Hex-валидация через dechunk. Фильтр dechunk удаляет данные из потока, если первый символ не является шестнадцатеричным. Это свойство используется для проведения посимвольного фаззинга: если после преобразования символ находится в диапазоне 0-9 или a-f, фильтр сохраняет поток, провоцируя контролируемую ошибку PHP при переполнении буфера.

3. Ротация символов (CP930). Кодек convert.iconv.UNICODE.CP930 осуществляет последовательный сдвиг символов (например, преобразует символ a в b), что позволяет перемещать буквы в шестнадцатеричный диапазон и обратно для их последующего распознавания.

4. Сдвиг байтов и удаление мусора. С помощью последовательного применения кодеков переупорядочивания байтов, таких как convert.iconv.UTF16.UTF-16BE и convert.iconv.UCS-4.UCS-4LE, атакующий генерирует два байта нерелевантных данных в начале текста, после чего удаляет их. Это сдвигает указатель чтения на следующую позицию, позволяя последовательно извлекать и декодировать всю строку.

Поскольку формируемый URL-запрос состоит исключительно из названий легитимных кодеков кодирования (таких как convert.base64-decode, convert.iconv.*, zlib.deflate), классические WAF не видят в нём признаков атаки, трактуя запрос как стандартную операцию сериализации данных.

Применение искусственного интеллекта и состязательного машинного обучения против WAF

Внедрение моделей машинного обучения (ML) для классификации трафика позволило повысить точность обнаружения аномалий, однако одновременно создало новый класс угроз — состязательные атаки (Adversarial ML). Целью атакующего является генерация семантически вредоносного запроса, который синтаксически оценивается ML-классификатором как безопасный (легитимный) трафик. Для автоматического поиска слепых зон в ML-моделях и сигнатурных движках (таких как ModSecurity) применяются специализированные состязательные инструменты:

• WAF-A-MoLE — фаззер, реализующий направленные мутации на основе генетических алгоритмов. Получая на вход рабочий эксплойт (например, SQL-инъекцию), инструмент помещает его в пул приоритетной очереди, ранжированный по оценке доверия (confidence score) классификатора WAF. На каждой итерации к заголовку пула применяются семантически эквивалентные операторы мутации до тех пор, пока оценка WAF не упадёт ниже порога блокировки.

• GSQLi — генеративно-состязательная сеть (GAN), обученная генерировать мутировавшие SQL-нагрузки. Генератор GAN создаёт варианты инъекций, а дискриминатор оценивает их способность обходить защиту, что позволяет обучить модель создавать высокоэффективные обходы для реальных WAF.

Ключевые семантически эквивалентные операторы мутации, используемые для обхода ML-моделей, представлены в таблице ниже:

Комплексные стратегии харденинга и тестирования WAF

Большинство организаций сталкиваются с одной и той же проблемой: WAF куплен, установлен и... забыт. Между тем, угрозы эволюционируют быстрее, чем внутренние команды успевают реагировать. Закрыть этот разрыв помогут специалисты Angara Security — с экспертизой в настройке правил, обработке исключений и нетипичных сценариев реагирования.

Если у вас остаются вопросы по применению WAF, обратитесь к нам, разберем конкретные ситуации.

Источники

1. Web Application Firewalls (WAF) in 2025: In-Depth Guide, https://www.oligo.security/academy/web-application-firewalls-waf-in-2025-in-depth-guide
2. When WAFs Go Awry: Common Detection & Evasion Techniques for Web Application Firewalls - MDSec, https://www.mdsec.co.uk/2024/10/when-wafs-go-awry-common-detection-evasion-techniques-for-web-application-firewalls/
3. WAF Best Practices 2026: Strategic Guide to Protecting Your Web Apps, https://www.alessioligabue.it/en/blog/waf-best-practices
4. Payload Padding WAF Bypass: The 2026 WAF Blind Spot | Prophaze, https://www.prophaze.com/payload-padding-waf-bypass-blind-spot/
5. Best WAF Solutions in 2026: Real-World Comparison - open-appsec, https://www.openappsec.io/post/best-waf-solutions-in-2026-real-world-comparison
6. Proxy / WAF Protections Bypass - HackTricks, https://hacktricks.wiki/en/pentesting-web/proxy-waf-protections-bypass.html
7. [2001.01952] WAF-A-MoLE: Evading Web Application Firewalls through Adversarial Machine Learning - arXiv, https://arxiv.org/abs/2001.01952
8. What is HTTP request smuggling? Tutorial & Examples | Web Security Academy, https://portswigger.net/web-security/request-smuggling
9. Access Control Bypass via Request Smuggling - Clear Gate, https://www.clear-gate.com/blog/access-control-bypass-via-request-smuggling/
10. What is HTTP Request Smuggling? - Fastly, https://www.fastly.com/fr/learning/security/what-is-http-request-smuggling
11. Browser HTTP Request Smuggling - HackTricks, https://hacktricks.wiki/en/pentesting-web/http-request-smuggling/browser-http-request-smuggling.html
12. HTTP Parameter Pollution (HPP) - aw-junaid/bug-bounty - GitHub, https://github.com/aw-junaid/bug-bounty/blob/main/resources/cheatsheets/HTTP%20Parameter%20Pollution.md
13. bug-bounty/methodologies/web penetration/HTTP Parameter Pollution.md at main - GitHub, https://github.com/aw-junaid/bug-bounty/blob/main/methodologies/web%20penetration/HTTP%20Parameter%20Pollution.md
14. HTTP Parameter Pollution | Examples & Mitigation Methods - Imperva, https://www.imperva.com/learn/application-security/http-parameter-pollution/
15. HTTP parameter pollution - Wikipedia, https://en.wikipedia.org/wiki/HTTP_parameter_pollution
16. Wordpress - HackTricks, https://hacktricks.wiki/en/network-services-pentesting/pentesting-web/wordpress.html
17. Top 10 web hacking techniques of 2025 | PortSwigger Research, дата последнего обращения: мая 22, 2026, https://portswigger.net/research/top-10-web-hacking-techniques-of-2025
18. Local File Inclusion (LFI) - Invicti, https://www.invicti.com/learn/local-file-inclusion-lfi
19. File Inclusion/Path traversal - HackTricks, https://hacktricks.wiki/en/pentesting-web/file-inclusion/index.html
20. PHP filters chain: What is it and how to use it - Synacktiv, https://synacktiv.com/publications/php-filters-chain-what-is-it-and-how-to-use-it
21. Bypassing WAFs with Adversarial ML | PDF | Statistical Classification | Machine Learning - Scribd, https://www.scribd.com/document/521779579/2001-01952
22. WAF-A-MoLE: Evading Web Application Firewalls through Adversarial Machine Learning - IRIS UniGe, https://unige.iris.cineca.it/retrieve/e268c4cc-b7ad-a6b7-e053-3a05fe0adea1/main.pdf
23. GSQLi: A GAN-based Approach for Adversarial SQL Injection Sample Generation against WAF - IEEE Xplore, https://ieeexplore.ieee.org/document/11106089/
24. AvalZ/WAF-A-MoLE: A guided mutation-based fuzzer for ML-based Web Application Firewalls - GitHub, https://github.com/AvalZ/WAF-A-MoLE
25. nemesida-waf/waf-bypass: Check your WAF before an attacker does - GitHub, https://github.com/nemesida-waf/waf-bypass.