Аудит безопасности мобильного приложения: методика оценки рисков

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

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

OWASP MASVS задаёт требования, MASTG помогает их проверить

OWASP MASVS описывает требования к безопасности мобильных приложений. Он делит их на два основных уровня: MASVS-L1 — базовый уровень для приложений общего назначения; MASVS-L2 — усиленные требования для продуктов, работающих с критичными или финансовыми данными. Отдельно выделен профиль MASVS-R, связанный с устойчивостью к реверс-инжинирингу и взлому.

Эти уровни помогают определить объём проверки, но не выдают сертификат неуязвимости. MASVS-L1 задаёт разумную нижнюю границу, а не магический щит от целевой атаки. Для банковского приложения, медицинского сервиса и корпоративного мессенджера профиль требований будет различаться. Выбирать его стоит исходя из данных, функций и модели угроз, а не из желания поставить в презентации красивую отметку.

Технические способы проверки описаны в OWASP MASTG — руководстве по тестированию и реверс-инжинирингу мобильных приложений. Оно помогает проверить выполнение требований MASVS и исследовать слабые места, в том числе сопоставляя их с категоризацией MASWE. В рабочем аудите связка выглядит так: MASVS формулирует, что должно быть защищено; MASTG подсказывает, как это тестировать; результаты фиксируют конкретные дефекты и сценарии их эксплуатации.

На практике аудит охватывает не только код приложения. Проверяют, как клиент хранит токены и другие чувствительные данные, какие разрешения запрашивает, как проверяет TLS-соединения, что раскрывает в логах, как устроены механизмы аутентификации и контроля доступа. Отдельный фронт — API: мобильный интерфейс может быть аккуратным, пока сервер без вопросов отдаёт данные по изменённому идентификатору записи.

Для каждой проверки полезно заранее зафиксировать область аудита:

• платформы и версии приложения, включая тестовые и производственные сборки;
• функции, связанные с входом, восстановлением доступа, оплатой и персональными данными;
• API, внешние SDK, аналитические библиотеки и каналы передачи данных;
• выбранный уровень MASVS и причины, по которым он подходит продукту;
• ограничения тестирования, например тестовые аккаунты, запрет на нагрузочные проверки или доступ только к отдельному контуру.

Без такого описания отчёт часто превращается в каталог замечаний без ответа на главный вопрос: какой риск закрывает каждое исправление.

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

Black box, Gray box и White box: глубина аудита зависит от доступа

Формат тестирования определяет, сколько информации получает аудитор и какие дефекты ему проще обнаружить. Black box проводится без исходного кода и внутренних данных. Gray box предполагает ограниченный доступ, например тестовые учётные записи и документацию по API. White box даёт доступ к коду и архитектуре.

Black box полезен, когда нужно понять, что доступно внешнему нарушителю без привилегий. Но отсутствие находок в таком тесте не означает, что внутри приложения всё чисто. Аудитор не увидит часть логики и может не пройти сценарии, требующие специальных ролей.

Gray box обычно даёт практичный баланс для тестирования мобильных сервисов на проникновение. Тестовые аккаунты позволяют проверять границы ролей и действия с чужими объектами. Например, можно выяснить, ограничивает ли сервер доступ к заказу текущим пользователем или доверяет идентификатору, который прислал клиент. Именно такие ошибки в API сканер часто не понимает: запрос выглядит корректно, а нарушение живёт в правилах доступа.

White box позволяет сопоставить наблюдаемое поведение с реализацией. Можно искать в исходниках ключи, небезопасное хранение данных, ошибочные проверки сертификатов, слабую обработку ошибок. Но результат зависит от охвата: проверили только Android, забыли iOS; посмотрели основной модуль, пропустили SDK; разобрали код, не проверили серверную авторизацию. Формально доступ полный, фактически картина дырявая.

