Сколько попугаев выдает ваш WAF? Обзор утилит для тестирования26.10.2023 11:15

Утилиты для синтетического тестирования чего-либо всегда пользовались популярностью. В памяти сразу всплывают Antutu, CPU-Z, 3DMark… А есть ли что-то подобное, но для тестирования WAF?

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

Что будем измерять?

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

• Качество обнаружения атак.

А зачем?

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

Можно запустить ПО для тестирования WAF и получить точную оценку, больше ничего делать не нужно?

Нет. Тестирование подобными утилитами может быть только одним из множества шагов. Кстати, в прошлой статье я чуть подробнее описывал методики тестирования WAF и инструменты для этого.

Покрытие

ПО из данного обзора способно покрыть только риски по следующим уровням OWASP Top 10 / API top 10:

• А03 / API3 — Injection (SQLi, RCE, NoSQLi, SSTI, etc)

• A05 — Security Misconfiguration (XXE)

• A08 — Software and Data Integrity Failures (Insecure Deserialization)

• A10 / API7 — Server-Side Request Forgery (SSRF)

• API5 — Broken Function Level Authorization

• API10 — Unsafe Consumption of APIs (Injection Flaws, SSI, XSS)

Почему так? Все просто — для тестирования реакции WAF достаточно отправить одиночный запрос. Запрос заблокирован — плюс в карму WAF, нет — минус.

Такой вид проверок универсален и не требует подстройки под специфику тестируемого WAF.

Что представляет из себя ПО для тестирования WAF?

Можно условно разделить такое ПО на две составляющие.

Первая — набор тестовых данных, содержащих разнообразные атаки на веб-приложения и строки, которые могут быть расценены атаками по ошибке (false-positive тесты).

Вторая — программа для кодирования и отправки тестовых данных. Она же контролирует реакцию тестируемого приложения и формирует отчет.

Просто? Конечно. Но дьявол в деталях. Разного рода скриптов для решения этой задачи очень много, а вот более-менее полноценные решения можно пересчитать по пальцам одной руки.

В этот обзор попало лишь три утилиты: FTW-compatible tool, waf-bypass и GoTestWAF, потому как остальное что я видел либо давным-давно не обновляется, либо содержит очень мало тестовых данных. Буду рад если уважаемый читатель дополнит сей перечень, вдруг я что-то упустил.

Пожелания к инструменту для тестирования.

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

• Простота запуска. Желательно docker, никаких заморочек с установкой ПО и скачиванием дополнительных компонентов.

• Большой набор тестовых данных по каждому типу атак. Включая: SQLi, XSS, RCE, PTRAV, LFI, RFI, Insecure Deserialization, NoSQLi, LDAPi, GraphQLi, SSRF, Parameter Pollution, XXE, SSI, SSTI, etc. Многое из этого списка находится или находилось в OWASP Top 10 / API Top 10. Не все WAF имеют одинаковое покрытие по вышеперечисленным атакам.

• Наличие false-positive тестов. Обязательно. Без этого не получить объективной картины. WAF со слишком «параноидальными» сигнатурами на первый взгляд будет выглядеть хорошо, но на деле им будет невозможно пользоваться из-за множества ложно-положительных срабатываний.

• Богатые возможности по кодированию payload. URL encode, Unicode, gzip, Base64, etc. Веб-приложения эти кодировки используют и если WAF недостаточно хорошо их разбирает (в том числе в цепочках), то возможен обход.

• Возможность вставлять payload в различные части запроса. В URI, параметры GET, заголовки, тело. Разнообразие типов содержимого (multipart, json, form-urlencoded, xml, etc) тоже важно.

• Поддержка современных протоколов.  gRPC, Websockets уже давно не экзотика. А насколько хорошо с ними работает WAF?

• Скорость работы. Хочется поддержки keepalive, многопоточности, http/2.

• Понятный и информативный отчет.

• Детальная статистика о прохождении тестирования. Какие запросы прошли, какие заблокированы, что ответило приложение? Это может пригодиться для разбора полетов. Бывает, что WAF не настроили и нужно что-то подкрутить дополнительно. Или разобраться в результатах тестирования досконально.

• Актуальность. Инструмент должен развиваться и регулярно пополнять базу тестов.

• Открытость. Открытый исходный код и база тестов крайне важны, процесс тестирования должен быть прозрачен и понятен.

• Удобный способ добавления новых payload.

• Возможность подстройки под тестируемое приложение. Нужна возможность указания кода блокировки, определение блокировки на основе содержимого ответа. Не всегда тестируемый WAF вернет 403 Forbidden, иногда может быть выдана страница блокировки (код ответа 200, содержимое произвольное).

Обзор инструментов

1. Решения на базе регрессионных тестов ModSecurity Core Rule Set (CRS)

Таких решений несколько, их объединяет набор тестовых данных из регрессионных тестов ModSecurity.

Тестовые данные разделены по типам правил ModSecurity и представляют из себя файлы в yaml формате, где описаны запросы и ожидаемая реакция WAF (наличие определенной записи в log файле ModSecurity, код ответа)

В первую очередь эти тесты заточены под основанные на ModSecurity CRS решения, а набор payload ограничен текущими возможностями обнаружения атак самим CRS. Но ничто не мешает использовать эти данные для тестирования любого другого WAF.

