WAF есть, а взломы продолжаются? Причина — не технология, а типовые ошибки настройки. Разбираем 10 самых частых провалов при внедрении защиты веб-приложений, чтобы не блокировать клиентов и не пропускать хакеров, а построить по-настоящему эффективную систему безопасности.
- 1. Введение
- 2. Ошибка 1. Слепая вера в базовые правила «из коробки»
- 3. Ошибка 2. Игнорирование ложных срабатываний и отсутствие процесса их обработки
- 4. Ошибка 3. Отсутствие анализа и защиты бизнес-логики приложений
- 5. Ошибка 4. Неправильная работа с регулярными выражениями
- 6. Ошибка 5. Игнорирование вопросов производительности и вносимых задержек
- 7. Ошибка 6. Работа только с сигнатурами без поведенческого анализа
- 8. Ошибка 7. Отсутствие защиты API и мобильных приложений
- 9. Ошибка 8. Слабая интеграция с SIEM и процессами реагирования
- 10. Ошибка 9. Отсутствие регулярного обновления правил
- 11. Ошибка 10. Формальное внедрение WAF без изменения процессов разработки
- 12. Выводы
Введение
Web Application Firewall (WAF) — это специализированный экран для защиты веб-приложений от атак вроде SQL-инъекций и XSS. Сегодня WAF стал обязательным элементом безопасности любого корпоративного сайта, особенно если он связан с хранением или обработкой персональных данных либо относится к критической информационной инфраструктуре.
Однако, несмотря на то что компании повсеместно внедряют WAF, сайты до сих пор взламывают с завидной регулярностью. Либо, наоборот, система блокирует всех подряд, включая обычных пользователей, и бизнес теряет клиентов.
Согласно статистике, 43 % компаний теряют клиентов из-за кибератак, а 60 % малого бизнеса закрываются после успешного взлома. При этом в 40 % случаев взломанные компании имели WAF, но он был настроен неправильно. Другими словами, проблема не в том, что технология WAF неэффективна, а в том, что администраторы часто допускают ошибки в настройке системы.
Ошибка 1. Слепая вера в базовые правила «из коробки»
Многие компании считают, что для достижения максимальной безопасности системы достаточно просто интегрировать WAF и включить базовую защиту «из коробки» со стандартными правилами OWASP Core Rule Set. Это грубейшая ошибка, которая зачастую приводит либо к ложным блокировкам юзеров, либо к пропуску реальных атак.
Суть ошибки
Администраторы оставляют правила WAF по умолчанию, никак не адаптируя их под особенности приложения, его архитектуру и вид входных данных. Разработчики делают базовые правила OWASP Core Rule Set максимально строгими, чтобы обеспечить защиту в максимально широком спектре сценариев, однако они никак не оптимизированы под специфику конкретных типов инфраструктур. Ввиду этого базовые регламенты защиты могут блокировать безобидные пользовательские запросы из-за таких тривиальных вещей, как необычные символы, апострофы, знаки «меньше» и «больше» в комментариях, распознавая их как часть вредоносного кода.
Администраторы не проводят начальную настройку: не анализируют логи в первые недели работы, не выявляют ложные срабатывания, не создают исключения для легитимных сценариев. При этом не учитывается версия используемого стека технологий — для приложений на PHP, Java, Node.js, .NET требуются абсолютно разные подходы к настройке WAF.
Пример ошибки: Equifax (2017)
В 2017 году кредитное бюро Equifax подверглось одной из самых масштабных утечек персональных данных в истории, затронувшей 147 миллионов человек. Атака использовала уязвимость в Apache Struts (CVE-2017-5638). Эта уязвимость была публично известна, а патч вышел за два месяца до инцидента. Equifax использовала WAF, но с настройками по умолчанию, поэтому система пропустила злоумышленников. Они беспрепятственно воспользовались «удалённой» дырой и похитили огромный объём данных. Компания позже признала, что WAF не был должным образом сконфигурирован для защиты от угроз.
Чем опасна эта ошибка
Просто поставить WAF с базовыми правилами и верить в стопроцентную защищённость категорически нельзя — это создаёт ложное чувство безопасности. Компания думает, что WAF работает, а на самом деле он либо пропускает реальные атаки (если правила не обновляются и не адаптируются под новые техники обхода), либо блокирует реальных пользователей, что приводит к репутационным и финансовым потерям.
В некоторых случаях, когда количество необоснованных блокировок слишком велико, администраторы идут на компромисс и переводят WAF в режим мониторинга. Это сводит на нет всю защитную инфраструктуру — теперь WAF только смотрит, но не блокирует.
Рисунок 1. Распространённые атаки на интернет-платформы. Источник: Anti-Malware.ru
Ошибка 2. Игнорирование ложных срабатываний и отсутствие процесса их обработки
Ложные срабатывания — это не только свидетельство недостаточной настройки WAF, но и огромная нагрузка на инфраструктуру кибербезопасности, которая затмевает собой реальные сообщения об угрозах. Несмотря на это, многие компании либо вообще не замечают эту проблему, либо не придают ей значения.
Суть ошибки
Администраторы WAF игнорируют ложные срабатывания: не анализируют логи, не собирают обратную связь от разработчиков или пользователей и не ищут первопричины алертов. Хотя эта информация может быть крайне полезна для создания базы исключений под легитимные сценарии, тем самым снизив количество ложных срабатываний. Из-за игнорирования такие события накапливаются в логах, создавая огромный информационный шум. В этом шуме тонут действительно опасные события, и соотношение сигнал/шум становится критически низким.
Нередко в компаниях отсутствует регламент взаимодействия между командой безопасности и отделом разработки по вопросам ложных срабатываний. Разработчики не знают, куда и как сообщать о проблемах, а специалисты по кибербезопасности не объясняют, почему запрос был заблокирован.
Пример ошибки: Azure WAF (2024)
Пользователи Azure Application Gateway с WAF регулярно сталкиваются с проблемой ложных срабатываний при использовании Keycloak для аутентификации. SAML-данные и JWT-токены случайным образом совпадают с правилами OWASP 3.2. Например, в 2024 году один пользователь сообщил, что при выходе из системы параметр id_token_hint, представляющий собой base64-кодированный JSON, содержал подстроку «.nsr». Она совпала с правилом, блокирующим попытки доступа к файлам операционной системы. Проблема до сих пор не исправлена, а срабатывания происходят настолько часто, что администраторам Azure WAF приходится вручную отключать целые группы правил, чтобы сохранить работоспособность системы.
Чем опасна эта ошибка
Накопление необработанных ложных срабатываний ведёт к тому, что команда перестаёт доверять WAF и начинает искать способы его обхода или даже полного отключения. При этом подключаются фреймворки, создающие видимость работы защитной системы «для отчётности». Кроме того, под давлением вышестоящего руководства, теряющего клиентов из-за ложных блокировок, администраторы могут начать отключать «шумные» правила одно за другим, не разбираясь в их назначении. В итоге защита становится бесполезной.
Ещё один риск — аналитики WAF тратят бóльшую часть своего времени на разбор ложных срабатываний вместо изучения реальных угроз. Это снижает эффективность всего центра мониторинга. Отсутствие процесса обработки ложных срабатываний — признак незрелости инфраструктуры ИБ, которая рано или поздно приведёт либо к утечке персональных данных, либо к полному отказу от использования WAF.
Ошибка 3. Отсутствие анализа и защиты бизнес-логики приложений
WAF классического типа, основанный на базовых сигнатурах, отлично отражает простейшие атаки вроде SQL-инъекций или XSS. Но если речь идёт об отражении кибератак современного типа, которые нацелены не на протокол, а на логику приложения, WAF становится бесполезен.
Суть ошибки
Компании фокусируются исключительно на настройке защиты от критических уязвимостей из OWASP Top 10. Они полностью игнорируют необходимость защиты от атак, эксплуатирующих бизнес-логику, и не проводят адаптацию настроек под бизнес-процессы организации.
Например, для интернет-магазина критически важна защита от массового бот-спама заказа товаров, для банка — от парсеров номеров счетов или карт, для медицинского портала — от несанкционированного доступа к чужим медицинским картам путём подбора идентификаторов.
WAF без тонкой настройки под бизнес-процессы такие атаки просто не видит, потому что технически каждый отдельный запрос подобного рода формально является легитимным и соответствует спецификации HTTP.
Пример ошибки: ЦИПР 2025 (2025)
В июне 2025 года при подготовке к конференции «ЦИПР-2025» специалисты Positive Technologies и Servicepipe столкнулись с массированными автоматизированными попытками сканирования веб-ресурсов форума. Злоумышленники искали слабые места и уязвимости в сайтах регистрации, через которые регистрируются первые лица регионов и топ-менеджеры крупных компаний. Только комбинация PT Application Firewall и системы защиты от ботов Servicepipe Cybert позволила предотвратить все попытки атак, включая те, что нацелены на бизнес-логику регистрационных форм.
Чем опасна эта ошибка
Атаки на бизнес-логику часто наносят гораздо больший ущерб, чем сугубо технические взломы. Причём страдает именно бюджет и репутация. Они могут уничтожить товарные запасы, исказить результаты выборов, парализовать работу сервисов бронирования, привести к массовым выплатам бонусов мошенникам и т. д. WAF, не учитывающий контекст бизнеса, остаётся полностью безоружным перед этими угрозами. Злоумышленники могут годами эксплуатировать уязвимости логики, оставаясь незамеченными. Компания теряет не данные, а деньги напрямую, но при этом служба безопасности рапортует, что WAF работает и атак нет.
Рисунок 2. Основные виды атак, которые блокируются WAF. Источник: Mungfali
Ошибка 4. Неправильная работа с регулярными выражениями
Регулярные выражения — это мощный и гибкий инструмент, лежащий в основе многих правил WAF, особенно в OWASP Core Rule Set. Но они же становятся источником серьёзнейших проблем при непрофессиональном использовании.
Суть ошибки
Администраторы или разработчики правил пишут неэффективные либо просто ошибочные регулярные выражения. Это приводит к падению производительности системы или создаёт новые уязвимости. Наиболее опасны «жадные» квантификаторы с конструкциями типа .*, .+, особенно когда они используются с неопределённым количеством повторений в середине выражения.
Такой подход заставляет движок регулярных выражений перебирать миллионы и миллиарды комбинаций при определённых входных данных, создавая огромную нагрузку на инфраструктуру. Отсутствие у администратора понимания принципов работы regexp-движков — верный признак того, что рано или поздно в системе появятся серьёзные бэкдоры для мощных атак.
Пример ошибки: Cloudflare (2019)
В 2019 году инженеры Cloudflare обнаружили и исправили несколько ReDoS-уязвимостей в собственных WAF-правилах, используемых для защиты миллионов сайтов. Проблема заключалась в регулярных выражениях, которые могли быть вызваны специально сконструированными запросами, приводящими к экспоненциальному росту времени обработки.
Хотя публичных сообщений об эксплуатации этих уязвимостей не было, сам факт их наличия показал, что даже крупнейшие провайдеры могут допускать ошибки в регулярных выражениях, создавая риск отказа в обслуживании для клиентов.
Чем опасна эта ошибка
Неграмотно настроенные правила WAF позволяют злоумышленникам создавать уязвимости класса ReDoS — HTTP-запросы с параметрами, содержащими «патологические» строки, которые вызывают экспоненциальный рост времени обработки регулярного выражения. Один такой запрос может загрузить ядро процессора WAF на несколько секунд, а несколько параллельных запросов — полностью парализовать его работу.
В облачных средах это способно привести к отказу в обслуживании не только WAF, но и всего защищаемого приложения. Даже без злого умысла неэффективные выражения кратно увеличивают задержки обработки пользовательских запросов на десятки и сотни миллисекунд. В масштабах высоконагруженных проектов это выливается в ощутимое падение производительности платформы и, как следствие, в ухудшение пользовательского опыта.
Ошибка 5. Игнорирование вопросов производительности и вносимых задержек
WAF — это дополнительное звено в цепочке обработки запроса, которое анализирует трафик на прикладном уровне. Это сложная и ресурсоёмкая операция, которая неизбежно генерирует задержки. Многие компании забывают об этом, пока высокие нагрузки не превращают эти задержки в критическую проблему.
Суть ошибки
Многие администраторы второпях внедряют WAF для обеспечения должного уровня защиты инфраструктуры. Они нередко забывают выполнять полноценные нагрузочные тесты, чтобы определить влияние WAF на время отклика приложения, максимальное количество запросов в секунду, потребление памяти и ресурсов процессора. В итоге выбор падает на неподходящий тип развёртывания, который не учитывает требования к задержкам и пропускной способности. Администраторы могут неправильно настроить режимы проверки.
Они включают все возможные правила и анализаторы без необходимости, что кратно увеличивает нагрузку, а также не используют кэширование результатов проверки для экономии статических ресурсов. Даже если с виду WAF настроен разумно, важно регулярно мониторить метрики производительности самого WAF в реальном времени, что часто игнорируется.
Пример ошибки: Cloudflare (2024)
2 июля 2024 года из-за ошибки в Lua-коде WAF сеть Cloudflare, обслуживающая около 20 % мирового трафика, частично оказалась недоступна на 25 минут. Треть запросов завершалась ошибкой 500. Инженеры внедряли защиту от критической уязвимости CVE-2025-55182 в React и использовали подсистему для отключения тестового инструментария. Но комбинация ранее не тестировалась — произошла попытка выполнения метода для неинициализированного объекта, что привело к аварийному завершению обработчика.
Чем опасна эта ошибка
Игнорирование производительности WAF приводит к прямым финансовым потерям. Согласно исследованиям Amazon и Google, каждая лишняя миллисекунда задержки снижает конверсию на доли процента. Для крупного e-commerce это миллионы рублей упущенной выручки. Полная недоступность сайта в пиковые моменты означает не только упущенную выгоду, но и испорченную репутацию, а также уход клиентов к конкурентам. Перегруженный WAF сам становится целью атаки: злоумышленники могут намеренно генерировать трафик, требующий глубокой и ресурсоёмкой проверки, чтобы вызвать отказ в обслуживании.
Ошибка 6. Работа только с сигнатурами без поведенческого анализа
Традиционные WAF строят защиту на поиске известных признаков атак, но современные злоумышленники научились обходить базовые сигнатуры с помощью обфускации, кодирования и других продвинутых техник маскировки. Поведенческий анализ позволяет обнаруживать то, что не видно WAF.
Суть ошибки
Компании полагаются исключительно на сигнатурный анализ, не используя более продвинутые методы: анализ динамического поведения, машинное обучение, обнаружение аномалий и анализ репутации IP-адресов. Они не учитывают, что современные злоумышленники давно научились обходить известные сигнатуры с помощью различных техник обфускации: изменение регистра символов, URL-кодирование, двойное кодирование, брутфорс, разбивка вредоносной нагрузки на несколько частей.
Рисунок 3. Рост количества брутфорс-атак на КИИ. Источник: Anti-Malware.Ru
Пример ошибки: Ticketmaster (2018)
В 2018 году Ticketmaster стала жертвой атаки Magecart. Злоумышленники внедрили вредоносный JavaScript-код через уязвимость в стороннем чат-боте, интегрированном на сайт. Скрипт собирал данные карт покупателей. Сигнатурный WAF не заметил подмены, поскольку скрипт был загружен с легитимного стороннего ресурса. Поведенческий анализ, отслеживающий изменения в цепочке поставок JavaScript, мог бы выявить аномалию, но он отсутствовал.
Чем опасна эта ошибка
Сигнатурный подход всегда отстаёт от изобретательности злоумышленников. Пока поставщик WAF не обновит базы сигнатур, компания остаётся уязвимой к новым типам атак. Организации, полагающиеся только на сигнатуры, рискуют пропустить целевые атаки с использованием нестандартных техник. Поведенческий анализ позволяет обнаруживать неизвестные угрозы по их аномальному поведению, но без него WAF видит лишь шаблонные атаки.
Ошибка 7. Отсутствие защиты API и мобильных приложений
Современные веб-приложения — это не просто HTML-страницы, а сложные API, обслуживающие мобильные приложения и внешние сервисы. Многие компании забывают, что API нуждается в отдельной настройке WAF, принципы которой отличаются от защиты основного сайта.
Суть ошибки
Администраторы настраивают WAF для защиты основного сайта, но забывают про API-эндпоинты, используемые мобильными приложениями или партнёрскими интеграциями. API часто работают с чувствительными данными и имеют свою специфику: JSON-формат, авторизация через токены, высокая частота запросов. Настройки WAF для веб-форм не подходят для API: то, что в веб-форме является атакой, в JSON-запросе может быть легитимными запросами. Из-за этого реальные атаки на API остаются невидимыми: массовое обращение к эндпоинтам, подбор токенов, инъекции в JSON-структуры.
Пример ошибки: JPMorganChase (2024)
В ходе исследования Zafran выяснилось, что основной сайт JPMorganChase был уязвим для обхода WAF. API-эндпоинты и backend-серверы банка были доступны напрямую через интернет, минуя защиту CDN и WAF. После уведомления исследователей компания оперативно закрыла уязвимость, но сам факт, что крупнейший банк США годами имел такую брешь, говорит о системной проблеме игнорирования защиты API-инфраструктуры.
Чем опасна эта ошибка
API часто защищены хуже, чем основной сайт, поэтому злоумышленники зачастую целятся именно в них. Компрометация API может привести к огромной утечке персональных данных, несанкционированным операциям от имени пользователей, доступу к бэкенд-системам. Без специальной настройки WAF под специфику API компания оставляет широкий плацдарм для масштабных атак, последствия от которых будут исчисляться многомиллионными штрафами.
Рисунок 4. Доля успешно отражаемых атак на API. Источник: Anti-Malware.Ru
Ошибка 8. Слабая интеграция с SIEM и процессами реагирования
WAF генерирует огромное количество событий, но если эти события не попадают в единую систему мониторинга (SIEM) и не становятся сигналом для соответствующей реакции, эффективность защиты сводится к нулю.
Суть ошибки
Логи WAF хранятся внутри системы, но не передаются в SIEM, не анализируются и не коррелируют с событиями от других средств защиты. Инциденты обнаруживаются случайно или постфактум, когда ущерб от атаки уже нанесён. Особенно критично, если отсутствует настройка алертов для особенно рискованных событий: множественные срабатывания одного правила, атаки на конкретные эндпоинты, превышение пороговых значений. Очевидно, что если нет алертов, то не будет и регулярного анализа логов для выявления трендов и улучшения правил WAF.
Пример ошибки: MyFitnessPal (2018)
В 2018 году Under Armour, владелец фитнес-приложения MyFitnessPal, обнаружил утечку данных 150 миллионов пользователей. Атака произошла через уязвимость в API, и злоумышленники выгружали данные в течение нескольких недель. Компания узнала об инциденте только после того, как данные начали продавать в даркнете. Хотя WAF мог фиксировать подозрительную активность, логи либо не анализировались, либо не вызывали алертов из-за отсутствия интеграции с SIEM. В результате утечка оставалась незамеченной долгое время.
Чем опасна эта ошибка
WAF без интеграции в процессы реагирования — это дорогой регистратор событий, а не активный элемент защиты. Злоумышленники могут неделями тестировать приложение на прочность, атаковать его разными способами, и никто этого не заметит. Без интеграции с SIEM невозможно строить сложные корреляции, например, связывать атаку на веб-приложение с последующим подозрительным поведением в сети. Среднее время обнаружения и реагирования кратно увеличивается, что напрямую влияет на масштабы нанесённого ущерба от инцидента.
Ошибка 9. Отсутствие регулярного обновления правил
Угрозы веб-приложениям эволюционируют стремительно. Каждую неделю появляются новые уязвимости и новые техники обхода защиты. WAF с устаревшими правилами быстро теряет эффективность и работает как legacy-антивирус с устаревшими базами.
Суть ошибки
Если внедрить WAF, настроить и оставить его без изменений на многие месяцы, со временем он может стать не только бесполезен, но и опасен. Многие администраторы не забывают про WAF, а боятся браться за его настройку, потому что однажды это привело к ложным срабатываниям, и теперь они выбирают «стабильность» в ущерб безопасности. Очень важно регулярно пересматривать и актуализировать правила WAF: только это позволяет успевать адаптировать инфраструктуру ИБ под постоянно меняющийся ландшафт угроз.
Пример ошибки: Log4Shell (2021)
В декабре 2021 года была обнаружена критическая уязвимость Log4Shell в библиотеке Log4j, затрагивающая миллионы приложений. Компании, которые оперативно обновили правила WAF в течение 24–48 часов, смогли заблокировать попытки эксплуатации на периметре. Те, кто не обновлял WAF годами или не следил за новостями, остались полностью уязвимыми и вынуждены были срочно латать каждое приложение вручную, тратя огромное количество человеко-часов и ресурсов. Многие организации пострадали именно из-за того, что их WAF не имел актуальных правил для блокировки этой атаки.
Чем опасна эта ошибка
Устаревшие правила создают ложное чувство защищённости. Компания думает, что WAF работает, а на самом деле он пропускает все атаки нового типа. Злоумышленники активно отслеживают свежие уязвимости и начинают эксплуатировать их в первые же часы после публикации. Если WAF не обновляется регулярно, компания проигрывает гонку вооружений. Разрыв между версиями правил может составлять годы, что означает отсутствие защиты от тысяч современных векторов атак.
Ошибка 10. Формальное внедрение WAF без изменения процессов разработки
Самая глубокая и опасная ошибка — рассматривать WAF как «палочку-выручалочку», которая решит все проблемы безопасности, не требуя изменений в процессах разработки и эксплуатации. WAF всегда должен быть последним рубежом защиты, а не единственной линией обороны.
Суть ошибки
Руководство выделяет бюджет на WAF, система устанавливается, но культура разработки не меняется. Разработчики продолжают писать код с уязвимостями, считая, что WAF их всегда прикроет. Безопасники и разработчики не общаются, не обмениваются знаниями, и WAF воспринимается как «чужой» инструмент, за который отвечает только отдел ИБ. Из этого вытекает и отсутствие полноценного цикла DevSecOps: безопасность не встроена в CI/CD, код не проверяется на уязвимости до выкатки в продакшн. В компаниях, пренебрегающих подобными мерами, закономерно отсутствует и соответствующее обучение разработчиков — они не знают, какие атаки WAF блокирует, а какие нет, и продолжают совершать новые ошибки.
Пример ошибки: Исследование Zafran (2024)
В декабре 2024 года исследователи из Zafran обнаружили, что более 140 000 доменов крупнейших компаний мира, включая Visa и Intel, уязвимы для обхода WAF из-за архитектурной ошибки: origin-серверы принимали трафик напрямую из интернета, а не только через CDN и WAF. Эта проблема известна с 2015 года. Были публикации и рекомендации Imperva, но 40 % компаний из Fortune 1000 продолжали её игнорировать. Они формально внедрили WAF, но не изменили процессы: не настроили IP-белые списки, не используют mutual TLS для проверки источника трафика, не проверяют архитектуру своей защиты.
Чем опасна эта ошибка
Технология сама по себе бессильна изменить человеческое поведение. Если разработчики сознательно делают мусорный код и создают уязвимости, надеясь на WAF, рано или поздно защита станет бесполезной. WAF можно обойти множеством способов: через прямые обращения к origin-серверам, через HTTP-запросы с параметрами, через обфускацию и т. д. Без безопасной разработки WAF — это не защита, а открытая дверь. Безопасность, встроенная в процесс разработки, даёт гораздо более надёжный результат, чем формальное наличие WAF.
Выводы
Десять разобранных ошибок объединяет одна общая проблема: отношение к WAF как к чёрному ящику, который достаточно однажды включить, чтобы забыть о безопасности. На практике эффективная защита веб-приложений требует постоянной работы: анализа ложных срабатываний, настройки правил под бизнес-логику, обновления сигнатур, интеграции с процессами мониторинга и реагирования.
WAF не заменяет безопасную разработку и не отменяет необходимость защищать API, мобильные приложения и бэкенд-системы. Это важный, но всего лишь один из слоёв защиты в обороне.
Компании, которые воспринимают WAF как живой, постоянно развивающийся инструмент, интегрируют его в DevOps-процессы, обучают команды и регулярно пересматривают правила, получают реальную защиту от большинства веб-атак. Те, кто относится к WAF формально, рано или поздно столкнутся либо с утечкой данных, либо с заблокированными клиентами, либо с недоступным сайтом в самый неподходящий момент.
