Как кастомные правила в WAF помогают более эффективно защищать веб-приложения

Всем привет! На связи Титов Антон, ведущий эксперт компании Angara Security по направлению защиты веба.

Зачем нужен WAF

WAF (Web Application Firewall) — сервис защиты веб-приложений от хакерских атак и угроз в интернете на прикладном уровне. Он отслеживает и проверяет весь входящий и исходящий трафик преимущественно по протоколам HTTP/HTTPS, блокируя подозрительные запросы ещё до того, как они доберутся до приложения.

По данным Red Team Angara Security, в более 50% случаев первичное проникновение во внутреннюю сеть организаций происходило через уязвимости публично доступных веб-приложений. Согласно исследованию Positive Research от 2025, в 44% случаев точкой входа в инфраструктуру были уязвимые веб-приложения, похожие цифры дает и Лаборатория Касперского» (39%). По данным исследований Angara MTDR, первоначальный доступ в каждую шестую организацию был связан с эксплуатациями уязвимостей на публично-доступных серверах, причем злоумышленники преимущественно используют «проверенные временем» бреши.

Таким образом, можно сделать вывод, насколько важно иметь защиту своих веб-ресурсов в лице WAF. Однако…

Проблема внедрения и использования WAF

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

Как заказчик видит свежекупленный WAF

Политики безопасности – вот то, что вас защищает.  С точки зрения WAF, политика безопасности – набор правил, определяющих прохождение трафика. Качественная настройка политик безопасности – залог безопасности веб-приложения. Как показывает опыт проведения проектов сотрудниками Angara Security, в более чем 50% случаев заказчики планируют внедрение решения с использованием ТОЛЬКО базовых политик безопасности, без дополнительной настройки.

К чему это приводит?

• Перерасход ресурсов на неприменимые уязвимости. Представьте вы пытаетесь поймать SQL-инъекцию в приложении, где нет подключения к базам данных (Это только пример, почти все веб-приложения так или иначе связаны с базами данных);

• Незащищенные бизнес-процессы. Перебор паролей, скрейпинг, абьюз бонусных программ, или ещё хуже IDOR – всё это, может привести как к репутационным, так и к финансовым потерям. (Это база базовая. Изначально, WAF предлагает сигнатурный* анализ для отлова пейлоадов, но как быть с запросами по составу ничем не отличающимся от легитимных?);

• Некоторые применимые уязвимости (0-day, n-day) остаются не закрытыми. Такие правила обычно пишутся вручную и не закрываются базовыми политиками.

• Настройка WAF – трудоемкий и трудозатратный процесс, который требует высокой квалификации специалистов: на создание кастомного правила средней сложности у эксперта уходит порядка двух часов, на сложное правило, включающее много сигнатур и требований со стороны заказчика, – до 12 часов;
• Компании сталкиваются с отсутствием квалифицированных кадров. Как следствие, работающие в компании специалисты не всегда могут выполнить дополнительный процесс настройки.
• Страх положить всю инфраструктуру компании;

• Надежда на то, что базовых правил WAF хватит для надежной защиты приложений.

Без адаптации под ваш бизнес все средства защиты превращаются в это.

Реальный кейс 1

Чтобы перейти от теории к практике, приведу пример крупного Fintech-заказчика, которому потребовалось реализовать кросс-доменное взаимодействие между приложением и API. В процессе реализации клиент столкнулся с SOP (Same-Origin Policy) – встроенным в браузер «ограничителем», который запрещает сложное кросс-доменное взаимодействие и отправку запроса. В таком случае необходимо настраивать политики безопасности, однако ИТ-департамент организации не был знаком с вопросом и построил CORS (Cross Origin Resource Sharing) – механизм обхода ограничений, накладываемых SOP. Во время пентеста такой системы произошла утечка данных через API. В реальной ситуации атаку можно было бы развивать дальше.

Как можно избежать печальных последствий? С учетом специфики CORS, в рассматриваемом нами случае было необходимо:

1. Проверить Origin;

2. Разрешить доступ к желаемому Origin;

3. Разрешить определенные методы;

4. Разрешить определенные заголовки;

5. Разрешить передачу Cookie на желаемый Origin;

6. Установить время разрешения;

7. Указать для кэша, что именно может меняться в структуре заголовка.

Пример реализации кастомного правила на одном из популярных WAF приведен ниже: мы создаем действие «Отправлять свой ответ» и создаем правило, которое выявляет preflight-запрос и выполняет указанное действие.

Пример реализации CORS. Часть 1.

Пример реализации CORS. Часть 2.

Таким образом, мы разрешаем браузеру отправлять кросс-доменные запросы и контролируем, что именно может быть отправлено, и все процессы в данном случае находятся в ведении ИБ-подразделения.

Реальный кейс 2

Другой пример уже у других заказчиков – Content Security Policy (CSP-политика). Она дает нам:

1. Предотвращение пропущенных XSS-атак;
2. Предотвращение Clickjacking;
3. Предотвращение WebShell и другого пропущенного вредоносного контента.

Почему это может быть важным? Не все сигнатуры* могут быть найдены, поэтому дополнительный уровень CSP позволяет более полно защитить веб-приложение. (про сигнатуры поговорим позже).

Пример возможной реализации CSP на одном популяром WAF.

А что, если сами нашли уязвимость?

Прекрасно. Как раз это и является самой главной ценностью – возможность описания собственных уязвимостей при помощи пользовательских правил. Или в простонародье «Виртуальные патчи».

Найденная уязвимость в некотором SASTI.

Ручная реализация «Виртуального патча» для найденной в SAST уязвимости.

Ну а всё же, что нужно делать?

1. Для создания кастомных правил требуется: анализ кодовой базы;
2. Выявление уязвимых бизнес-процессов (пентест);
3. Просмотр логов веб-приложений и установление взаимосвязей;
4. Создание кастомных правил;
5. Создание корреляций и агрегаций;
6. Проведение тестирования «черным ящиком» до и после изменений.

Можно ли упростить задачу? Да, но только в том случае, если у компании уже есть наработки в виде политик и ретроспективных данных.

Бытует мнение, что существуют бессигнатурные WAF. Но, честно говоря, на мой взгляд, это всего лишь маркетинговый ход, который вводит в заблуждение конечных пользователей о ненадобности настройки политик безопасности. Я могу объяснить свою позицию двумя тезисами:

1. Если WAF бессигнатурный, с какой-то мегахитрой базой знаний, машинным обучением и прочими наворотами, которому не требуется никакого постороннего вмешательства, то какой смысл в кнопочке «Создать правило»? :-)

2. Если абстрагироваться и пофилософствовать, то давайте подумаем, как определить вредоносный запрос. Проанализировать? А это как? Регулярка? Ифчик? Даже в машинном обучении у нас есть ифчики. То есть, существует какой-то «вопрос» (легитимный ли запрос) или даже набор «вопросов», что в свою очередь и является в том или ином виде «СИГНАТУРОЙ».

На этом всё. Надеюсь, теперь стало немного понятнее, для чего нам WAF и что делать, чтобы эффективнее его использовать.

Источник