Использование WAF для защиты веб-приложений и API уже давно стало необходимостью. И дело тут не только в требованиях регуляторов (152-ФЗ и 187-ФЗ, PCI DSS), но и в здравом смысле, стоит хотя бы посмотреть на количество взломов и утечек за последнее время. На рынке WAF много решений, но как их сравнить, как выбрать лучшее, как проверить качество парсинга данных и обнаружения атак?

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

Что будем тестировать?

• Что будем тестировать?

• Инструментарий для тестирования WAF

  • сURL

  • Специализированный софт для тестирования WAF

  • Общие рекомендации по тестированию WAF

• Заключение

СПРАВКА
Стандарты безопасности, требующие наличие WAF:

• Payment Card Industry Data Security Standard (PCI DSS).

• HIPAA (Health Insurance Portability and Accountability Act) - стандарт безопасности в здравоохранении США, который устанавливает требования к защите медицинских данных. WAF рекомендуется для обеспечения конфиденциальности и целостности данных пациентов.

• GDPR (General Data Protection Regulation) - регламент Европейского Союза, устанавливающий требования к защите персональных данных граждан ЕС. WAF может помочь в предотвращении утечки и несанкционированного доступа к персональным данным.

• FFIEC (Federal Financial Institutions Examination Council) - в США FFIEC устанавливает требования к информационной безопасности для финансовых учреждений. WAF рекомендуется в качестве одного из мероприятий для защиты онлайн-банкинга и финансовых приложений.

• 152-ФЗ и 187-ФЗ отсылают к соответствующим описаниям мер в Приказах ФСТЭК № 21 и 239 соответственно. Часть таких мер (которые очень схожи, если не одинаковы) можно реализовать классом решений WAF. К примеру - это может быть маскирование данных при передаче или обнаружение фактов несанкционированного доступа к защищаемой системе.

На какие аспекты обратить внимание при сравнении нескольких WAF? Достаточно много информации по этой теме можно почерпнуть в проекте OWASP Web Application Firewall Evaluation Criteria Project (WAFEC).

На данный момент актуальной является первая версия документа.

Вторая версия находится в разработке, вот ссылка на черновик.

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

Перед тем как двигаться дальше, необходимо затронуть классификацию рисков безопасности по OWASP Top 10 и OWASP API Top 10 (на данный момент актуальны Top 10 2021г и API Top 10 2023г). От современных WAF требуют максимального покрытия по OWASP, с этим трудно не согласиться, но утилит, которые могут протестировать защиту по всем рискам из OWASP, нет.

Риски OWASP Top 10 и OWASP API Top 10 можно условно разделить на два блока:

• Инъекции и несколько других типов атак, связанных с модификацией данных в запросе (SSRF, XXE, etc).

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

Блок - 1

• А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)

Блок - 2

• A01 / API1 - Bola

• A02 - Cryptographic Failures

• A04 - Insecure Design

• A06 - Vulnerable and Outdated Components

• A07 - Identification and Authentication Failures

• A09 - Security Logging and Monitoring Failures

• API2 - Broken Authentication (Brute, Credential Stuffing, Weak JWT)

• API4 - Unrestricted Resource Consumption (Maximum upload file size, Execution timeouts)

• API6 - Unrestricted Access to Sensitive Business Flows

• API8 - Security Misconfiguration (CORS, Latest security patches missing)

• API9 - Improper Inventory Management

Для проведения полноценного тестирования сценариев из второго блока требуется реализовать специальный демо-стенд (или даже несколько), настроить и отладить соответствующие модули защиты WAF, составить цепочки запросов. 

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

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

Инструментарий для тестирования WAF

Попробую описать несколько типичных подходов к тестированию и выбору инструментов.

сURL

сURL — утилита командной строки для взаимодействия с разнообразными серверами, включая HTTP(s). Является стандартным средством для отправки HTTP запросов. Практически ни одно тестирование WAF не обходится без этой утилиты.

Для тестирования основной функциональности WAF - обнаружения атак - можно придумать некоторое количество сценариев с атаками разных типов, для примера:

curl 'http://example.com/?q="><script>alert()</script>'
curl "http://example.com/?q=';WAITFOR%20DELAY%20'0:0:30%27--%22/"
curl "http://example.com/../../../../../../../../../../etc/shadow/"
etc

