Более трети современных приложений содержат опасные уязвимости. Для анализа их защищённости сегодня не обойтись без динамического сканера (Dynamic Application Security Testing, DAST), функциональность которого позволяет оперативно обнаружить и оценить проблемы в области безопасности. Рассказываем, на что обратить внимание при выборе такого инструмента.
- Введение
- Что такое DAST и как работает инструмент?
- На что обращать внимание при выборе инструмента DAST?
- Какой инструмент выбрать?
- 4.1. BurpSuite Enterprise
- 4.2. OWASP ZAP (Zed Attack Proxy)
- 4.3. PT BlackBox
- Выводы
Введение
По данным исследования Positive Technologies, в 2020-2021 годах злоумышленники имели возможность совершить атаку на 98 % веб-приложений. Потенциально они могут распространять вредоносные программы, перенаправлять пользователей на поддельные сайты или красть их персональные данные при помощи методов социальной инженерии. В 2020 году 66 % веб-приложений имели уязвимости высокой степени риска, в 2021 году этот показатель немного снизился и составил 62 %. При этом 72 % от общего числа всех найденных уязвимостей связаны с ошибками в коде.
Таким образом, большинство продуктов, выпускаемых на рынок, достаточно уязвимы, чтобы стать лёгкой добычей для хакеров. Конечно, создать идеально защищённое ПО невозможно, но сократить количество уязвимостей и повысить уровень безопасности продукта вполне реально. Для этого можно внедрить DevSecOps; процесс позволит связать разработку и безопасность, и в результате программное обеспечение будет проверяться и тестироваться на наличие уязвимостей на каждом этапе его создания.
Процесс DevSecOps весьма объёмен, он включает в себя различные инструменты ИБ. В этой статье Юрий Шабалин, ведущий архитектор Swordfish Security, поговорит о практике DAST, а именно — о том, как выбрать подходящий сканер для динамического анализа приложений. Вместе разберёмся, на какие параметры инструмента нужно обращать внимание и какие продукты сейчас доступны на рынке.
Что такое DAST и как работает инструмент?
Dynamic Application Security Testing (DAST) — это одна из практик безопасной разработки. В рамках DAST проводится автоматизированный анализ развёрнутого и функционирующего приложения. Динамический сканер проверяет все точки доступа по HTTP, имитирует внешние атаки с применением распространённых уязвимостей, моделирует случайные действия пользователей. Инструмент определяет, какие API есть у сервиса, отправляет проверочные запросы, например подставляет, где это возможно, неправильные данные (кавычки, разделительные знаки, спецсимволы и другое). Поиск уязвимостей происходит в результате анализа отправленного запроса и полученного ответа от сервиса, а также их сравнения с обычным запросом. Динамический сканер отправляет и анализирует большое количество запросов — это позволяет находить разные проблемы безопасности.
В 2021 году Anti-Malware.ru делал обзор рынка DAST в статье «Разработка безопасных приложений. Часть 2. Обзор рынка DAST 2021».
Большинство сканеров похожи по функциям и принципам работы. Основными их компонентами являются «паук» (spider) для составления карты приложений и анализатор.
«Паук» обходит каждую ссылку на всех страницах, до которых может добраться, изучая содержимое файлов, нажимая кнопки, перебирая по словарю потенциально возможные варианты названия директорий и страниц. Этот процесс называется краулингом (crawling), он позволяет оценить размер «поверхности» атаки, в том числе с учётом существующих способов взаимодействия с приложением.
Анализатор — компонент, который проводит непосредственно проверку приложения. Он работает в пассивном или активном режиме. В первом случае изучаются только те данные, которые ему присылает «паук». Во втором — анализатор отправляет запросы с некорректными данными по найденным «пауком» точкам и по другим местам, которых нет на страницах, но которые при этом могут использоваться в приложении. Затем компонент делает вывод о наличии уязвимости на основании ответов и реакции сервера.
На что обращать внимание при выборе инструмента DAST?
DAST реализует автоматический анализ приложения в динамике с использованием различных инструментов. Выбирать эти инструменты нужно с учётом конкретных параметров.
Качество сканирования
Это — соотношение найденных и пропущенных уязвимостей. С ходу понять, насколько качественно анализирует сканер, невозможно. Для этого нужно иметь хотя бы примерное представление о том, какие уязвимости есть в приложении, чтобы потом сравнить их с результатами сканирования. Существует несколько способов проверить инструмент:
- Если у вас есть приложение и вы уже проверяли его на уязвимости через программу вознаграждений за поиск изъянов (баг-баунти), тестирование на проникновение и другое, можно сравнить полученные результаты с итогами проверки сканером.
- Если приложения нет, можно использовать другое заранее уязвимое ПО, которое создаётся, как правило, для обучения. Нужно найти такую программу, которая по стеку технологий близка к вашим разработкам.
Для качества сканирования также определяющую роль играет количество ложных срабатываний: они засоряют результаты, к тому же среди них могут затеряться реальные ошибки. В этом случае намного проще определить, насколько качественно сканирует инструмент: достаточно проанализировать отчёт, разобрать срабатывания, посчитать примерно, какая доля от их общего числа — ложные, и на этой основе сделать вывод о точности сканера.
Краулинг
Если дополнительной информации о приложении нет и нужно проанализировать его «с нуля», важно понимать, как много путей и переходов получится собрать в нём, то есть насколько точным будет краулинг. Для этого нужно посмотреть настройки продукта. Необходимо выяснить, умеет ли он мониторить запросы от фронтенда к бэкенду, парсить, например, Swagger- или WSDL-приложения, находить ссылки в HTML или JS. Ещё стоит изучить процесс получения информации о приложении. Можно перед сканированием уточнить, какие именно API используются: нужно понять, что поможет инструменту совершить полноценную проверку приложения. В процессе выбора сканера полезно составить список того, что может импортировать каждый инструмент, и подумать, получится ли встроить это в процесс.
Скорость сканирования
Этот параметр также важен, особенно если проверки интегрированы в разработку: они могут тормозить процесс и в результате приводить к тратам времени и денег. Скорость сканирования во многом зависит от того, как оперативно приложение отвечает на запросы, сколько одновременных подключений оно способно обработать, и от ряда других факторов. Поэтому чтобы сравнить скорость работы различных инструментов, нужно запускать их применительно к одному и тому же ПО в примерно одинаковых условиях.
Детальная настройка
У инструментов автоматического анализа должны быть детальные настройки. Они позволят убрать лишние запросы и ограничить зону проверки, за счёт этого повысятся качество процесса и скорость анализа. Чем детальнее настройки, тем точнее получится обозначить задачи инструменту.
Существуют «умные» сканеры, которые сами подстраиваются под приложения. Но у таких инструментов всё равно должна быть ручная настройка, поскольку цели у проверок бывают разные. Например, иногда нужно просканировать приложение в нескольких вариантах, начиная тотальной проверкой и заканчивая поверхностным анализом; в таком случае ручная настройка точно будет кстати.
При выборе инструмента нужно обращать внимание на количество параметров, а также на то, как легко их настраивать. Чтобы сравнить работу разных инструментов, можно создать в каждом из них несколько профилей сканирования: быстрый и поверхностный для начального анализа, полный и максимальный — для полноценного.
Интеграция
Чтобы динамический анализ был максимально эффективным, стоит интегрировать эту практику в процесс разработки и периодически запускать сканер во время сборки. Нужно заранее сформировать перечень того, что используется в процессе CI / CD, составить примерный план запуска инструмента. Это поможет проанализировать сканер с точки зрения интеграции и понять, насколько легко получится внедрить его в процесс разработки и удобно ли использовать его API.
Технологии
Выбирать сканер нужно с учётом технологий, которые использует ваша компания в разработке. Для этого можно проанализировать приложения и сформировать список технологий, языков и фреймворков, которые применяются в продуктах. Перечень может получиться весьма обширным, особенно если компания велика. Поэтому уместно выбрать всего несколько параметров в качестве критериев оценки сканеров:
- количество технологий и фреймворков, которые охватывает инструмент,
- возможность поддержки ключевых технологий, которые компания использует в своих самых важных сервисах.
Запись последовательности логина
Для динамических сканеров крайне важна технология записи последовательности логина, поскольку для входа в приложение обязательно нужно пройти аутентификацию. Но в этом процессе кроется много подводных камней, например хеширование пароля перед отправкой или его шифрование общим ключом на фронтенде; это далеко не весь список. Поэтому нужно заранее проверить, справится ли инструмент со всеми нюансами. Для этого необходимо выбрать максимально разные приложения и посмотреть, сможет ли сканер пройти в них этап логина.
Также нужно проверить, как поведёт себя инструмент при разлогинивании. Сканер в процессе анализа отправляет много запросов, в ответ на некоторые из них сервер может «выбросить» пользователя из системы. Инструмент должен заметить это и снова войти в приложение.
Обновления инструмента
Технологии постоянно развиваются, поэтому при выборе инструмента важно также учитывать, насколько часто выходят его обновления или новые версии сигнатур / паттернов или правил анализа. Стоит изучить эту информацию на сайте продукта или запросить её у вендора. Это покажет, внимательно ли разработчик следит за тенденциями и насколько актуальной будет ваша база проверок.
Также нужно выяснить, сможете ли вы влиять на развитие продукта и как разработчик обрабатывает запросы на добавление новых функций. Это покажет, насколько быстро в продукте будут появляться те функциональные возможности, которые вам нужны, и как устроено общение с вендором в рамках обновления опций.
Какой инструмент выбрать?
Совсем недавно на рынке был большой выбор инструментов от Acunetix, Netsparker, Rapid7, Nessus, AppScan, WebInspect и других вендоров, которые выпускают качественные продукты. В настоящее время из-за сложившихся политических условий инструментов для динамического анализа осталось не так много. Но эффективные решения всё же есть: часть из них созданы на базе Open Source, остальные являются коммерческими продуктами.
BurpSuite Enterprise
Инструмент разработала компания PortSwigger. У продукта есть полноценный REST API для взаимодействия и управления запуском сканирований, отправкой отчётов и многим другим. Сканирующим агентом является классический BurpSuite. Он запущен в режиме «headless», но имеет ограничения: например, с ним можно взаимодействовать только через управляющие команды с головного портала, а загрузить свои плагины не получится. Кроме этого, у продукта небольшая функциональность (по крайней мере, на момент, когда мы тестировали сканер). В целом, если инструмент правильно настроить, он может показать вполне эффективный результат.
OWASP ZAP (Zed Attack Proxy)
Этот очень популярный в мире инструмент создан в рамках деятельности сообщества OWASP, поэтому он полностью бесплатен. Для него есть разные SDK и API под различные языки программирования, поэтому можно пользоваться разработками OWASP или своими плагинами. Продукт имеет расширения для различных инструментов CI / CD, его можно запускать в разных режимах и управлять им программно, а следовательно, внедрять инструмент в процесс разработки. В то же время у сканера есть и минусы. Он создан на базе Open Source, поэтому качество проверки ниже, чем у энтерпрайз-решений. Ещё функциональность инструмента не очень обширна и глубока, но её можно дописать и улучшить.
PT BlackBox
Это — новая разработка компании Positive Technologies. У вендора уже давно есть облачный продукт PT BlackBox Scanner. Инструмент обладает полноценным REST API для управления сканированием, есть всё для детальной настройки параметров анализа. Недавно, в конце августа, компания выпустила «коробочную» редакцию продукта. До релиза мы успели протестировать бета-версию и можем сказать, что инструмент является достойной заменой разработкам зарубежных вендоров. Совсем скоро мы планируем дополнительно проверить вышедший продукт и сравнить его с другими инструментами.
Выводы
При выборе динамического анализатора стоит использовать отмеченные выше в этой статье критерии, но применять их нужно правильно. Каждая компания уникальна, имеет свои нюансы и особенности — всё это необходимо учитывать в связке со всеми критериями. Также нужно заранее определить свои потребности и понять, каких результатов вы хотите от инструмента. На рынке сейчас осталось не так много продуктов. С одной стороны, это плохо, с другой — не придётся слишком долго выбирать. Но, чтобы не ошибиться, нужно проводить полноценное тестирование различных вариантов, сравнивать их между собой и выбирать наилучшее решение с учётом потребностей компании и параметров качества.
