Роман Душков, Security Vision
Мы уже разбирали продукты и методики анализа исходного кода приложений путём поиска в содержимом уязвимых мест и сравнения с базой знаний экспертов, а сегодня разберем динамический анализ (Dynamic Application Security Testing, DAST). Он проводится в уже существующих платформах после компиляции исходного кода и может быть совмещён с предыдущими методами. Такой подход позволяет сделать анализ живым и постоянным, эффективно внедряясь в сам процесс разработки (DevSecOps) и при этом не нарушая скорость выхода новых версий продуктов, обновления сайта или миграции базы данных.
Основа динамического анализа – осуществление атак на приложение и поиск уязвимостей, который можно проводить без специальных продуктов. Такой подход является достаточно распространенным: многие компании объявляют награды за найденные уязвимости, вовлекая таким образом белых хакеров в обеспечение своей собственной безопасности. Все, что для этого нужно – иметь в публичном доступе свой сервис (например, сайт для онлайн-банкинга) или просто выдать лицензии на своё программное обеспечение интересующимся. Сам процесс можно назвать тестированием в режиме «чёрного ящика» (его так называют, поскольку доступа к исходному коду нет, а приложение используется в режиме «как есть»). Угадать, что внутри и как этим воспользоваться, предстоит пользователям. Такой процесс называется bounty hunting (охота за наградой) и похож на поиск сокровища без карты или охоту на покемонов. К слову, в 2022 году в рамках программ Bug Bounty корпорация Google выплатила 12 миллионов долларов (самая крупная выплата составила 605 000 долларов).
Несмотря на популярность и доступность такого метода, на рынке стали востребованы также автоматические системы, которые «атакуют» приложение без участия людей.
Рис. 1 – Механизмы динамического анализа кода
Инструментам DAST все равно, где в вашей архитектуре произошли изменения. Еще одна особенность DAST заключается в том, что это единственный метод тестирования безопасности, который не зависит от языка программирования. DAST не просматривает исходный код, байт-код или ассемблерный код; он просто проверяет готовый продукт. Базовый модуль DAST присутствует в open-source и коммерческих решениях по анализу уязвимостей, более продвинутые механизмы существуют в w3af или sqlmap. Работа таких инструментов похожа на проверку газовых труб на утечку, только вместо мыльного раствора и труб – искусственные атаки и ваше приложение.
Если вам посчастливилось обнаружить проблему безопасности, вы можете добавить специальные сценарии использования в свой набор тестов. Это чем-то похоже на построение завода по переработке отходов, когда весь поток сортируется: металл и пластик отправляются на переработку, стеклянные бутылки возвращаются на производство напитков, а часть мусора – сжигается. Так можно распределить нагрузку между автоматизированной системой и отделом тестирования и качества.
Более того, некоторые DAST-решения позволяют не только обнаруживать уязвимости, проводя атаки-«пустышки» на приложение, но и организовать эффективную защиту на лету. Такой процесс называется патчингом и чем-то похож на блокировку дороги во время ремонта или проезда кортежа. Уязвимое место найдено (в нашем примере это определенная дорога) и должно быть временно закрыто, пока уязвимость не устранена. Закрыть уязвимость можно вручную и автоматически, запустив новый процесс, когда заплатка помещается в уязвимое место до выпуска обновлённой версии приложения. Есть вендоры, которые комбинируют несколько продуктов, совмещая DAST со средствами зашиты (например, WAF), но при желании такой процесс можно настроить и автоматизировать самостоятельно, применяя средства для интеграции «разношёрстных» продуктов.
Начать проверку кода можно с применением бесплатных решений, одно из которых – продукт OWASP ZAP (Zed Attack Proxy). Продукт имеет расширения для различных инструментов CI/CD. Его функциональность не очень обширна и глубока, но её можно дописать и улучшить, если привлечь свои ресурсы или партнёров. Применение коммерческих инструментов позволит модифицировать и упростить процесс проверки. Его можно условно разделить на несколько частей:
· Построение дерева приложения, когда сканер кликает на все кнопки и открывает все возможные интерфейсы, как будто сенсорный экран «заглючило» после намокания под дождём. Только приложение делает этот краулинг умышленно, чтобы понять все взаимосвязи и возможности для получения доступа к данным.
· Каталогизирование, которое чем-то похоже на инвентаризацию ИТ-активов в компании. В ходе этого процесса система раскладывает интерфейсы по их типам, чтобы в дальнейшем осуществить более детальный анализ.
· Осуществление атаки на приложение, когда DAST в зависимости от интерфейса, определенного ранее, пытается «простукать» систему своими атаками. Атаки обычно безвредны и не несут реальной угрозы (часто не несут даже смысла, а только пустые заголовки), поэтому ущерба работе приложения быть не должно.
· Анализ происходящего и принятие решений, когда сканер подсвечивает все успешные попытки добраться к данным, которые должны быть защищены.
Поскольку анализ проходит на уже развёрнутой системе, появились два подхода:
1. Чтобы не повредить продукту и его развитию, лучше иметь отдельный стенд для тестирования. Физически это выглядит как копия приложения в изолированной среде, с которой работает динамический сканер. При таком подходе нужно продумать о дополнительном «железе», зато будет не страшно использовать DAST решения в первое время.
2. Если процессы очень развиты, разработка может вестись параллельно тестированию и применяется виртуальный патчинг, то использовать динамическое тестирование можно и на полноценном приложении без дополнительных закупок, учётных записей и поддержки.
Если для динамического тестирования вместе с готовым приложением дополнительно выдать исходный код, процесс можно преобразить в интерактивный анализ (Interactive Application Security Testing, IAST). Применение методик также эффективно при публикации исходного кода, когда в публичные репозитории разработчик полностью выкладывает свои наработки. Это похоже на то, как если бы вы опубликовали собственные рецепты коктейлей и блюд, чтобы весь мир смог повторить ваш успех и порадовать гостей дома. Такой подход позволит широкому мировому сообществу участвовать в развитии, применять одновременно статические, динамические сканеры и их комбинации, но делать это необязательно – сканеры могут работать и on-premise, без транслирования ваших приложений и наработок за пределы компании. В любом случае, динамический сканер должен найти и подсветить уязвимые места, чтобы разработчики новой версии устранили проблему или чтобы ИТ-специалисты смогли поставить «заплатку» и просто не пропускать трафик в уязвимую сторону (обычно так делают, если это не влияет на функционирование приложения).
Применение DAST возможно параллельно процессу разработки, это позволяет намного быстрее проверить, существует ли уязвимость уже сейчас, а также посмотреть, можно ли её предотвратить в будущем. Выбирать сканер нужно с учётом технологий, языков и фреймворков, которые применяются при разработке. Обычно, чем больше команда разработки и компания в целом, тем параметров становится больше, поэтому тестирование решений может проводится в течение нескольких месяцев и даже лет, но результат точно позволит снизить все риски.
