Информационная безопасность
Безопасность мобильных приложений
HackerOne Mobile Security Report 2023: мобильные приложения получают в среднем на 37% больше высокосерьёзных отчётов чем веб-приложения. Причина: разработчики привыкли что server-side защита отвечает за безопасность, а mobile - только UI. Но mobile приложение работает в руках потенциального атакующего: декомпилируется за минуты, трафик перехватывается через proxy, данные читаются на rooted устройстве. Угроза модель другая.
- **Uber 2019:** tokens хранились в UserDefaults без шифрования - bug bounty репорт показал чтение через jailbroken iPhone за 2 минуты
- **Banking apps (OWASP research 2022):** 40% банковских приложений не используют certificate pinning - трафик перехватывался через Burp Suite
- **Revolut bug bounty:** 25 000 долларов за обнаружение API endpoint без AuthZ в мобильном приложении - доступ к чужим транзакциям
Certificate Pinning: защита от MiTM
TLS защищает трафик, но доверяет любому CA из системного хранилища - их там 100+. Атакующий с доступом к устройству (корпоративный MDM, rooted device) устанавливает собственный CA и перехватывает зашифрованный трафик. **Certificate Pinning** фиксирует конкретный сертификат или public key в коде приложения.
**Всегда два pin:** основной и backup. Если сертификат сервера меняется (плановая ротация, инцидент), приложение перестаёт работать до обновления. Backup pin = следующий сертификат в цепочке (intermediate CA) или pre-pinned будущий сертификат. Инцидент Cloudflare 2022: certificate mismatch вывел часть мобильного трафика.
**Android Network Security Config** (API 24+) - декларативный pinning без кода: `res/xml/network_security_config.xml`. Проще, чем код, но менее гибкий. Требует обновления приложения при ротации сертификата.
Certificate pinning настроен. Security researcher с rooted Android устанавливает свой CA. Pinning обойти?
Root/Jailbreak Detection
Root/jailbreak открывает устройство для анализа приложения: Frida для hooking, Objection для bypass, r2frida для анализа памяти. Banking, payment, DRM-приложения используют root detection как дополнительный слой защиты. Не абсолютная защита - определённые методы обходятся - но повышает стоимость атаки.
**SafetyNet / Play Integrity API (Google)** - server-side attestation: устройство отправляет подписанный Google сертификат, что не рутировано и не эмулируется. Сложнее обойти чем client-side проверки. Apple DeviceCheck / App Attest - аналог для iOS. Используется в banking apps.
Root detection обнаружена. Приложение сразу крашит (force close). Правильный подход?
Secure Storage: данные на устройстве
OWASP Mobile Top 10 #2 - Insecure Data Storage. SharedPreferences/UserDefaults, SQLite без шифрования, файлы во внешнем хранилище - всё читается на rooted/jailbroken устройстве. Токены, ключи, личные данные - должны быть в защищённых хранилищах платформы.
| Хранилище | Платформа | Безопасность | Когда использовать |
|---|---|---|---|
| Keychain | iOS | Высокая (Secure Enclave) | Токены, пароли, ключи |
| Android Keystore | Android | Высокая (TEE/StrongBox) | Ключи шифрования |
| EncryptedSharedPreferences | Android | Средняя | Настройки, некритичные данные |
| SharedPreferences / UserDefaults | Обе | Низкая (plain XML) | Только non-sensitive |
| SQLCipher | Обе | Высокая | Зашифрованные БД |
Access token хранится в UserDefaults (iOS). Устройство jailbroken. Что произойдёт?
Obfuscation и anti-tampering
APK/IPA можно декомпилировать: jadx для Android, class-dump для iOS. Без обфускации атакующий видит имена классов, методов, строки - бизнес-логику, API endpoints, hardcoded secrets. Обфускация не предотвращает анализ, но значительно повышает его стоимость.
**Hardcoded secrets в коде** - OWASP Mobile Top 10 #6. После декомпиляции видны API keys, encryption keys, URLs внутренних API. Решение: secrets через remote config при запуске, certificate pinning для запросов к config endpoint, root detection перед получением secrets.
Мобильное приложение безопасно если его сложно декомпилировать
Security through obscurity - слабая защита. Настоящая безопасность: sensitive данные остаются на сервере, минимально необходимые rights, keychain/keystore для secrets, certificate pinning, server-side validation всех действий.
Достаточно мотивированный атакующий всегда декомпилирует приложение. Архитектура безопасности должна предполагать что клиент скомпрометирован (zero trust). Сервер не должен доверять клиенту без верификации.
Обфускация включена. Атакующий запускает приложение через Frida. Помогает ли обфускация?
Ключевые идеи
- **Certificate Pinning:** фиксирует конкретный public key в коде. Всегда два pin (основной + backup). Защищает от MiTM, но не от Frida на rooted устройстве
- **Root Detection:** несколько методов + Play Integrity API. Degraded mode лучше crash: отключить чувствительные функции, уведомить сервер
- **Secure Storage:** токены только в Keychain (iOS) / Android Keystore. SharedPreferences / UserDefaults - только non-sensitive настройки
- **Obfuscation:** защита от статического анализа, не от Frida. Архитектура: сервер не доверяет клиенту, все операции верифицируются server-side
Связанные темы
Mobile security строится на тех же принципах что и server-side, но с другой моделью угроз:
- Аутентификация и авторизация — Мобильный AuthN: биометрия + Keychain tokens + certificate pinning
- Шифрование данных — Keychain/Keystore используют те же AES/RSA примитивы для хранения
- Безопасность API — Mobile backend API: те же требования к AuthN, rate limiting, input validation
Вопросы для размышления
- Где хранятся access tokens в мобильном приложении? Keychain/Keystore или UserDefaults/SharedPreferences?
- Реализован ли certificate pinning? Есть ли backup pin для случая ротации сертификата?
- Можно ли перехватить трафик мобильного приложения через Charles или Burp Suite без специальных инструментов?