Тестов достаточно много, покрыты различные типы атак и false-positive.

Тесты написаны разными людьми и нет единой стилистики в оформления, именования и описания. Из-за этого не всегда удобно в них разбираться. Например, в описании может быть указано false-positive, true-positive, false-negative, true-negative, FP, not FP и так далее, еще поди пойми что имеется ввиду)

Есть очень специфичные именно для ModSecurity тесты, например:

• отправка запросов без атак, но используя HTTP метод «TEST»

• отправка запроса без атак, но с заголовком «Cache-Control»

Написать свои тесты можно, по аналогии с остальными.

Теперь давайте рассмотрим несколько решений, использующих эти наборы тестов.

WAFBench от Microsoft

Проект предоставляет несколько утилит:

• WAFBench (wb) — утилита для тестирования производительности

• Python WAF Bench (pywb) — расширенная версия wb. Функциональный аналог WAFBench.

• FTW-compatible Tool — позволяет производить тестирование WAF данными из набора OWASP Core Rule Set regression testing suite.

Первые две утилиты нас пока не интересуют, речь пойдет про FTW-compatible Tool

Утилита может работать в 2х режимах:

• black-box (можно тестировать любой WAF, выводы делаются на основании кода ответа сервера, ожидаемый код должен быть прописан в тесте)

• white-box (требуется подключить логи ModSecurity для анализа)

Пример сборки и запуска black-box тестирования

git clone https://github.com/microsoft/WAFBench.git
docker build -t wafbench WAFBench

docker run -it --rm \
  -v `pwd`:/data \
  wafbench \
  ftw_compatible_tool -d /data/regression.db -x "load util/regression-test/crs-v3.1/black-box/ | gen | start host:port | report | exit"

Обратите внимание, что нужно указать свои host и port.

Если нужно добавить свои тесты, то придется создать каталог в WAFBench/util/regression-test, сложить в него нужные вам тесты, пересобрать контейнер и указать этот каталог при запуске.

И еще. У меня не получилось подключить тесты из текущей версии CRS — v4.0, После запуска ftw_compatible_tool контейнер упал с ошибкой `KeyError: 'description'` на этапе load. При этом коробочные версии 3.1. и 3.2. работают.

Framework for Testing WAFs (FTW) утилиты

Еще несколько аналогичных утилит:

https://github.com/fastly/ftw — не развивается, последний коммит в апреле 2019
https://github.com/coreruleset/ftw — устарела, ей на смену пришла go-ftw
https://github.com/coreruleset/go-ftw — заточена на тестирование ModSecurity, требует подключение логов. Приспосабливать под тестирование сторонних WAF смысла нет.

Выводы

Из этого семейства я бы выбирал FTW-compatible Tool, но назвать этот инструмент идеальным язык не поворачивается.

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

2. Waf-Bypass

Инструмент для тестирования WAF без привязки к вендору, написан на python.
На момент написания статьи имеет 6069 тестовых запросов.
Тестовые данные хранятся в JSON, при желании легко дополнить.
В использовании гораздо удобнее FTW решений.

Пример запуска

docker pull nemesida/waf-bypass
docker run nemesida/waf-bypass --host='172.17.0.1:8080'

Выводы

Вполне годный инструмент, подходит.

3. GoTestWAF

https://github.com/wallarm/gotestwaf

https://wmx-public.gitlab.yandexcloud.net/wmx-public/gotestwaf (fork)

Инструмент для тестирования WAF, нет привязки к вендору, написан на Go.

Форк от Вебмониторэкс содержит скрипты для конвертации тестов из FTW и WAF-Bypass.

И еще несколько особенностей:

Может делать вывод о блокировке запроса путем анализа тела ответа. Пригодится, если WAF выдает страницу блокировки с кодом ответа 200.

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

Поддерживает тестирование на основе OpenAPI спецификации. Поможет тестировать WAF, использующий позитивную модель (блокировка запросов, выходящих за рамки OpenAPI спецификации)

Имеет массу параметров запуска для подстройки под тестируемый WAF.

Возможно выглядит как реклама, тем более что автор статьи имел честь внести небольшой вклад в развитие этой утилиты, но так уж вышло, пытался быть объективным, правда)

Пример запуска

docker run --rm -v ${PWD}/reports:/app/reports gotestwaf --url=http://172.17.0.1:8080/ --workers 20

Выводы

Самый, не побоюсь этого слова, продвинутый инструмент для тестирования WAF на данный момент.

Сравнительная таблица по утилитам для тестирования WAF

* количество тестов может меняться в зависимости от версии утилит. Дано для общего представления
** тесты из набора crs-v3.3 за исключением REQUEST-911-METHOD-ENFORCEMENT, REQUEST-920-PROTOCOL-ENFORCEMENT, REQUEST-921-PROTOCOL-ATTACK, REQUEST-943-APPLICATION-ATTACK-SESSION-FIXATION
*** crs-v3.3 полный набор тестов

Заключение

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

Не обязательно выбирать что-то одно, вы можете использовать их все! Аж все три))

Также вы можете дополнять тесты из коробки собственными, благо делается это без особых проблем.

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

© Habrahabr.ru