Cloudflare протестировала принадлежащий ей межсетевой экран веб-приложений (WAF) с помощью передовых моделей искусственного интеллекта, способных изменять атакующие запросы после каждой попытки, вместо использования исключительно фиксированного набора тестов. Компания провела эксперимент в отдельной staging-среде клиента с его предварительного согласия и зафиксировала 1 107 попыток в рамках 45 сценариев.
Основная идея заключалась в имитации части поведения злоумышленника, который может пробовать различные кодировки, переносить полезную нагрузку в другие места внутри HTTP-запроса или изменять способ представления назначения, а затем использовать ответ для выбора следующей попытки. Модель не получала исходный код приложения, внутренние правила WAF или номера правил, а работала только с контекстом запроса и определёнными данными HTTP-ответа.
Как работало адаптивное тестирование?
Каждый сценарий начинался с запроса, который, как было известно, блокируется WAF, после чего модель предлагала новое изменение. После отправки запроса другая модель или отдельный вызов для проверки анализировали ответ, прежде чем система определяла следующий шаг в пределах максимального числа попыток. Код выполнял запросы и регистрировал свидетельства, а перед каждой попыткой система также проверяла имя домена по списку разрешённых, отключала перенаправления и не позволяла изменять или публиковать правила защиты.
44 сценария охватывали шесть категорий: межсайтовый скриптинг (XSS), SQL-инъекции, инъекции команд, подделку запросов на стороне сервера (SSRF), обход путей или включение локальных файлов (LFI), а также атаки Log4j. Сорок пятый сценарий отдельно рассматривал инъекции в журналы.
От 1 107 попыток к 49 результатам, требующим расследования
В целом WAF показал высокую эффективность, обеспечив почти полное покрытие категорий XSS, LFI, SQLi и Log4j. После проверки людьми осталось 49 результатов, заслуживающих расследования; 48 из них относились к категориям инъекций команд и SSRF. Число заблокированных запросов составило 558, тогда как другие попытки были исключены, поскольку являлись недействительными, безвредными, повторными или не достигли цели.
Cloudflare не считала незаблокированный запрос подтверждённой уязвимостью. Требовалось, чтобы запрос был действительным и достиг цели, оставался явно вредоносным, поведение было связано с WAF, а инженеры могли безопасно воспроизвести его. Это различие важно, поскольку одного обхода WAF недостаточно, чтобы доказать успешную эксплуатацию приложения или доступ к конфиденциальным данным.
Пример пробела в обнаружении SSRF
В одном из сценариев система изменила способ записи адреса службы облачных метаданных, использовала различные числовые представления и размещала адрес в нескольких частях запроса. Большинство попыток было заблокировано, однако одна попытка с представлением с завершающей точкой привела к перенаправлению вместо блокировки WAF. Cloudflare сочла это сигналом, заслуживающим расследования, а не доказательством доступа к учётным данным или успешной эксплуатации.
Что изменилось на практике?
Cloudflare проанализировала результаты, чтобы определить, требуется ли новое правило, улучшение нормализации запросов или вмешательство другого уровня безопасности. Результаты привели к трём изменениям в Managed Ruleset: добавлению обнаружений SSRF - Obfuscated Host и SSRF - Restricted Protocol в выпуске от 21 июля, а также улучшению обнаружения SSRF - Cloud. Обнаружение замаскированного хоста напрямую возникло из запросов, в которых использовались необычные числовые форматы внутренних адресов.
Эксперимент показывает, что искусственный интеллект здесь является инструментом расширения пространства тестирования, а не заменой инженерной оценки. Две модели из одного семейства создавали разные варианты, однако основные проблемы проявлялись у обеих. Кроме того, увеличение числа попыток в рамках одного сценария не гарантировало обнаружения дополнительных результатов: некоторые цепочки начинали повторять идеи, тогда как увеличение числа исходных точек, категорий атак и мест ввода обеспечивало более широкий охват.
Ограничения WAF сохраняются: полезная нагрузка, обошедшая защиту, приводит к успеху только в том случае, если само приложение уязвимо для эксплуатации, поэтому обновление программного обеспечения и исправление уязвимостей по-прежнему необходимы. Cloudflare также рекомендует сначала включать правила в режиме регистрации, анализировать соответствующие запросы и события безопасности, а затем переходить к блокировке после проверки того, что легитимный трафик не затронут. В дальнейшем компания планирует провести white-box-тестирование, при котором модели будут известны и уязвимости приложения, и правила WAF.