Безпека в мобільній розробці: що це, які загрози та як захищатися

Основні загрози: 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. Повного захисту не існує — завдання в тому, щоб зробити зворотну розробку достатньо дорогою для зловмисника.