Безопасность в мобильной разработке: что это, какие угрозы и как защищаться

Основные угрозы: OWASP Mobile Top 10

Что такое OWASP Mobile Top 10?

OWASP (Open Web Application Security Project) — некоммерческая организация, публикующая рейтинг самых опасных уязвимостей мобильной безопасности. OWASP Mobile Top 10 — это список, который помогает разработчикам понять, на что обращать внимание в первую очередь. В версии 2024 года лидируют проблемы, связанные с небезопасным хранением, слабой аутентификацией и небезопасной сетевой коммуникацией.

M1: Небезопасное хранение данных — самая частая проблема: пароли, токены и личные данные остаются в SharedPreferences, NSUserDefaults или локальных файлах без шифрования. M2: Слабая аутентификация — отсутствие проверки на стороне сервера, слабые пароли. M3: Небезопасная сетевая коммуникация — отсутствие HTTPS или неправильная проверка SSL-сертификата. M4 и M5 связаны с криптографией и неправильным использованием API.

M6: Небезопасная авторизация — пользователь может получить доступ к данным другого пользователя через подмену ID в запросе. M7: Инъекции кода (SQL Injection, XSS). M8: Манипуляции с приложением — репаккинг, подмена кода. M9 и M10 — утечка данных через сторонние библиотеки и обратная разработка. Для каждой из этих угроз существуют проверенные контрмеры, и в IT Sectr мы применяем их во всех проектах с 2017 года.

Man-in-the-Middle (MITM) атаки

MITM-атака (атака «человек посередине») происходит, когда злоумышленник перехватывает трафик между приложением и сервером. Это возможно через подмену DNS, ARP-спуфинг или подключение к незащищённой Wi-Fi-сети. Для защиты используются SSL/TLS-сертификаты и Certificate Pinning.

Certificate Pinning — механизм, при котором приложение проверяет, что сертификат сервера совпадает с заранее сохранённым в коде приложения. Даже если злоумышленник подменит сертификат через прокси (например, Burp Suite), приложение отвергнет соединение. Pinning бывает двух типов: pinning по публичному ключу (Public Key Pinning) и по хешу сертификата (Certificate Hash Pinning).

Шифрование и хеширование: AES, RSA, SSL/TLS

Симметричное шифрование: AES

AES (Advanced Encryption Standard) — симметричный алгоритм шифрования, основа безопасности данных на устройстве. AES использует один и тот же ключ для зашифровки и расшифровки данных. AES поддерживает ключи длиной 128, 192 или 256 бит. В мобильной разработке AES-256 применяется для шифрования данных на устройстве: файлов, кэша, записей в локальной базе данных.

Режимы AES: GCM (рекомендуемый) — обеспечивает аутентификацию данных, CBC — базовый режим с цепочкой блоков, ECB — небезопасный, не используйте его. Для iOS AES доступен через CommonCrypto (CCOptions), для Android — через Cipher в Java Cryptography Architecture (JCA). Важно: ключ шифрования никогда не должен храниться в коде приложения — используйте Keychain/Keystore.

Асимметричное шифрование: RSA — использует пару ключей (публичный и приватный). RSA применяется для шифрования небольших объёмов данных — обычно для обмена симметричным ключом между клиентом и сервером. Длина ключа RSA — минимум 2048 бит (рекомендуется 4096). В iOS RSA доступен через Security Framework (SecKeyCreateRandomKey), в Android — через KeyPairGenerator в Android Keystore.

Хеширование и SSL/TLS

Хеширование (SHA-256, SHA-3) — необратимое преобразование данных в строку фиксированной длины. Хеши используются для проверки целостности данных и хранения паролей. Для паролей обязательно применяйте bcrypt, scrypt или Argon2 — обычный SHA-256 уязвим к атакам по радужным таблицам. SSL/TLS — протокол шифрования сетевого трафика между клиентом и сервером. Современный стандарт — TLS 1.3, который обеспечивает Perfect Forward Secrecy (PFS).

TLS 1.3 быстрее предшественников: рукопожатие (handshake) занимает один round-trip вместо двух. На Android минимальная версия TLS настраивается через SSLSocket, на iOS — через ATS (App Transport Security), который по умолчанию требует TLS 1.2 или выше. Отключать ATS для iOS-приложения можно только для конкретных доменов с обоснованием.

Безопасное хранение: Keychain и Keystore

iOS: Keychain

Keychain (Связка ключей) — защищённое хранилище в iOS / macOS для паролей, ключей шифрования, сертификатов и токенов. Данные в Keychain шифруются аппаратным ключом, уникальным для каждого устройства. Доступ к Keychain контролируется через Security Framework (SecItemAdd, SecItemCopyMatching). Keychain автоматически блокируется при блокировке устройства и шифруется с помощью Secure Enclave.

Android: Keystore

