Проблемы динамического анализа веб-приложений и API. Как мы их решаем

Проблемы динамического анализа веб-приложений и API. Как мы их решаем

Чтобы использовать DAST на практике, заказчик должен понимать, как работает этот класс решений, для каких целей его нужно выбирать, какие приложения и в каких сценариях необходимо анализировать и, наконец, как работают собственные сканируемые приложения. В этой статье мы разберем некоторые аспекты динамического анализа веб-приложений с упором на актуальный опыт применения и пилотирования нашего решения по динамическому анализу SolidPoint DAST.

Разбираем термины

Следует разграничить термины «DAST», «динамический анализ», «сканер уязвимостей» и «сканер безопасности». Путаницу в терминах я встречал как в формальных взаимодействиях с заказчиками, так и в личных беседах, конечно, она осложняет взаимопонимание, и может приводить к ложным ожиданиям.

Если говорить о терминах проще, то:

• «Динамический анализ» — ​общее название методов анализа ПО во время его выполнения. Сюда входит не только безопасность, но и проверка производительности и функциональности, анализ поведения ПО, сетевая активность, работа с памятью и другие категории.
• «Сканеры уязвимостей» — ​это подкласс «сканеров безопасности». Они используют разные методы, включая динамические, для поиска уязвимостей в широком стеке инфраструктуры и ПО. Чаще всего сканеры отрабатывают уязвимости из классификатора CVE. При этом «сканеры безопасности» могут идентифицировать более широкую номенклатуру рисков. Оба термина применяются достаточно вольно для обозначения инструментов, представленных на рынке.
• «DAST» — ​наиболее узкий термин. Он указывает на класс сканеров, применяющих динамический анализ для идентификации недостатков безопасности веб-приложений и API без доступа к коду, методом «черного ящика». Результатом работы DAST, как правило, является список выявленных недостатков ПО, категорированных по CWE.

Таким образом, под DAST мы понимаем специфический класс инструментов для анализа безопасности веб-приложений и API. Хотелось бы, чтобы на рынке вся терминология становилась более унифицированной. Разница в понимании ведёт к потере времени при переговорах, что критично в условиях срочных запросов и интенсивных коммуникаций. Сейчас мы рекомендуем согласовать все термины ещё на старте.

Нередко мы встречаем конкурсные процедуры, где указаны широкие требования для сканеров уязвимостей, например, по поддержке протоколов, не имеющих отношения к вебу. При этом конкурс заявлен на выбор инструмента DAST. Добавлю, что есть некоторая надежда на то, что ожидаемый новый ГОСТ по динамическому анализу зафиксирует терминологию и взаимодействие станет проще.

Что значит правильная подготовка к сканированию

Основное, если вы не знаете, как устроено ваше приложение, которое вы хотите сканировать, а также инфраструктура его доставки, то эффективности от DAST’а ожидать не приходиться. Опыт пилотных внедрений показал, что успешное сканирование требует тщательной подготовки. Были случаи, когда мы сталкивались со сложностями при сборе информации о приложении и при проведении первичного сканирования: недостоверная устаревшая или неполная информация, систематические ошибки в полученных «на руки» данных, низкий показатель стабильности и доступности стендов.

По сути, инструменты DAST умеют сканировать приложения без какой-либо подготовки, даже без данных для аутентификации. Но обычно всё интересное закрыто от доступа, поэтому первое, с чем необходимо определиться, — ​это какую инсталляцию приложения мы сканируем, какие данные по аутентификации нам нужны, достаточно ли сканирования под одной ролью или нужно под разными, как работает механизм аутентификации, ограничено ли время сессии, и если да, то как конкретно? Зачастую типы аутентификации и применяемые методы могут смешиваться, тогда инструмент должен уметь их применить «по месту».

