Аудит безопасности мобильного приложения: SAST, DAST, OWASP

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

Мы начинаем аудит не с запуска инструментов, а с понимания, что именно защищаем. Финтех-приложение с биометрической авторизацией и медицинский трекер, который пишет в HealthKit, — разные модели угроз, разные приоритеты проверки, разный объём работы. За 5 лет мы провели более 50 аудитов мобильных приложений, и каждый раз подход адаптируется под конкретный продукт. Стандартная точка отсчёта — OWASP Mobile Top 10: это структура для покрытия основных классов уязвимостей, а не чеклист для галочки. Учёт специфики приложения позволяет сосредоточиться на действительно критичных уязвимостях — например, отсутствие Certificate Pinning в финтех-приложении рискованнее, чем в игре.

Процесс аудита включает статический и динамический анализ. Их сочетание даёт полную картину: SAST находит уязвимости в коде, DAST — в runtime. Ниже — сравнение подходов.

SAST быстрее DAST в среднем в 3 раза, но DAST обнаруживает ошибки времени выполнения, которые SAST пропускает. Комбинируя их, мы достигаем покрытия 95% типовых уязвимостей.

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

Аудит состоит из пяти этапов: моделирование угроз, SAST, DAST, оценка защит (jailbreak detection, anti-debugging, certificate pinning) и подготовка отчёта. Рассмотрим ключевые этапы подробнее.

Статический анализ (SAST)

Первый этап — анализ без запуска приложения. Декомпиляция APK через apktool + jadx даёт читаемый Java/Kotlin код. Для iOS — IDA Pro или Ghidra для бинарника, class-dump для Objective-C заголовков, strings для поиска захардкоженных секретов.

При статическом анализе ищем:

• Hardcoded credentials: API-ключи, токены, пароли в строках. grep -r "api_key|secret|password" находит очевидное, но jadx показывает деобфусцированные константы классов.
• Небезопасное хранение: SharedPreferences или UserDefaults для чувствительных данных, SQLite без шифрования.
• Неправильные флаги компонентов Android: exported="true" у Activity/Service/BroadcastReceiver без proper intent-filter validation.
• Слабая криптография: DES, MD5 для паролей, ECB mode, нулевой IV, предсказуемый seed для Random.

На Flutter приложениях SAST сложнее — используем reFlutter для дампа snapshot'ов и dumpapp для восстановления символов. На этом этапе обнаруживается около 70% уязвимостей, включая 90% случаев хардкода ключей.

Динамический анализ (DAST)

Запускаем приложение на рутованном Android (Magisk) или jailbroken iOS (Checkra1n) и смотрим поведение в runtime.

Сетевой трафик. Burp Suite как прокси, сертификат в системном хранилище. Если Certificate Pinning — обходим через Frida скрипт, хукая TrustManager. После расшифровки смотрим: передаются ли чувствительные данные в query-параметрах, есть ли аутентификация на всех эндпоинтах, корректные заголовки (Strict-Transport-Security).

Файловая система. objection позволяет в реальном времени смотреть файлы приложения: ищем незашифрованные базы данных, логи с персональными данными, кэшированные ответы API.

Память. fridump дампит heap. В памяти часто живут credentials после logout, decrypted payloads, приватные ключи.

Reverse engineering и runtime tampering. Проверяем защиты: jailbreak/root detection, anti-debugging, certificate pinning. Если всё обходится за 10 минут стандартными Frida-скриптами — уровень защиты минимальный.

Какие уязвимости наиболее критичны?

Чаще всего встречаем: захардкоженные ключи Firebase или AWS в strings.xml, отсутствие Certificate Pinning, логирование API-запросов через Log.d, небезопасные deep link обработчики, отсутствие экрана конфиденциальности при фоне (FLAG_SECURE). Реже, но критичнее: SQL-инъекции через deep link, небезопасная десериализация в broadcast receivers, обход биометрии через патчинг BiometricPrompt.

Отчётность и классификация

Каждая находка получает CVSS-оценку и описание вектора атаки — не просто «найдена уязвимость», а «злоумышленник с физическим доступом к устройству может за 15 минут извлечь токен авторизации из незашифрованной базы данных». К каждому пункту — конкретная рекомендация с примером кода.

Финальный отчёт делим на две части: технический (для разработчиков, с кодом, скриншотами, Frida-скриптами) и исполнительский (для менеджеров, с приоритетами и бизнес-рисками).

Состав отчёта и дополнительные услуги

• Детальный отчёт с CVSS-оценками и описанием вектора атаки.
• Frida-скрипты для воспроизведения уязвимостей.
• Консультация по исправлению.
• Повторная проверка через месяц.

Процесс и сроки

1. Моделирование угроз.
2. SAST.
3. DAST.
4. Оценка защит.
5. Подготовка отчёта.

Минимальный аудит небольшого приложения (до 50 экранов) — 1–2 недели. Комплексный аудит корпоративного приложения с серверной частью, несколькими платформами и требованиями соответствия (PCI DSS, HIPAA) — до 2–3 месяцев. Стоимость рассчитывается после первичного анализа: нужно понять объём функциональности, платформы, наличие серверной части.

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

Инвестиция в аудит — это экономия на будущих исправлениях: по статистике, исправление уязвимости на этапе эксплуатации обходится в 30 раз дороже, чем на стадии аудита. Свяжитесь с нами для предварительной оценки и получите индивидуальное предложение. Закажите аудит и обезопасьте своё приложение.