Аудит безопасности мобильного приложения (OWASP Mobile Top 10)
OWASP Mobile Top 10 — структурированный список наиболее критичных классов уязвимостей мобильных приложений. Аудит по этому стандарту не означает формальную проверку чеклиста — каждый пункт требует активного тестирования, которое адаптируется под конкретную архитектуру приложения.
M1: Improper Credential Usage
Ищем захардкоженные credentials: API-ключи в коде, пароли в конфигурационных файлах, токены в git-истории. Инструменты: jadx + grep, truffleHog для репозитория, анализ AndroidManifest.xml и Info.plist.
Проверяем хранение: credentials в SharedPreferences/UserDefaults — уязвимость. Должно быть в Android Keystore / iOS Keychain. На jailbroken устройстве читаем Keychain через objection keychain dump — смотрим что там хранится и с какими атрибутами доступа.
M2: Inadequate Supply Chain Security
Сторонние зависимости — часто самое слабое место. Проверяем: версии библиотек на известные CVE (OWASP Dependency-Check, gradle dependencyInsight, pod-outdated), использование библиотек из ненадёжных источников, разрешения, которые запрашивают SDK аналитики и рекламы.
Отдельно — CI/CD пайплайн: есть ли secret scanning в репозитории, подписание артефактов сборки, проверка целостности зависимостей через hash verification.
M3: Insecure Authentication/Authorization
Тестируем: обход экрана авторизации через deep links (передаём параметры в URL, которые должны быть доступны только авторизованным пользователям), горизонтальное повышение привилегий (авторизованный пользователь A обращается к данным пользователя B, меняя user_id в запросе), отсутствие ревалидации сессии при критических операциях.
На практике часто находим: deep link myapp://reset-password?token=XXX обрабатывается без проверки источника intent'а — любое приложение может отправить такой intent и инициировать сброс пароля. Или: смена email в профиле не требует подтверждения текущего пароля.
M4: Insufficient Input/Output Validation
На мобильном клиенте особенно актуальны: SQL-инъекции через параметры deep links или WebView URL, XSS в WebView с setJavaScriptEnabled(true), path traversal при работе с файлами (URL типа ../../etc/passwd в параметрах загрузки файла), небезопасная десериализация в Intent extras.
// уязвимый код — принимает Intent extras без валидации
String fileName = getIntent().getStringExtra("file_name");
File file = new File(getExternalFilesDir(null), fileName);
// fileName = "../../../../../../data/data/com.other.app/secret.db"
M5: Insecure Communication
Проверяем через Burp Suite proxy:
- Наличие HTTPS для всех эндпоинтов
- Certificate Pinning (обходим через Frida
ssl-unpinning.js) - Данные в GET-параметрах URL (логируются серверами, прокси, CDN)
- Небезопасные WebSocket соединения
- Утечка чувствительных данных в заголовках запросов
network_security_config.xml на Android — проверяем cleartextTrafficPermitted, наличие пользовательских CA в trust-anchors. Если debug-overrides разрешает cleartext — убеждаемся, что это только для debug builds.
M6: Inadequate Privacy Controls
Права доступа: приложение запрашивает ACCESS_FINE_LOCATION постоянно, хотя геолокация нужна только в конкретном сценарии? Или READ_CONTACTS без видимой функции работы с контактами? Анализируем соответствие запрашиваемых разрешений декларируемой функциональности.
Логи: adb logcat часто выдаёт PII в продакшн-билде. Проверяем наличие чувствительных данных в logcat, Crashlytics/Sentry сообщениях (стектрейс может содержать user data), аналитических событиях.
M7: Insufficient Binary Protections
Декомпилируем APK через jadx, IPA через Ghidra. Оцениваем:
- Читаемость бизнес-логики после декомпиляции
- Наличие/качество обфускации (R8/ProGuard/DexGuard)
- Строковые константы в plaintext
- Debug-флаги в продакшн-билде (
BuildConfig.DEBUG,debuggableв манифесте) - Наличие anti-tampering проверок
M8: Security Misconfiguration
Android: android:debuggable="true" в продакшн манифесте открывает отладочный доступ. android:allowBackup="true" позволяет adb backup на Android < 12 — из бэкапа читаются SharedPreferences, базы данных. exported="true" у компонентов без проверки intent.
iOS: ATS (App Transport Security) отключён через NSAllowsArbitraryLoads. Entitlements: избыточные capabilities (например, com.apple.developer.icloud-container-identifiers у приложения, которое не использует iCloud).
M9: Insecure Data Storage
Полная ревизия хранилищ данных на устройстве:
| Хранилище | Что ищем | Инструмент |
|---|---|---|
| SQLite БД | чувствительные данные, отсутствие шифрования | objection, sqlite3 |
| SharedPreferences / UserDefaults | пароли, токены, ключи | objection data storage |
| Keychain (iOS) | атрибуты доступа, что именно хранится | objection keychain dump |
| Файловая система | незашифрованные документы, кэш ответов API | objection files ls |
| Буфер обмена | автокопирование чувствительных данных | ручное тестирование |
Буфер обмена — часто упускаемая уязвимость: приложение копирует номер карты или пароль в clipboard, другое приложение его читает. На iOS 14+ нужен explicit UI для доступа к clipboard, но проверяем.
M10: Insufficient Cryptography
Слабые алгоритмы: DES, 3DES, RC4, MD5 для паролей, ECB mode для блочных шифров, предсказуемый seed в java.util.Random вместо SecureRandom, нулевой или фиксированный IV, отсутствие MAC (используется AES-CBC без HMAC).
Реализации кастомной криптографии вместо стандартных библиотек — красный флаг. «Своя крипта» почти всегда сломана.
Отчёт и приоритизация
По каждой из 10 категорий фиксируем: найдено/не найдено, конкретные экземпляры уязвимостей с CVSS оценкой, шаги для воспроизведения, рекомендации с примерами кода. Приоритеты: Critical (эксплуатируется без рута/jailbreak, прямой доступ к данным) → High → Medium → Low (информационные находки).
Аудит типичного приложения среднего масштаба по OWASP Top 10 — 3–5 рабочих дней. Включает статический анализ, динамическое тестирование на рутованном Android и jailbroken iOS, анализ трафика. Объём документации — согласно требованиям заказчика.