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

f062a9f2c2120783d7fcf49823a50a12.png

Утилиты для синтетического тестирования чего-либо всегда пользовались популярностью. В памяти сразу всплывают 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.

Плюсы

Минусы

База тестов пополняется вместе с развитием ModSecurity CRS

Нет генерации отчетов «из коробки»
Результаты записываются в SQLite базу regression.db, а для получения отчета придется написать несколько запросов для выборки данных

Тестов много, есть false-positive

Нет динамического кодирования payload
Что написано в то и отправлено

Запросы отправляются заголовками
HOST: localhost
User-Agent: ModSecurity CRS 3 Tests
Если это нужно изменить — придется редактировать множество yaml файлов с тестами и пересобирать контейнер
(В данном случае файлы находятся в util/regression-test/crs-v3.1/black-box/)

По умолчанию подгружаются все тесты, включая специфические из наборов «REQUEST-911-METHOD-ENFORCEMENT» и аналогичных. Это ориентировано на сам ModSecurity CRS, использовать для тестирования сторонних WAF смысла не вижу

Если нужно добавить свои тесты, то придется создать каталог в 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

Payload записаны в разных кодировках — plaintext, URL encode, double URL encode, частичный URL encode. Из-за этого неудобно искать нужный payload при отладке или при вдумчивом тестировании. Проще для восприятия когда все записывается в едином стиле, например, plaintext и кодируется динамически

Тестов много, покрыты различные типы атак

Тесты с multipart описаны странно. Для части из них указан boundary, у остальных — нет. Логично чтобы boundary формировался сам. Но тут может я просто что-то не понял)

Есть false-positive тесты

При указании «ENCODE»: «Base64 UTF-16», отправляются еще и plain text запросы, что не вполне очевидно

Выдает отчет о тестировании

Поддерживает динамическое кодирование payload в Base64 и UTF-16

Можно указать отличный от 403 код блокировки

Есть возможность добавлять свои заголовки в запросы

Есть многопоточность

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

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

a450781ec07a6e91acc229d503768324.png

Выводы

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

3. GoTestWAF

https://github.com/wallarm/gotestwaf

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

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

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

Плюсы

Минусы

Простой запуск в docker

Обладает самым богатым набором payload для тестирования. Множество своих + скрипты для конвертация CRS и WAF-Bypass тестов

Есть false-positive тесты, много

Выдает детальный отчет о тестировании (консоль, PDF и CSV)

Поддерживает динамическое кодирование payload

Легко добавить свои тесты. Формат YAML

Поддерживает WebSocket, gRPC

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

Может делать вывод о блокировке запроса путем анализа тела ответа. Пригодится, если 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

25c2e89a48d2bf88ef650b5d8c1ba928.pngcba3e2eb6eb67d715e737b484980ac55.png9b91414ec4c20df8527ec5150a78f785.png

Выводы

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

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

FTW-compatible-tool

WAF-Bypass

GoTestWAF

Наличие Docker образа

Да

Да

Да

Количество тестов атак*

2009**

2169***

6063

3183 (базовый набор)

7990 (с подключением тестов ModSecurity CRS и WAF-Bypass)

Количество тестов false-positive*

84**

227***

19

999 (базовый набор)

2184 (с подключением тестов ModSecurity CRS и WAF-Bypass)

В активной разработке?

Да

Да

Да

Вывод результатов

В SQLite базу

Текстовый отчет в консоль, можно включить вывод детального отчета

Текстовый отчет в консоль

Детальный PDF отчет

CSV

Поддержка протоколов

HTTP

HTTP

HTTP

Websockets

gRPC

Возможность написания своих тестов

Есть

Есть

Есть

Тесты для типов атак

LFI, RFI, RCE, XSS

SQLI

GraphQL, LDAP, LFI, NoSQLi, OpenRedirect, RCE, RFI, SQLi, SSI, SSRF, SSTI, XSS

SQLi, RCE, XSS, PTRAV, RFI, LFI, XXE, LDAPi, mail-injection, NoSQLi, SSI, SSTI, GraphQL, SSRF, OpenRedirect

Динамическое кодирование payload

Нет

BASE64, UTF-16

URL, JSUnicode, BASE64, XML Entity

Места вставки payload в запрос

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

URL

Args

Body

Cookie

User-Agent

Referrer

Header

MultipartForm

JSON

gRPC

Header

UserAgent

RequestBody

JSONRequest

JSONBody

HTMLForm

HTMLMultipartForm

SOAPBody

XMLBody

URLParam

URLPath

NonCrudUrlPath

NonCrudUrlParam

NonCRUDHeader

NonCRUDRequestBody

Многопоточность

Нет

Да

Да

Работа через прокси

Из коробки нет

Да

Да

Задание произвольного User-Agent

Требуется редактирование всей базы тестов

Да

Да

Добавление своих HTTP заголовков

Требуется редактирование всей базы тестов

Да

Да

Указание кода блокировки WAF, если не 403

Требуется редактирование всей базы тестов

Да

Да

Вывод о блокировке запроса путем анализа тела ответа

Нет

Нет

Да

Поддержка сессий (Cookie)

Нет

Нет

Да

Тестирование с использованием OpenAPI спецификации

Нет

Нет

Да

* количество тестов может меняться в зависимости от версии утилит. Дано для общего представления
** тесты из набора 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