С помощью SolidPoint DAST мы поддерживаем различные механизмы: аутентификация по кукам, токенам, HTTP Basic, по клиентским сертификатам, через локальное хранилище браузера (localStorage). Наконец, существуют более сложные сценарии — ​запись браузерного скрипта с данными аутентификации и метод аутентификации по HTTP-запросу, например, для работы с JWT-токенами и для обновления короткоживущих сессий. При этом для сканируемого приложения можно задать целую группу данных аутентификации для основного приложения и для входящих в приложение API, находящихся на соседних URL, — ​сканер сам применяет эти данные.

Для подготовки сканирования следом идут дополнительные вопросы, есть ли CAPTCHA, OTP, SMS, можно ли как-то зафиксировать их значения в тестовых средах и что делать с ними в продуктивной среде, поскольку динамически подгрузить их в запущенное сканирование может оказаться проблематичным. Следующий вопрос — ​как ограничена нагрузка в продуктивной или в тестовой среде? Зачастую тестовые среды сами по себе менее мощные, а в продуктивной не хочется влиять на производственный процесс. Важно понять предел нагрузки, сколько условных RPS можно разрешить сканеру, этот же параметр, кстати, напрямую повлияет на время сканирования.

Есть ли WAF или иные системы, блокирующие трафик? Если да, необходимо внести сканер в белый список. Также, нужно выявить, какие конечные точки приложения нельзя затрагивать сканированием. В первую очередь, это касается конечных точек, приводящих к выходу из сессии — ​«разлогину». Еще в продуктивных приложениях это могут быть конечные точки, связанные с вызовом внешних интеграций, например, SMSGateway — ​мы же не хотим исчерпать весь бюджет платного сервиса, отправив тысячи SMS в никуда? Также могут быть конечные точки, связанные с критическим бизнес-процессом, например, с кнопкой «оплатить». Обычно на сайте это последний этап воронки продаж, и он должен работать идеально.

Сканирование — это отправка мно­жества запросов, не всегда корректных функционально, для проверки того, как приложение отреагирует. Приложение может начать регистрировать поток ошибок. В ситуации, когда сканер внесён в белый список и средства защиты пропускают его трафик, это может неожиданно для всех привести к реальным операционным рискам, например, вызвав DoS. Но чаще всего регистрируемые ошибки могут замаскировать сопутствующую реальную проблему, и служба мониторинга имеет все шансы за штормом событий её пропустить, нарушив SLA и, как следствие, не выполнив KPI.

Также возникает вопрос о длительности сканирования. Как правило, время зависит от размера приложения, сложности конечных точек приложения — ​количества параметров в каждой, а также от скорости сети и выбранного RPS. При сканировании составляется карта приложения и различными методами проверяется каждый выявленный объект: конечная точка или ресурс на сайте, атаки посылаются по каждому выявленному параметру. Все эти факторы в совокупности влияют непредсказуемо сложно, и чтобы ответить точно, потребуется провести первое полноценное сканирование.

Вытекающий вопрос из предыдущего — ​а сколько узлов сканирования понадобиться для реальной промышленной инсталляции? До первого полноценного сканирования каждого приложения и API ответить сложно, т. е. это становится понятным в середине внедрения. По этой причине в сканере SolidPoint DAST поддерживается горизонтальное масштабирование и количество узлов не ограничено лицензией.

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

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

Несмотря на то, что DAST как класс решений работает с приложениями как с «черным ящиком» (т. е. через его внешние интерфейсы), влияние технологий разработки сканируемого приложения все же сказывается на результатах сканирования. Так было при появлении SPA приложений, после чего сканеры на рынке дружно заявили о всяческой поддержке SPA — ​почти сразу, как ее реализовали.

Возникает вопрос, насколько качественно средства динамического анализа определяют поверхность атаки? Ответ не очевиден, ведь недостаточное покрытие не приводит к ложным срабатываниям, на которые можно указать, а приводит к ложно негативным результатам, оставляя реальный скоуп приложения и уязвимости без внимания. Ведь чтобы просканировать функцию на стороне сервера, надо сначала найти, как ее вызвать — ​узнать формат запроса, параметров, а дальше уже проверять на уязвимости; если инструмент не умеет с хорошей полнотой идентифицировать функции на стороне сервера — ​т. е. поверхность атаки — ​до этапа тестирования на уязвимости этой функции инструмент даже не доберется, т. е. фактически приложение останется просто непроанализированным. Эти проблемы характерны для современных приложений с изощренной сложностью интерфейсов и глубокой зависимостью от разнообразных JS-фреймворков.

