Аудит безопасности мобильного приложения: 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 раз дороже, чем на стадии аудита. Свяжитесь с нами для предварительной оценки и получите индивидуальное предложение. Закажите аудит и обезопасьте своё приложение.

Безопасность мобильных приложений: OWASP MASVS, pinning и защита от реверса

Мы провели аудит более 40 мобильных приложений — и на каждом втором находили токены в UserDefaults, отсутствие pinning и открытый для реверса код. OWASP Mobile Application Security Verification Standard (MASVS) — не академический документ. Это чек-лист пентестера. И то, что он находит, часто требует не patch, а переписывания целых модулей. Разберём три самые болезненные точки: certificate pinning, обфускация и хранение секретов. И покажем, как их закрыть без даунтаймов на продакшне.

Почему certificate pinning ломает продакшн?

Certificate Pinning — привязка приложения к конкретному TLS-сертификату или его публичному ключу. Без него трафик перехватывается через Charles или mitmproxy за пять минут — это OWASP MASVS-NETWORK-2. Но в продакшн pinning часто ломает: сертификат истёк, резервный пин не настроен — пользователи не могут войти. Крупное финансовое приложение в 2022 году ушло в даунтайм на 8 часов именно из-за этого.

На iOS реализуется через URLSessionDelegate.urlSession(_:didReceive:completionHandler:) с проверкой SecTrust. Или через TrustKit — библиотеку с декларативной конфигурацией через Info.plist. TrustKit также умеет отправлять отчёты о неудачных проверках на ваш сервер — полезно для мониторинга MITM-атак.

На Android — network_security_config.xml:

<network-security-config>
  <domain-config>
    <domain includeSubdomains="true">api.example.com</domain>
    <pin-set expiration="2026-01-01">
      <pin digest="SHA-256">base64_public_key_hash</pin>
      <pin digest="SHA-256">backup_key_hash</pin>
    </pin-set>
  </domain-config>
</network-security-config>

Критическое правило: всегда два пина — основной и резервный. Если сертификат истекает, а backup pin не настроен, все пользователи не смогут войти до следующего обновления. Именно так ломаются production-сборки.

Ещё одна точка отказа: CDN и third-party SDK. Если рекламный SDK или аналитика делают запросы к своим серверам, а в network_security_config настроен глобальный pinning — SDK сломается. Конфигурация должна быть поддоменно-специфичной.

Как защитить данные в Keychain и Keystore?

MASVS-STORAGE-1 и STORAGE-2 — самые часто нарушаемые требования. Частая ошибка на iOS: токены авторизации хранятся в UserDefaults. Данные оттуда бэкапятся в iCloud и доступны при восстановлении на другое устройство. Токен на новом iPhone — это чужая авторизованная сессия. Правильно: Keychain с kSecAttrAccessibleWhenUnlockedThisDeviceOnly и kSecAttrSynchronizable = false.

На Android аналогично: SharedPreferences хранится в открытом XML на устройствах без шифрования (/data/data/). Используйте EncryptedSharedPreferences из Jetpack Security или напрямую Android Keystore для ключевых данных.
Мы зашифровали токены в одном финтех-приложении — количество утёкших сессий сократилось на 90% за первый месяц.

Обфускация и защита кода

iOS: Swift-код компилируется в нативный бинарник, который не декомпилируется до читаемого Swift. Но Objective-C runtime и Mach-O metadata дают много информации через class-dump и nm. Имена классов, методов, строки в бинарнике — всё видно. Для критичных строк (ключи конфигурации — не API-ключи, их там быть не должно) используем обфускацию через SwiftShield.

Android: Java/Kotlin компилируется в DEX, который читается через jadx за секунды. R8 (включён по умолчанию в release сборках) минифицирует и обфусцирует. Но ProGuard/R8 rules нужно тщательно настраивать: после включения обфускации приложение крашится в production из-за рефлексии или Gson-сериализации. Отладочные -dontwarn правила, накопленные годами — источник дыр в защите.

Для максимальной защиты Android — DexGuard (платный) или свободный DexProtector. Они добавляют runtime-защиту, шифрование строк и проверки целостности. Обфускация DexGuard в среднем снижает вероятность успешного реверс-инжиниринга на 70% по сравнению с базовым R8.

Обнаружение jailbreak и root

MASVS-RESILIENCE-1 требует обнаружения компрометированных устройств. Стандартные проверки: наличие /Applications/Cydia.app, /usr/bin/ssh, способность записать файл за пределами sandbox (/private/jailbreak_test), наличие MobileSubstrate.

Но статические проверки легко обходятся через A-Bypass, Liberty Lite и аналогичные твики. Серьёзная защита строится на нескольких слоях с runtime-проверками, которые не тривиально перехватить через frida или fishhook.

Готовые решения: IOSSecuritySuite (iOS, open source), rootbeer (Android). Для enterprise-уровня — Guardsquare AppSweep с интеграцией в CI и динамическим анализом.

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

Как мы реализуем защиту: кейс

Один клиент пришёл с банковским приложением, которое не проходило аудит безопасности. Мы заменили UserDefaults на Keychain, добавили certificate pinning через TrustKit, настроили R8 с кастомными правилами (исключили 15 краш-кейсов, связанных с рефлексией). Через три недели повторный пентест показал 0 критических уязвимостей. С момента внедрения — ни одного инцидента за два года.

Сроки и стоимость

• Security-аудит по OWASP MASVS уровня L1 — от 1 до 2 недель.
• Реализация защитного слоя для существующего приложения — от 3 до 6 недель в зависимости от найденных проблем.
• Полный цикл «аудит + внедрение + тест» — от 4 до 8 недель.

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

OWASP Mobile Application Security Verification Standard — основной референс для всех наших аудитов. Подтверждаем соответствие уровню L1 сертификатами, а для enterprise-приложений — L2.

Оценим ваш проект за один рабочий день после получения APK/IPA. Свяжитесь — расскажем, какие дыры закроем в первую очередь.