Мы протестировали собственный WAF с помощью передовых моделей ИИ. Вот что мы выяснили29.09.2026 16:00

«Готов ли ваш WAF к передовым моделям ИИ?» Мы постоянно слышим этот вопрос от клиентов и решили это проверить.

Когда речь идёт об эксплуатации приложений, большие языковые модели (LLM) особенно хорошо умеют быстрее любого хакера перебирать и видоизменять полезную нагрузку атак. LLM могут использовать ответы в реальном времени, чтобы менять подход: например, проверять разные варианты кодирования, отправлять полезную нагрузку в другую часть HTTP-запроса или переходить к тестированию следующей уязвимости.

Ещё до появления LLM инженеры по безопасности использовали два распространённых подхода к тестированию приложений: статическое и динамическое тестирование безопасности приложений. Первое анализирует код без его выполнения, чтобы выявить уязвимости, а второе проверяет работающие приложения на наличие ошибок во время выполнения. Существует немало работ по сканированию кода с помощью передовых моделей ИИ, в том числе материалы о том, как создать собственный тестовый стенд.

В описанном в этой статье проекте мы выбрали динамический подход: поручили LLM действовать как хакер и оценить, справляется ли WAF со своей задачей. Модель не видела исходный код и правила WAF, а могла изучать только выбранные данные HTTP-ответов.

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

Мы запустили тестировщик в авторизованной промежуточной среде клиента, проверили шесть категорий атак и зафиксировали 1 107 попыток. После проверки незаблокированных запросов и исключения некорректных, безвредных, дублирующихся и не относящихся к области исследования наблюдений выяснилось, что WAF Cloudflare блокировал подавляющее большинство атак. Запросы, которые прошли, помогли нам создать новые средства обнаружения и усилить защиту для всех клиентов Cloudflare.

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

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

Как работает адаптивный цикл

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

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

Оба вызова модели выполняются без доступа к внутренней информации WAF. Модели не получают выражения правил, идентификаторы правил, сведения об оценке атаки WAF или информацию о том, какой именно уровень защиты сработал. Мы реализовали систему на Python, а не стали оборачивать существующий инструмент для тестирования на проникновение. Она отвечает за повторную отправку HTTP-запросов, управление сценариями, отслеживание состояния и сбор результатов.

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

Система фиксирует структурированные данные о каждой попытке.

Шесть категорий атак против одной конфигурации WAF

Основной запуск проводился в авторизованной промежуточной среде клиента, защищённой WAF Cloudflare. Мы использовали разрешённый тестовый User-Agent, чтобы средства контроля автоматизированного трафика клиента не остановили проверку до того, как запросы достигнут WAF.

Мы запустили 45 сценариев. В каждом из них искали разные способы доставить одну и ту же атаку: изменить кодирование, выбрать другую часть запроса или иначе записать тот же адрес назначения. Из них 44 охватывали шесть категорий атак: межсайтовый скриптинг (XSS), внедрение SQL-кода (SQLi), внедрение команд (CMDi), подделка межсайтовых запросов на стороне сервера (SSRF), обход по пути или включение локального файла (LFI), а также Log4j. В оставшемся сценарии проверялось внедрение в журналы; его результаты приведены отдельно.

В тестовой зоне WAF был настроен следующим образом: блокировка при оценке атаки WAF 30 или ниже, включённый набор управляемых правил Cloudflare и основной набор правил OWASP с уровнем паранойи 3.

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

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

Вот пример того, как LLM адаптирует атаку с подделкой межсайтовых запросов на стороне сервера (SSRF) в ходе тестирования.

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

В этом сценарии SSRF тестировщик отправлял один и тот же адрес метаданных облака в разных форматах — например, в виде целого числа, в восьмеричном представлении и с точкой в конце; во всех случаях речь шла об одном IP-адресе. Кроме того, адрес помещался в разные части запроса. WAF заблокировал все варианты, кроме одного. В попытке 18 модель сохранила структуру запроса из предыдущей заблокированной попытки и использовала адрес с точкой в конце. Вместо блокировки WAF клиент получил перенаправление.