Android Keystore — системное хранилище криптографических ключей, изолированное от приложения. Начиная с Android 6.0 (API 23), Keystore использует аппаратную поддержку (TEE — Trusted Execution Environment) на устройствах с чипом безопасности. Ключи в Keystore никогда не покидают защищённую область — приложение получает только handle для операций шифрования и подписи.

SharedPreferences и NSUserDefaults не предназначены для хранения конфиденциальных данных — они хранят информацию в открытом виде. Для защиты данных используйте EncryptedSharedPreferences (Android) или шифруйте данные перед сохранением в UserDefaults (iOS). В IT Sectr мы всегда используем Keychain и Keystore для токенов доступа и паролей.

Аутентификация: OAuth 2.0, JWT и биометрия

OAuth 2.0 и OpenID Connect

OAuth 2.0 — протокол делегированной авторизации, обеспечивающий безопасность доступа к ресурсам пользователя без передачи пароля. В мобильных приложениях чаще всего используется Authorization Code Flow с PKCE (Proof Key for Code Exchange). PKCE предотвращает перехват авторизационного кода — обязательное требование для мобильных приложений.

OpenID Connect (OIDC) — надстройка над OAuth 2.0 для аутентификации пользователя. OIDC добавляет ID Token в формате JWT, который содержит информацию о пользователе (имя, email, id). Поток OAuth 2.0 + OIDC включает: redirect пользователя на страницу логина, получение авторизационного кода, обмен кода на токены (access + refresh + id), использование access token для API-запросов.

JWT: Access, Refresh и Session Token

JWT (JSON Web Token) — компактный URL-безопасный формат токена, который содержит claims в формате JSON. JWT состоит из трёх частей: header (тип и алгоритм подписи), payload (данные) и signature (подпись). Access Token — короткоживущий токен (15–60 минут) для доступа к API. Refresh Token — долгоживущий (дни/недели) для получения нового access token без повторного логина.

Session Token — традиционный подход, где сервер хранит сессию в БД или Redis, а клиент получает случайный идентификатор. В мобильной разработке JWT предпочтительнее: он не требует серверного хранения сессий, содержит всю информацию внутри себя и легко проверяется. Однако JWT нельзя отозвать мгновенно — это компромисс, который решается коротким временем жизни access token и использованием refresh token.

Биометрическая аутентификация

Face ID и Touch ID на iOS, Fingerprint Auth на Android — биометрические методы аутентификации, использующие уникальные физические характеристики пользователя. В iOS биометрия работает через LocalAuthentication (LAContext), в Android — через BiometricPrompt (Android 9+) или FingerprintManager (устарел). Биометрия используется для разблокировки приложения, подтверждения платежей и доступа к защищённым данным.

Важные нюансы: биометрия — это удобный UX, но не замена серверной аутентификации. После успешной биометрической верификации приложение должно получить access token от сервера. На Android обязательно проверять, что устройство использует Class 3 (Strong) биометрию, а не только распознавание лица по камере (Class 1).

Защита кода: ProGuard, R8 и Root Detection

Обфускация: ProGuard и R8

ProGuard — инструмент обфускации, сжатия и оптимизации Java-байткода для Android, повышающий безопасность кода от обратной разработки. R8 — его преемник, встроенный в Gradle с Android Studio 3.4. R8 выполняет четыре задачи: сжатие (удаляет неиспользуемые классы и методы), оптимизация (инлайнит методы, упрощает код), обфускация (переименовывает классы и методы в короткие имена) и пре-верификация (проверка байткода).

DexGuard — коммерческая версия ProGuard с расширенной защитой: шифрование строк, обфускация ресурсов, защита от репаккинга, контроль целостности APK. Для большинства проектов достаточно R8, но для финансовых и банковских приложений DexGuard обеспечивает дополнительный уровень защиты. Включается R8 через build.gradle: minifyEnabled = true и proguardFiles.

Root и Jailbreak Detection

Root Detection (Android) и Jailbreak Detection (iOS) — механизмы, которые проверяют, получены ли на устройстве привилегии суперпользователя. На взломанных устройствах можно читать память процесса, перехватывать трафик и подменять код. Для проверки на Android используется проверка наличия SU-бинарного файла, тестовых ключей подписи и нестандартных build-флагов.

RASP (Runtime Application Self-Protection) — технология, которая защищает приложение во время выполнения. RASP обнаруживает попытки дебаггинга, репаккинга, внедрения кода и завершает работу приложения при обнаружении угроз. Примеры RASP-решений: Dexter, Guardsquare, Promon. RASP работает в рантайме и реагирует на аномалии — в отличие от статической обфускации, которая защищает код до запуска.

Reverse Engineering — процесс восстановления исходного кода из скомпилированного приложения. Инструменты: JADX (декомпилятор APK), Ghidra, IDA Pro, Hopper. Защита от Reverse Engineering — это комбинация обфускации, шифрования строк, проверки целостности и Root Detection. Полной защиты не существует — задача в том, чтобы сделать обратную разработку достаточно дорогой для злоумышленника.