Для многих продуктов разумна комбинация подходов. Статический анализ кода ускоряет поиск типовых проблем, динамическое исследование показывает поведение приложения, а проверка API и бизнес-сценариев выявляет дефекты, которые не видны в отдельных файлах. Автоматический сканер здесь полезен как сито. Считать его аудитором — способ получить красивый отчёт и пропустить реальную дыру.

Оценка риска: вероятность плюс ущерб

OWASP Risk Rating Methodology предлагает оценивать риск через вероятность эксплуатации и воздействие: Risk = Likelihood × Impact. Это не попытка получить научно точное число из тумана. Модель нужна, чтобы команда одинаково рассуждала о находках и не ставила рядом утечку платёжных данных и косметическую ошибку в отладочном сообщении.

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

Воздействие оценивают по техническому и бизнес-ущербу. Техническая сторона включает конфиденциальность, целостность и доступность данных и функций. Бизнес-сторона — последствия для пользователей и оператора: компрометация аккаунтов, несанкционированные операции, нарушение процессов, регуляторные и репутационные последствия. Последние не следует подменять произвольной суммой ущерба, если у компании нет обоснованной модели такого расчёта.

Разберём типовую находку без выдуманной статистики: приложение сохраняет долговременный токен в доступном для извлечения виде. Сам факт хранения ещё не описывает риск полностью. Аудитор выясняет, можно ли получить данные при обычном доступе к устройству, действует ли токен после выхода из аккаунта, ограничены ли его права, как быстро он отзывается и какие операции доступны с его помощью. Затем оценивает масштаб последствий, если токен попадёт в чужие руки.

В результате приоритет складывается из контекста. Уязвимость с высокой вероятностью эксплуатации и доступом к чувствительным операциям требует срочного исправления. Дефект, который можно использовать только в редких условиях и который не раскрывает значимые данные, может получить более низкий приоритет. Но его всё равно документируют: низкий риск сегодня иногда становится удобной ступенькой после изменения архитектуры.

В отчёте по каждой находке нужны воспроизводимые сведения:

1. Компонент и версия, где обнаружен дефект.

2. Условия, необходимые для его эксплуатации.

3. Последовательность действий и техническое подтверждение результата.

4. Какие данные или функции затрагиваются.

5. Оценка вероятности и воздействия с объяснением выставленного уровня.

6. Рекомендуемое исправление и способ повторной проверки.

Формулировка вроде «обнаружена слабая криптография» мало помогает разработчику. Нужны конкретный алгоритм или место его применения, сценарий использования и условия, при которых проблема влияет на защиту данных. Иначе команда либо не поймёт, что чинить, либо заменит одну библиотеку другой, оставив архитектурную дыру нетронутой.

Инструменты: сканер находит подозрительное, аудитор проверяет смысл

Инструменты статического анализа кода проверяют исходники без запуска приложения. Они могут подсветить опасные вызовы, встроенные секреты, небезопасные настройки и участки, требующие ручной проверки. Это хороший способ ускорить первичный разбор больших репозиториев. Это плохой повод объявить безопасность проверенной.

Статический анализ зависит от правил и контекста. Он может отметить безопасный код как проблему, пропустить дефект в сложной логике или не понять, что ключ, выглядящий как случайная строка, даёт доступ к производственному ресурсу. Результаты нужно сортировать: подтверждать находки, отсекать ложные срабатывания и связывать дефекты с реальным поведением приложения.

Динамический анализ исследует приложение во время работы. Проверяют сетевые запросы, реакцию на изменение среды, хранение данных, обработку ошибок, поведение с разными ролями. Исследование Android-сборки может включать просмотр манифеста и разрешений, анализ ресурсов и компонентов, изучение сетевого обмена и проверку того, что остаётся на устройстве после завершения сессии. Для iOS набор технических приёмов отличается, но логика та же: проверить фактическую поверхность атаки, а не только намерения разработчика.