При разработке методики тестирования нужно обязательно подумать про кодирование данных. Веб серверы, фреймворки, библиотеки, прочие компоненты, из которых строятся веб-приложения, могут работать с данными в разных кодировках (URL encoding, Base64, gzip, Unicode, double URL encoding), что может быть не вполне очевидно для разработчиков конечного приложения и WAF. Если WAF не обладает достаточными возможностями по декодированию и парсингу данных, то у злоумышленника появляется шанс на обход.

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

Инструменты для автоматического поиска уязвимостей в веб-приложениях.

Еще один очевидный вариант тестирования WAF – проверить реакцию на запросы от инструментов для аудита ИБ, например:

• SQLMap — инструмент для обнаружения и эксплуатации SQL инъекций

• Nuclei — сканер уязвимостей

• Nikto — сканер уязвимостей для веб приложений

• BurpSuite vulnerability scanner — сканер уязвимостей, встроенный в утилиту по тестированию веб-приложений BurpSuite

Критерием качества работы WAF будет количество заблокированных запросов. Из неудобств отмечу необходимость как-то контролировать сколько запросов было заблокировано, а сколько прошло. Для этого потребуется анализировать логи WAF \ бекэнда или иным образом следить за реакцией WAF. Лично мне в таких случаях нравится проксировать трафик через BurpSuite, все запросы как на ладони, с ними удобно работать, фильтровать, сортировать, отправлять повторно при необходимости.

Кстати, некоторые утилиты из коробки обладают функциональностью для обхода WAF, например у SQLMap есть солидный набор tamper scripts. Рекомендую тестировать  несколько таких сценариев.

Как всегда есть нюансы.

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

Второй. Отсутствие false-positive тестов, т.е. используя только этот класс утилит нельзя составить более-менее объективную картину качества работы WAF. Темы false-positive я еще коснусь чуть ниже.

Я бы рекомендовал использовать эти инструменты в дополнение к другим методам тестирования.

Внимание! Если вы проводите тестирование WAF этими или подобными инструментами убедитесь что блокировка запроса происходит на основе обнаружения атаки, а не из-за содержимого заголовка User-Agent. По умолчанию вышеупомянутые утилиты добавляют свой User-Agent, на что во многих WAF есть соответствующие сигнатуры. Если такое происходит — используйте стандартный User-Agent браузера, обычно это легко делается через аргументы командной строки. Для справки можете использовать ресурс https://developers.whatismybrowser.com/

PayloadsAllTheThings, SecLists, etc

На github есть несколько репозиториев, где комьюнити собирает информацию об атаках, payload, методах обфускации и прочую важную информацию. Наиболее известные из них:

• https://github.com/swisskyrepo/PayloadsAllTheThings

• https://github.com/danielmiessler/SecLists

Логично сформировать набор payload по данным из этих репозиториев и прогнать через BurpSuite intruder или самописный скрипт.

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

Пример однотипных payload *(найдите 5 отличий :))

,NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/*
,NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20--
',NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/*
',NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20--
",NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20/*
",NULL,NULL,NULL,NULL,NULL,NULL,NULL)%20waitfor%20delay%20'0:0:20'%20--
ORDER BY 1 
ORDER BY 2 
...
ORDER BY 31337

Примеры комментариев:

# ms-sqli info disclosure payload fuzzfile
# replace regex with your fuzzer for best results <attackerip> <sharename>
# run wireshark or tcpdump, look for incoming smb or icmp packets from victim
# might need to terminate payloads with ;--
# you will need to customize/modify some of the vaules in the queries for best effect
# mysql local file disclosure through sqli
# fuzz interesting absolute filepath/filename into <filepath>
# regex replace as many as you can with your fuzzer for best results:
# <user-fieldname> <pass-fieldname> <username>

Пример не полных payload:

'
''
`
``
,
"
""
/
\
;
'='

Репозитории, подобные "PayloadsAllTheThings" и "SecLists" крайне полезны, поскольку содержат массу информации по основным payload для эксплуатации уязвимостей разных типов, варианты по обходу WAF. Активно обновляются сообществом (спасибо, друзья!).

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

Из минусов можно отметить отсутствие false-positive данных для написания тестов.

Рекомендую к ознакомлению.

Специализированный софт для тестирования WAF

Существуют готовые инструменты для проведения тестирования WAF, вот их некоторые особенности:

• Обширный (тысячи) набор разнообразных тестовых атак.

• Наличие false-positive тестов.

• Отправка запросов в разных кодировках и форматах (Base64, URL encoding, JSON, etc).

• Использование различных HTTP методов,

• Несколько вариантов Content-Type.

• Вставка payload в произвольные места запроса (query params, URI, body, headers, json, etc).

• Формирование отчетов.

Как правило, разработчики регулярно добавляют новые payload и false-positive тесты, в некоторых случаях в этом участвует еще и комьюнити.

Вот список достойных упоминания инструментов:

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

  •  WAFBench FTW compatible tool от Microsoft

  •  Framework for Testing WAFs (FTW)

• WAF Bypass Tool

• GoTestWAF от Wallarm

• GoTestWAF форк от Вебмониторэкс

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

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

Добавить свои тесты в большинстве случаев легко, т.к. по сути эти решения представляют собой средство для автоматизации кодирования исходных данных, отправки запросов и генерации отчетов. Данные для тестов (атаки и false-positive) открыты, а работа самих инструментов прозрачна.

Использование готовых утилит вполне удобно, особенно когда тестирование надо провести быстро. Запустил и практически сразу получил отчет.

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

Общие рекомендации по тестированию WAF

Вне зависимости от выбранных вами инструментов есть несколько критичных моментов, на которые обязательно стоит обратить внимание.

Правильный backend

Результаты тестирования могут сильно зависеть от ответов backend за WAF.

Наборы тестовых запросов должны быть разнообразными, использовать методы GET, POST, PUT и другие. Если backend за WAF на это не рассчитан, то в ответ вернет 405 Method Not Allowed, что может быть расценено инструментом тестирования WAF как обход (т.к. обычно ожидается 403). В итоге вы получите искаженный результат. Для исключения этого фактора рекомендую backend, который на все запросы отвечает 200, пример - https://hub.docker.com/r/mendhak/http-https-echo

Отключение блокировок по IP

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

Отключение позитивной модели или подстройка под нее

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

Одинаковые условия для всех испытуемых

Неизменность инструментария и набора тестов. Нужно следить чтобы все испытуемые были в равных условиях.

Отсутствие блокировок на основе содержимого User-Agent

При тестировании убедитесь что происходит блокировка на основании анализа запроса, а не из-за содержимого заголовка User-Agent.

Отключение антибот функциональности

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

Разнообразие payload

Постарайтесь обеспечить хорошее покрытие как по разным типам атак (SQLi, RCE, LFI, etc), так и по вариантам payload для каждого типа атаки. Банальные вектора типа <script>alert(1337)</script> и ../../../etc/passwd заблокирует любой WAF.

Наличие false-positive тестов

Очень важный момент. WAF может обладать слишком «грубыми» сигнатурами (или иными методами обнаружения атак) и при тестировании выглядеть лучше конкурентов за счет этого. Но на деле недостаточно качественные сигнатуры станут причиной блокировки нормальных запросов от пользователей. Вот несколько примеров строк, которые могут быть расценены некоторыми WAF как атаки.

"UPDATE is used to modify data in a table."
ANY (almost) values
DEAR FINN,--I think it would do; copy should reach us second post
JavaScript: Basics of JavaScript Language
ls 300 lexus
D'or 1st parfume
I setted the COOKIE value to : expandGeoJsonFeatures=true;
exec noun
time he came.
nc 8000 controller

Наличие достаточного количества false-positive тестов поможет получить более релевантную картину.

Не сравнивайте «в лоб» решения, основанные на разных принципах фильтрации – позитивной и негативной моделях.

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

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

• Негативная модель. При такой модели, напротив, работает правило: «разрешено все, кроме запрещенного». Использование такого подхода приводит к восприятию любого трафика в сторону приложения, как потенциально опасного. Как следствие – любой запрос к приложению разбирается и оценивается полностью.

Заключение

1. Чтобы сделать правильный выбор из многообразия WAF, придется разработать методику сравнения и тестирования. OWASP Web Application Firewall Evaluation Criteria Project (WAFEC) может стать отправной точкой для этого.

2. При тестировании WAF важно оценить качество обнаружения инъекций. В этом вам помогут инструменты, описанные выше. Совмещайте утилиты тестирования WAF, пентест инструменты, ознакомьтесь с Payloads All The Things.

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

GLHF!

P.S. Выражаю благодарность моему коллеге D1nko за помощь в написании этой статьи.

Все об API Security, Web Security. Еще немного про уязвимости и технические изыскания команды Вебмониторэкс. Никакой рекламы. Только полезные материалы. https://t.me/WMXWAS