Для защиты цифровых активов организаций важно оперативно выявлять и устранять уязвимости. Инструменты для сканирования автоматизируют этот процесс, позволяя эффективно находить слабые места в системах и приложениях.
Привет! Меня зовут Никита, я занимаюсь информационной безопасностью в RuStore. Сегодня расскажу о том, как мы создали свой сервис сканирования уязвимостей на базе OWASP ZAP, с какими трудностями столкнулись и какие подходы применили для их решения.
Что надо было сделать
Перед нашей командой встала задача организовать динамическое сканирование для каждого релиза. С ростом числа релизов вопрос автоматизации и оптимизации этого процесса стал особенно актуальным. Нам требовался инструмент, способный выполнять динамический анализ приложений, с гибкой настройкой правил сканирования и целей анализа.
Почему OWASP ZAP
Мы выбрали OWASP ZAP — открытое программное обеспечение, предоставляющее все необходимые инструменты для глубокого динамического анализа. Это решение соответствовало нашим специфическим требованиям и превосходило другие по двум ключевым причинам:
адаптивность под специфику проекта;
мощный API, который упрощает добавление новых функций, правил и плагинов.
Интеграционный сервис
В качестве первого этапа разработки системы сканирования мы создали интеграционный сервис, который обеспечивает гибкую настройку OWASP ZAP для каждого нового релиза. На Python был создан сервис, способный выполнять следующие задачи:
сбор информации о сервисах и релизах;
настройка параметров сканирования через API OWASP ZAP на основе JSON-конфигурации.
Пример входной конфигурации:
"scan host": [
{
"targetProto": "https",
"targetHost": "apps.rustore.ru",
"header token": [
{
"User-Token": "***"
}
],
"enabled": "true",
"swagger scope": {
"enabled": "False",
"url": "https://backapi.rustore.ru/v3/api-docs"
},
"scan config": {
"scanner": {
"enabled": "true",
"exclusion": [
{
"value": ".*logout.*",
"enabled": "true"
}
]
},
"spider": {
"enabled": "true",
"ajax spider": "true",
"exclusion": [
{
"value": "https://console.rustore.ru",
"enabled": "true"
}
]
}
}
}
]Для настройки параметров сканирования мы разработали структуру JSON-файла, которая включает следующие возможности:
Подключение модулей и правил сканирования: позволяет гибко настраивать необходимые типы и правила сканирования для каждой цели сканирования.
Правила включения и исключения адресов: позволяют определить, какие URL-адреса должны быть включены в сканирование, а какие исключены.
Настройка работы с веб-сокетами: предоставляет параметры для управления взаимодействием с веб-сокетами во время сканирования, что важно для проверки реального поведения приложения в условиях активного обмена данными.
Специфическая авторизация для каждого сервиса: позволяет задать авторизационные данные для доступа к защищённым частям приложения, что критично для проверки уязвимостей в защищённых сегментах.
Управление форматом отчетов: включает настройки для генерации отчётов о результатах сканирования, что упрощает анализ и предоставление результатов тестирования.
Кроме того, OWASP ZAP разворачивается на отдельной ноде в нашей инфраструктуре, и для каждого сканирования запускается новый чистый инстанс. Это гарантирует изоляцию сеансов и чистоту тестирования, что критично для получения точных и объективных результатов.
В итоге в сервисе получилось несколько модулей, разделенных по логике работы:
Core
В core-модуль входят настройка сессии ZAP, настройка аутентификации, настройка контекста скана, политики сканирования с исключениями, работа с веб-сокетами, запуск остальных модулей.
Модуль сканирования и обработки результатов
В модуле реализованы настройка и добавление правил сканирования, конфигурация плагинов. Для его создания мы исследовали и протестировали множество публичных плагинов для OWASP ZAP из внутреннего магазина и внешних источников, таких как GitHub и GitLab. Мы оценили возможности настройки и результаты работы каждого плагина, выбрав наиболее подходящие для нашего стека технологий. И сейчас постоянно занимаемся обогащением правил и механизмов поиска уязвимостей для улучшения качества сканирования.
Проблемы и их решения
После реализации этого функционала мы столкнулись с проблемой объёма срабатываний и скорости их обработки. Было принято решения отсортировать проверки по проценту false positive срабатываний. Идея заключается в том, чтобы выделить классы срабатываний без false positive и сразу отправлять их в работу без дополнительного анализа. Отчёт с такими срабатываниями генерируется отдельно, и его можно сразу отправлять в команду разработки.
Еще одной проблемой оказался внутренний механизм ZAP работы с false positive, который отказывался работать как нам надо. Поэтому мы реализовали свой модуль, который отслеживал статусы задач от скана к скану.
Список срабатываний, ранее отмеченных как false positive, отдельным файлом подгружается из хранилища S3, затем парсится скриптом, и релевантные для данного сканирования false positive результаты загружаются в метод AlertFilter, встроенный метод API ZAP.
Сущность false positive алерта содержит в себе информацию о ключевых параметрах отправленного запроса и потенциальной уязвимости:
ruleId — идентификатора отработавшего правила ZAP;
url - URL запроса;
Method — HTTP-метод, использовавшийся при запросе;
Parameter — название уязвимого параметра;
attack — полезная нагрузка, отправленная ZAP’ом в параметре запроса;
CWEId — идентификатор CWE найденной уязвимости.
Пример сущности оповещения false positive:
{
"ruleId": "43",
"url": "https://***.rustore.ru/applicationData/10?pageSize=21&pageNumber=0",
"Method": "GET",
"Parameter": "pageSize",
"attack": "10",
"Instances": "541",
"CWEId": "33"
}
Модуль сбора информации
Идея создания модуля сбора информации появилась из-за необходимости минимизировать влияние на процессы наших продуктовых команд. Модуль был нужен для определения конкретной области сканирования под релиз или задачу, так как полный скан занимает слишком много времени и не соответствует нашим требованиям по TTM в рамках SDLC процессов.
Наша задача состояла в том, чтобы собрать максимум данных для точного описания области сканирования для релиза. Важным требованием была автоматизация сбора данных и их перевод в формат, понятный сервису. Поэтому мы отказались от написанных людьми описаний задач и сервисов в свободной форме. Идеальным решением стало отслеживание всех изменений API-спецификаций, любых изменений эндпоинтов и параметров. Мы написали функционал парсинга спецификаций API и хранения нескольких предыдущих состояний, чтобы предотвратить ошибки, связанные со случайным или ошибочным изменением Swagger.
Еще одним источником данных об изменениях стали merge requests в релизные ветки. Эти данные позволяют заранее узнать, какие сервисы готовятся к релизу, и просканировать их. Данные из этого модуля передаются в CORE-модуль для запуска скана с конкретным скоупом.
Пример вывода приложения при проверке изменений Swagger'а:
Services:
https://backapi.rustore.ru
https://api.rustore.ru
https://app-selection.*.rustore.ru
https://dev.rustore.ru
There are updates at the following stands:
https://backapi.rustore.ru
https://api.rustore.ruМодуль генерации отчетов
На этом этапе мы генерируем несколько отчетов и отправляем их в разные системы. Создаются два вида отчетов:
Полный скан: отчет включает все найденные уязвимости, за исключением ложных срабатываний. Он сохраняется в S3-хранилище вместе с ZAP‑сессией, чтобы инженеры по информационной безопасности могли получить полную картину о сервисе и скане.
Отчет для разработчиков: этот отчет содержит только те правила, которые имеют очень низкий процент ложных срабатываний или не имеют их вовсе.
Оба отчета представлены в удобочитаемом формате HTML. Также мы сохраняем их копии в формате JSON для удобства автоматизации обработки и последующей загрузки в системы управления уязвимостями.
Также результаты сканирования попадают во внутреннюю систему управления уязвимостями — VK Security Gate. Этот инструмент компании VK предназначен для автоматизированного сканирования исходного кода с использованием инструментов статического анализа (SAST), поиска уязвимых зависимостей (SCA), а также для обработки полученных срабатываний. Security Gate позволяет удобнее обрабатывать находки и отслеживать их статусы по каждому сервису в любой среде разработки.
Кроме того, был автоматизирован процесс согласования релизов. Теперь проверяются статусы всех находок в Security Gate, и релиз не может быть согласован, если среди них есть необработанные проблемы или уязвимости с определенной критичностью.
Что в итоге
Мы создали универсальный сервис для интеграции и настройки OWASP ZAP с модульной системой и оптимизировали процесс обнаружения и исправления уязвимостей.
Процесс от публикации нового билда до подтверждения исправления бага включает следующие этапы:
Создание билда: Сборка микросервиса и развертывание его на dev-стенды.
Импорт спецификаций: OpenAPI спецификация загружается в ZAP через API.
Запуск модуля сбора информации: Модуль отслеживает изменения в микросервисах по спецификациям API на всех стендах и изменениях в релейных ветках.
Настройка и сканирование: ZAP настраивает контекст тестирования и проводит активное сканирование по импортированной области сканирования.
Обработка результатов: Автоматическое исключение false positive и создание отчетов.
Отправка отчетов: Отчеты отправляются в VK Teams и Security Gate.
Обработка уязвимостей: Инженер ИБ подтверждает или отклоняет уязвимости (например, false positive) и следит за исправлением багов.
Дальнейшее сопровождение процесса: контроль за исправлением бага инженером ИБ вплоть до закрытия проблемы, аппрува релиза и деплоя безопасного кода в production.
Сейчас этот сервис работает в двух режимах:
Режим сканирования на изменения: Выполняется на dev и stage средах для выявления уязвимостей в новых версиях сервисов.
Полное сканирование по расписанию: Осуществляется на stage и prod средах для проверки межсервисных взаимодействий и состояния prod. Все результаты сканирования обрабатываются по описанной выше схеме.
Это решение упростило процесс отслеживания и исправления уязвимостей, а также позволило сократить время на разбор изменений в сервисах.
Планы на будущее
Мы продолжаем расширять функциональность нашего сервиса, чтобы обеспечить ещё более глубокий и точный анализ безопасности приложений.
В ближайших планах:
добавление и улучшение кастомных правил сканирования;
выпуск нашей разработки в Open Source.