В исследовании The Security Tools Gap [1], проведенном компанией Axeinos в марте 2025 года, прямо сказано, что при определении поверхности атаки BlackBox сканеры очень быстро сдаются, оставляя значительную часть приложения неисследованной, причем чем выше сложность приложения, тем больше эта проблема. Получается, что изначально, сканеры ищут уязвимости и ошибки не в приложении, а в его малой части, при этом существующие технологии динамического краулинга не могут компенсировать это упущение, нужно что-то иное.

Значительно ранее, проводя многочисленные пентесты для наших заказчиков, мы обнаружили, что периодически встречаются запросы, хранящиеся в коде JS, не имеющие соответствующей части в UI. Стало понятно, что классические методы динамического краулинга, не способны их найти. Кроме того, у них есть дополнительные ограничения: страницы приложения могут создаваться динамически, что удлиняет и иногда зацикливает анализ, не всегда элементы управления и связанные с ними функции получается идентифицировать, не все введенные краулером данные оказываются корректными, чтобы приложение перешло на следующий экран. По этой причине при разработке своего сканера мы уделили особое внимание этой проблеме, разработав специальный модуль статико-динамического анализа клиентского кода — ​анализатор JavaScript-кода [2]. Мы рассказывали об этой технологии на Standoff в 2022 году [3]. Удобными особенностями JS-анализатора являются относительная быстрота анализа, игнорирование ветвлений, т.  е. весь загруженный код может быть проанализирован без ограничений логики работы приложения, и в нем могут быть найдены необходимые вызовы, включая необходимый формат и параметры. Также, если приложение отдает сразу весь JS-код, появляется возможность без авторизации получить полную карту конечных точек, включая связанные с административными функциями. Также этот анализ интересен пентестерам, с его помощью можно быстро получить информацию о поверхности атаки приложения заказчика.

Таким образом, в SolidPoint DAST проблема обнаружения возможной поверхности атаки и как следствие, проблема сужения проверяемого скоупа приложения эффективно решаются спектром инструментов: статическим и динамическим краулерами, дирбастингом, и уникальным JS-анализатором. Для получения дополнительной информации о конечных точках приложения сканер может интегрироваться с SolidWall WAF, а также способен импортировать спецификацию OpenAPI/Swagger, SOAP, GraphQL сервиса.

О решении SolidPoint DAST

SolidPoint DAST входит в реестр отечественного ПО. Разработчиком кода является компания «СолидСофт», которая активно развивает продукт с оглядкой на потребности российских заказчиков.

Мы предлагаем внедрять инструмент SolidPoint DAST как централизованную систему автоматического динамического анализа веб-приложений и API, которая включает возможности масштабирования задач сканирования с единым центром управления и поддержкой горизонтального масштабирования мощностей сканирования. Централизованное управление и разделение доступов позволяют организовать работу множества подразделений одновременно, оптимизируя потребляемые ресурсы. SolidPoint DAST из коробки поддерживает интеграции в различные автоматизированные процессы, как для анализа продуктивных сред, так и для интеграции в среды разработки, с помощью REST API или CLI, взаимодействующего с REST API. Также можно автоматизировать выгрузку результатов сканирования во внешние системы ASOC или интегрироваться с системами управления задачами, например Jira, Redmine и т. п. Таким образом, SolidPoint DAST может решать большой спектр задач автоматизированного сканирования веб-приложений и API на практике.

[1] http://web.archive.org/web/20250424002323/https://axeinos.co/report/The%20Security%20Tools%20Gap.pdf

[2] http://journals.tsu.ru/engine/download.php?id=223281&area=files

[3] https://www.youtube.com/watch?v=vG0EzOr81pE

Реклама. ООО «СОЛИДСОФТ», ИНН: 7714944046, Erid: 2VfnxxZoFYt