Supply Chain Security
Узнать большеПо данным ГК «Солар», 54% приложений содержат хотя бы одну критичную уязвимость, которая может стать точкой входа для хакеров. Злоумышленники могут воспользоваться уязвимостями или недостатками в коде, чтобы нарушить работу приложения, похитить персональные и платежные данные пользователей и навредить репутации компании. Наличие уязвимостей и недекларированных возможностей в коде ПО также может негативно сказаться на качестве работы приложения, его производительности и других характеристиках. Чтобы избежать таких проблем, важно внедрить цикл безопасной разработки ПО с применением инструментов анализа кода на разных этапах, в том числе, на этапе готового приложения. Для этих целей отлично подходит динамический анализ кода — Dynamic Application Security Testing. Разберемся, что это такое, как он встраивается в цикл безопасной разработки и какие сильные и слабые стороны имеет.
Dynamic Application Security Testing: понятие и краткое описание
Это динамическая проверка ПО, которая реализуется, когда уже есть готовое развернутое ПО, то есть помогает исследовать завершенный продукт. Суть метода — имитация атак на готовые программы для поиска небезопасных мест. Для проведения такого анализа не нужно иметь доступ к исходному коду приложения и детально погружаться в его структуру, поэтому динамическую проверку относят к проверкам методом «черного ящика», то есть, когда перед нами условный закрытый черный ящик, мы не знаем, что там внутри и можем действовать только извне.
DAST применяется для проверки как общедоступных веб-сервисов и ориентированных на массовую аудиторию приложений, так и внутренних систем, которые используются сотрудниками.
Динамическое тестирование обычно автоматизировано и реализуется с помощью специальных инструментов. В зависимости от поставленных задач они могут имитировать реальные пользовательские действия, «простукивать» интерфейсы программ, отправлять запросы и т.д.
DAST легко и эффективно внедряется в процесс безопасной разработки программного обеспечения — DevSecOps. Его применение не замедляет скорость создания продуктов и обновление готовых версий, а даже наоборот — позволяет оперативно исправить ошибки и без задержек выпустить решение на рынок.
Какие задачи решает динамический анализ кода
DAST может быть полезен в следующих ситуациях:
- На финальных этапах разработки приложения. Разработчики приложений заинтересованы в том, чтобы выпустить на рынок удобное для пользователей, функциональное и желательно безопасное ПО. Благодаря динамическому анализу можно еще до релиза выявить и устранить недостатки кода.
- Для проверки готового приложения, выпущенного сторонними разработчиками, например подрядчиками. DAST можно выполнить, если сервис есть в публичном доступе, даже если нет доступа к коду и нет информации о том, как устроен продукт.
- Для проверки наследованного программного обеспечения, если отсутствует доступ к исходному коду и продукт выпускался давно. Часто такие системы являются устаревшими и обновить их с целью устранения уязвимостей проблематично, поскольку разработчиков может уже не быть на рынке. Но безболезненно отказаться от использования такого обеспечения нельзя из-за критической важности для работы компании.
- Для выявления ошибок, не замеченных в процессе других проверок и проявляющихся только при запуске приложений в реальной среде.
Сильные и слабые стороны DAST
В качестве ключевых преимуществ динамического анализа можно выделить:
- Возможность тестировать программы при отсутствии доступа к исходному коду.
- Возможность обнаруживать проблемы, связанные с памятью. Например, DAST позволяет увидеть утечки памяти, выход за установленные объемы и т.д.
- Меньшее количество ложных срабатываний, поскольку динамическое тестирование не прогнозирует ошибки и уязвимости в программном обеспечении, а выявляет их по факту возникновения.
Как и у любого типа анализа, у Dynamic Application Security Testing есть и слабые стороны:
- Сложности с локализацией ошибок в исходном коде программы, поскольку динамическое тестирование все же ориентировано на выявление проблем именно в процессе эксплуатации ПО.
- Малый процент выявления логических ошибок, поскольку анализатор может воспринять проблему как истинное условие работы приложения.
- Необходимость имитировать рабочую среду для программного обеспечения. Стоит учитывать, что полностью воспроизвести ее не получится, так как это небезопасно из-за высоких рисков компрометации пользовательских данных.
- Невозможность полностью покрыть исходный код программы, из-за чего есть риск упустить часть уязвимостей.
- Значительные временные затраты, связанные со сложностью процесса тестирования.
Однако стоит понимать, что успешность проведения тестирования во многом зависит от используемого инструмента. Анализатор должен гибко настраиваться, безболезненно встраиваться в процесс безопасной разработки, обладать удобным и понятным интерфейсом, а также регулярно обновляться. Пример такого решения — Solar appScreener для комплексного контроля безопасности ПО, который включает в себя помимо DAST еще и другие виды анализа кода (SAST, SCA, SCS).
SAST или DAST: какой метод выбрать
Динамический анализ – это не единственный вид анализа, который используется разработчиками. Также активно применяют Static Application Security Testing (сокращенно — SAST) — проверку исходного кода ПО на наличие уязвимостей без необходимости запуска в рабочей среде. Статический анализ обеспечивает:
- Полное покрытие исходного кода в отличие от динамического тестирования, которое проверяет только исполняемый код.
- Отсутствие необходимости в больших вычислительных мощностях и разворачивании рабочих сред для тестирования.
- Простоту внедрения анализатора на любом этапе разработки ПО.
Использовать SAST в чем-то проще, чем DAST, поскольку для высокой эффективности динамического анализа нужно достаточно много входных данных, а для статического необходим только исходный код. Однако некоторые ошибки невозможно выявить на этапе анализа исходного кода, и тут на помощь приходит DAST.
Кроме того, методика статического анализа сопряжена с таким серьезным минусом, как ложноположительные срабатывания. То есть анализатор может указать на ошибку, которой по факту нет. Но программисту придется вручную проверять каждое срабатывание, а на это уходит достаточно много времени. В процессе динамического тестирования проблема ложных срабатываний значительно меньше.
Резюмируем — SAST и DAST созданы для выполнения своих конкретных задач, поэтому выбирать из них что-то одно – не самый эффективный подход. Идеально, если они будут комбинироваться и применяться в процессе разработки программного обеспечения на разных его этапах. Такой подход позволит выявить максимальное количество уязвимостей на разных этапах цикла создания ПО и обеспечит высокий уровень безопасности готовых продуктов.
При использовании анализатора Solar appScreener можно провести корреляцию результатов этих двух видов анализа и комплексно рассмотреть все обнаруженные уязвимости. Это позволит приоритизировать процессы обработки недочетов и в первую очередь устранить наиболее критичные проблемы.
Принцип работы DAST на примере анализатора Solar appScreener
Методика проведения тестирования зависит от выбранного инструмента. Рассмотрим схему, по которой работает наше решение Solar appScreener, позволяющее выявлять недекларированные возможности и уязвимости в готовых функционирующих приложениях. Инструмент работает путем передачи на вход программы случайно сгенерированных или заведомо неправильных сведений.
Инструмент включает пять методов динамического анализа: AJAX-веб-сканер, Fuzzer, традиционный, пассивный и активный сканеры. Расскажем, как происходит тестирование с помощью этих компонентов.
- AJAX-запросы — технология, с помощью которой можно обращаться к сервису без необходимости перезагрузки страницы динамическими методами, например, скрытого фрейма или XML http Request. Эти алгоритмы полезны для тестирования кнопок и форм, позволяющих совершать элементарные пользовательские действия: подписываться на обновления, добавлять товары в корзину, покупать в один клик и т.д. Как правило, все эти операции в приложениях осуществляются как раз без перезагрузки страницы.
- Инструменты фаззинга позволяют тестировать программы на неожиданный вход, чтобы проверить, будут ли ошибки или нетипичное поведение при выполнении приложения. Эта функция помогает работать с элементами страницы, для которых известны входные данные.
- Три вида сканеров в модуле DAST дают возможность выбрать режим атаки в зависимости от целей проверки. Традиционный, или стандартный режим сканирования предусматривает отсутствие ограничений в процессе тестирования. Агрессивный подразумевает тестирование новых узлов при их обнаружении. Активный режим позволяет инициировать атаки на этапе активного сканирования.
В модуле DAST Solar appScreener реализовано несколько способов авторизации на проверяемых сервисах. Анализатор может использовать указанные логины и пароли, токены аутентификации bearer, заголовки из Json-формы. Также инструмент работает с формами авторизации, подставляя в нужные поля выданные пользователем значения.
По результатам проверки Solar appScreener генерирует отчеты с описанием обнаруженных уязвимостей и недекларированных возможностей приложения с рекомендациями по их устранению.
