Безопасност в мобилната разработка: какво е, какви заплахи и как да се защитим

Основни заплахи: 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, който съдържа информация за потребителя (име, имейл, id). Потокът OAuth 2.0 + OIDC включва: пренасочване на потребителя към страницата за вход, получаване на код за упълномощаване, обмен на кода за токени (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. Пълна защита не съществува — задачата е да се направи обратното разработване достатъчно скъпо за нападателя.