После обновления приложения в Google Play или App Store конкуренты получают доступ к базе пользователей. Или хакер через уязвимый deep link сбрасывает пароль администратора. Такие сценарии — результат отсутствия системного аудита безопасности. Наши инженеры с 5+ лет опыта и более 100 проведённых аудитов находят эти слабые места до того, как их найдут злоумышленники.
По данным OWASP, более 80% мобильных приложений содержат хотя бы одну уязвимость из Mobile Top 10. Устранение такой уязвимости на этапе разработки обходится в 30 раз дешевле, чем после релиза. Поэтому аудит до публикации — разумная инвестиция. Мы сочетаем статический и динамический анализ с ручным пентестом, чтобы покрыть все векторы атак. Ниже — как это работает.
Почему OWASP Mobile Top 10 — эталон для проверки?
OWASP Mobile Top 10 — не формальный чек-лист, а структурированный подход к активному тестированию. Каждый из 10 пунктов адаптируется под архитектуру приложения: мы не просто сверяемся со списком, а воспроизводим атаки в реальных условиях. Вот как мы это делаем.
Как мы ищем уязвимости: процесс в деталях
Начнём с самого частого источника риска — некорректного хранения секретов.
M1 и M2: Секреты, зависимости и цепочка поставок
Ищем захардкоженные credentials: API-ключи в коде, пароли в конфигурационных файлах, токены в git-истории. Инструменты: jadx + grep, truffleHog для репозитория, анализ AndroidManifest.xml и Info.plist. Проверяем хранение: credentials в SharedPreferences/UserDefaults — уязвимость. Должно быть в Android Keystore / iOS Keychain. На jailbroken устройстве читаем Keychain через objection keychain dump — смотрим, что там хранится и с какими атрибутами доступа.
Сторонние зависимости — часто самое слабое место. Проверяем версии библиотек на известные CVE (OWASP Dependency-Check, gradle dependencyInsight, pod-outdated), использование библиотек из ненадёжных источников, разрешения, которые запрашивают SDK аналитики и рекламы. Отдельно — CI/CD пайплайн: есть ли secret scanning в репозитории, подписание артефактов сборки, проверка целостности зависимостей через hash verification.
M3 и M4: Аутентификация, авторизация и ввод данных
Тестируем обход экрана авторизации через deep links (передаём параметры в URL, которые должны быть доступны только авторизованным пользователям), горизонтальное повышение привилегий (авторизованный пользователь A обращается к данным пользователя B, меняя user_id в запросе), отсутствие ревалидации сессии при критических операциях.
На практике часто находим: deep link myapp://reset-password?token=XXX обрабатывается без проверки источника intent — любое приложение может отправить такой intent и инициировать сброс пароля. Или смена email в профиле не требует подтверждения текущего пароля.
На мобильном клиенте особенно актуальны: 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 и M8: Коммуникации и конфигурация
Проверяем через Burp Suite proxy: наличие HTTPS для всех эндпоинтов, certificate pinning (обходим через Frida ssl-unpinning.js), данные в GET-параметрах URL (логируются серверами, прокси, CDN), небезопасные WebSocket соединения, утечка чувствительных данных в заголовках запросов. network_security_config.xml на Android — проверяем cleartextTrafficPermitted, наличие пользовательских CA в trust-anchors.
Safety Misconfiguration: 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).
M6, M7 и M9: Данные, бинарная защита и хранение
Права доступа: приложение запрашивает ACCESS_FINE_LOCATION постоянно, хотя геолокация нужна только в конкретном сценарии? Или READ_CONTACTS без видимой функции работы с контактами? Анализируем соответствие запрашиваемых разрешений декларируемой функциональности. Логи: adb logcat часто выдаёт PII в продакшн-билде. Проверяем наличие чувствительных данных в logcat, Crashlytics/Sentry сообщениях, аналитических событиях.
Декомпилируем APK через jadx, IPA через Ghidra. Оцениваем: читаемость бизнес-логики после декомпиляции, наличие и качество обфускации (R8/ProGuard/DexGuard), строковые константы в plaintext, debug-флаги в продакшн-билде (BuildConfig.DEBUG, debuggable в манифесте), наличие anti-tampering проверок.
Полная ревизия хранилищ данных на устройстве:
| Хранилище | Что ищем | Инструмент |
|---|---|---|
| SQLite БД | Чувствительные данные, отсутствие шифрования | objection, sqlite3 |
| SharedPreferences / UserDefaults | Пароли, токены, ключи | objection data storage |
| Keychain (iOS) | Атрибуты доступа, что именно хранится | objection keychain dump |
| Файловая система | Незашифрованные документы, кэш ответов API | objection files ls |
| Буфер обмена | Автокопирование чувствительных данных | Ручное тестирование |
M10: Слабая криптография
Слабые алгоритмы: DES, 3DES, RC4, MD5 для паролей, ECB mode для блочных шифров, предсказуемый seed в java.util.Random вместо SecureRandom, нулевой или фиксированный IV, отсутствие MAC (используется AES-CBC без HMAC). Реализации кастомной криптографии вместо стандартных библиотек — красный флаг. «Своя крипта» почти всегда сломана.
Что даёт аудит: результаты и приоритизация
По каждой из 10 категорий фиксируем: найдено/не найдено, конкретные экземпляры уязвимостей с CVSS оценкой, шаги для воспроизведения, рекомендации с примерами кода. Приоритеты: Critical (эксплуатируется без рута/jailbreak, прямой доступ к данным) → High → Medium → Low (информационные находки).
Как подготовиться к аудиту: 3 шага
- Соберите актуальные бинарные файлы (APK/IPA) и исходный код, если доступен.
- Предоставьте документацию: описание архитектуры, список сторонних библиотек, API-эндпоинты.
- Определите критичные сценарии: аутентификация, платежи, работа с персональными данными.
Сравнение методов тестирования
| Тип анализа | Время выполнения | Глубина покрытия | Доля выявляемых уязвимостей |
|---|---|---|---|
| Статический | 1–2 дня | Код + зависимости | 60–70% |
| Динамический | 2–3 дня | Runtime + сеть | 40–50% |
| Ручной пентест | 3–5 дней | Логика + бизнес | 80–95% |
Ручное тестирование выявляет до 95% уязвимостей — это на 30% больше, чем автоматический скрининг. Поэтому в нашем аудите сочетаются все три типа.
Аудит типичного приложения среднего масштаба по OWASP Top 10 — 3–5 рабочих дней. Включает статический анализ, динамическое тестирование на рутованном Android и jailbroken iOS, анализ трафика. Объём документации — согласно требованиям заказчика. Получите консультацию для оценки вашего приложения — наши эксперты свяжутся с вами в течение часа. Закажите аудит безопасности вашего мобильного приложения прямо сейчас.