16.07.2024 13:42
f0resteR 0 2100 Источник

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

Привет! Меня зовут Никита, я занимаюсь информационной безопасностью в 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"
}
Примеры отчетов OWASP ZAP
Примеры отчетов OWASP ZAP

Модуль сбора информации

Идея создания модуля сбора информации появилась из-за необходимости минимизировать влияние на процессы наших продуктовых команд. Модуль был нужен для определения конкретной области сканирования под релиз или задачу, так как полный скан занимает слишком много времени и не соответствует нашим требованиям по 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, и релиз не может быть согласован, если среди них есть необработанные проблемы или уязвимости с определенной критичностью.

Пример срабатывания в системе Security Gate
Пример срабатывания в системе Security Gate

Что в итоге

Мы создали универсальный сервис для интеграции и настройки OWASP ZAP с модульной системой и оптимизировали процесс обнаружения и исправления уязвимостей.

Процесс от публикации нового билда до подтверждения исправления бага включает следующие этапы:

  1. Создание билда: Сборка микросервиса и развертывание его на dev-стенды.

  2. Импорт спецификаций: OpenAPI спецификация загружается в ZAP через API.

  3. Запуск модуля сбора информации: Модуль отслеживает изменения в микросервисах по спецификациям API на всех стендах и изменениях в релейных ветках.

  4. Настройка и сканирование: ZAP настраивает контекст тестирования и проводит активное сканирование по импортированной области сканирования.

  5. Обработка результатов: Автоматическое исключение false positive и создание отчетов.

  6. Отправка отчетов: Отчеты отправляются в VK Teams и Security Gate.

  7. Обработка уязвимостей: Инженер ИБ подтверждает или отклоняет уязвимости (например, false positive) и следит за исправлением багов.

  8. Дальнейшее сопровождение процесса: контроль за исправлением бага инженером ИБ вплоть до закрытия проблемы, аппрува релиза и деплоя безопасного кода в production.

Сейчас этот сервис работает в двух режимах: 

  1. Режим сканирования на изменения: Выполняется на dev и stage средах для выявления уязвимостей в новых версиях сервисов.

  2. Полное сканирование по расписанию: Осуществляется на stage и prod средах для проверки межсервисных взаимодействий и состояния prod. Все результаты сканирования обрабатываются по описанной выше схеме.

Это решение упростило процесс отслеживания и исправления уязвимостей, а также позволило сократить время на разбор изменений в сервисах. 

Планы на будущее

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

В ближайших планах:

  • добавление и улучшение кастомных правил сканирования;

  • выпуск нашей разработки в Open Source.

Комментарии (0)