MASTG здесь полезен как практический ориентир: он систематизирует подходы к тестированию мобильных приложений и помогает связать технические проверки с требованиями MASVS. Сам по себе документ не запускает тесты и не принимает решения за команду. Результат зависит от того, насколько точно аудитор выбрал тестовые сценарии и насколько полно проверил приложение и его серверную сторону.

API заслуживает отдельной программы испытаний. Проверяют аутентификацию и авторизацию на каждом значимом действии, ограничение доступа к объектам, обработку токенов, повторное использование запросов и защиту чувствительных операций. Клиентскую проверку роли легко обойти модифицированной сборкой. Поэтому сервер должен независимо проверять, имеет ли пользователь право на каждую запрошенную операцию. Если право проверяется только в интерфейсе, это не контроль доступа, а декорация.

По той же причине нельзя ограничиваться проверкой TLS и наличия шифрования. Шифрование канала не исправит чрезмерные права токена, открытый API или утечку данных через логи. Защита на устройстве тоже не отменяет серверных ошибок. Слои должны закрывать разные сценарии, а не изображать друг друга.

CVSS помогает сравнивать дефекты, но не заменяет контекст

CVSS — стандартизированная система оценки критичности уязвимостей, поддерживаемая FIRST. Её применяют для оценки CVE-дефектов и сопоставления технической серьёзности. Шкала полезна, когда команде нужно единообразно описывать уязвимость и понимать её базовые характеристики.

Однако CVSS и оценка риска конкретного продукта отвечают на разные вопросы. CVSS описывает свойства уязвимости по заданной модели. OWASP Risk Rating позволяет рассматривать вероятность и воздействие в контексте приложения и бизнеса. Одинаковый технический дефект может иметь разные последствия в зависимости от доступных данных, прав пользователя и архитектуры сервиса.

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

Ещё одна ловушка — свести все находки к одному рангу без обоснования. Для продуктовой команды важны не только уровень критичности, но и масштаб затронутых версий, условия эксплуатации, наличие обходного решения и стоимость исправления. Последний пункт не должен превращаться в индульгенцию: дорогое исправление не снижает риск, оно лишь требует осознанного решения о сроках и временных мерах защиты.

Как превратить отчёт в исправления

Аудит завершён только тогда, когда находки устранены и проверены повторно. Сам отчёт не закрывает эксплойт, даже если в нём много таблиц и аккуратные CVSS-баллы. Для каждой проблемы назначают владельца, срок и критерий завершения. После исправления проверяют не только конкретный дефект, но и соседние сценарии, где могла повториться та же ошибка проектирования.

Практический порядок работы выглядит так:

1. Зафиксировать активы, версии приложения, API и бизнес-сценарии, которые входят в область аудита.

2. Выбрать профиль MASVS и формат доступа, объяснив, почему они подходят модели угроз.

3. Составить план тестов по MASTG: клиент, локальное хранение, сеть, аутентификация, авторизация и серверные операции.

4. Провести автоматизированный и ручной анализ, подтверждая находки воспроизводимыми доказательствами.

5. Оценить каждую уязвимость по вероятности и воздействию; при необходимости отдельно привести CVSS.

6. Назначить исправления и повторно проверить сборку и затронутые API после изменений.

Политика безопасной разработки должна закреплять регулярный анализ кода, проверку зависимостей и контроль доступа в API. Для релиза нужны критерии блокировки: подтверждённые критические дефекты не уезжают в производство под обещание исправить их когда-нибудь. Отдельно определяют правила хранения токенов, обработки персональных данных, логирования и отзыва скомпрометированных учётных данных. Эти требования проверяют в сборках, а не оставляют в корпоративной вики как талисман.

Итоговая методика проста по форме и требовательна к исполнению: требования задаёт MASVS, способы проверки описывает MASTG, риск связывает вероятность с ущербом, а CVSS помогает стандартизировать оценку технической критичности. Сканеры ускоряют работу, ручной анализ проверяет логику, повторное тестирование подтверждает исправление. Если команда ограничилась сканом и красивым отчётом, аудит закончился раньше, чем началась защита.