В таблице ниже представлены отдельные моменты этого сеанса. В столбце «Гипотеза» кратко изложено, что, по словам модели, она пыталась проверить перед каждым следующим шагом. Это не дословная расшифровка и не доказательство правильности объяснения.

Попытки 17 и 18 представляют собой интересную пару: структура запроса была одинаковой, различалось только представление хоста. Один запрос был заблокирован, другой — нет. Это позволило сформулировать конкретный вопрос: меняет ли точка в конце то, как WAF интерпретирует адрес назначения? Это стало поводом для проверки, но не доказательством того, что к метаданным получили доступ.

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

Что мы обнаружили

Наш тестировщик выполнил 1 107 попыток, и общий результат оказался высоким: почти все атаки XSS, LFI, SQLi и Log4j были заблокированы. Хотя тестирование принесло полезные результаты, оно также породило много шума. После проверки специалистами мы выделили 49 заслуживающих внимания результатов, 48 из которых относились к CMDi и SSRF. 

Вот как они распределились:

Остальные попытки не дали результата, который стоило бы учитывать: модель не смогла сформировать пригодный HTTP-запрос, некоторые запросы не достигли цели, а часть сгенерированной полезной нагрузки оказалась безвредной.

Прежде чем учитывать незаблокированный запрос как результат, мы задавали пять вопросов:

Мы исключили все случаи, не прошедшие эту проверку, и объединили дубликаты. Оставшиеся результаты стали основой для работы над правилами, нормализацией и мерами защиты.

Результаты проверки превратились в средства обнаружения

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

Мы объединили связанные результаты в четыре набора потенциальных правил, проверили каждый из них и протестировали кандидатов на реальном трафике — прежде чем какое-либо правило стало защищать трафик клиентов.

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

Эта работа способствовала трём изменениям в наборе управляемых правил Cloudflare: в выпуске от 21 июля появились новые средства обнаружения SSRF — скрытый хост и SSRF — ограниченный протокол, а существующее правило SSRF — облако было улучшено. Средство обнаружения SSRF — скрытый хост появилось непосредственно благодаря запросам, в которых внутренние адреса были закодированы нестандартными числовыми способами.

Что мы узнали

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

Увеличение числа попыток в одном сценарии не всегда помогало обнаружить больше проблем. В некоторых сценариях ближе к концу лимита в 25 попыток модель начинала повторять прежние идеи. Мы добились более широкого охвата, проверяя больше исходных запросов, категорий атак и мест размещения входных данных, а не удлиняя одну последовательность.

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

Что клиенты могут сделать уже сейчас

WAF — лишь один из уровней защиты, которые можно развернуть. Использование всех доступных средств защиты повышает эффективность всей системы безопасности. 

Прежде всего убедитесь, что перед приложением правильно настроены управляемые правила и оценка атаки WAF. Дополнительно можно использовать средства защиты API, обнаружения ботов и мошенничества, а также анализа угроз, чтобы ещё больше усилить защиту. Например, положительные средства контроля безопасности добавляют ещё один уровень защиты: вместо поиска только известных шаблонов атак они определяют ожидаемые приложением форматы запросов и выявляют входные данные, не соответствующие этим требованиям. Это существенно сокращает поверхность атаки. 

Многоуровневая защита сочетает средства с разными функциями.

Клиентам не нужно повторять этот эксперимент. Чтобы развернуть перед приложением как можно больше правил, мы рекомендуем сначала включить управляемые правила в режиме журналирования, проверить соответствующие запросы в разделе «События безопасности» и убедиться, что легитимный трафик не затронут, прежде чем переводить правило в режим блокировки. Другой вариант — обратиться к своей команде по работе с клиентами и попросить включить в зонах функцию обнаружения сигнатур атак. Эта новая функция упрощает анализ трафика, соответствующего правилам, и развертывание средств обнаружения по сигнатурам. Если вы уже проводите тестирование безопасности приложений, выполняйте его на промежуточном хосте, защищённом теми же средствами Cloudflare, что и рабочая среда.

Что дальше

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

© Cloudflare Blog