Безопасность мобильных приложений, как обеспечить сохранность данных

Развитие высоких технологий и тренд мобильности привели к тому, что современное мобильное устройство зачастую используется в качестве мобильного офиса, центра развлечений и инструмента для потребления интернет-контента. Сам аппарат многое может рассказать о своем владельце, так как в его памяти хранятся: контакты коллег, друзей и близких с их персональными данными, журнал звонков, переписка, параметры точек доступа Wi-Fi, которые расположены в пределах ареала обитания владельца, приложения социальных сетей (зачастую с сохраненными паролями, банковские реквизиты или мобильный банк, фото и видео, заметки и пр.

То, насколько стремительно Интернет и мобильные устройства проникли в нашу жизнь видно из исследований размещенных на портале DataReportal.

Численность населения на начало 2023 года - 8,01 млрд человек;
Пользователей мобильных телефонов - 5,44 млрд человек;
Пользователей интернета - 5,16 млрд человек;
Пользователей социальных сетей - 4,76 млрд человек.

Ниже видно как изменились эти значения по сравнению с аналогичным периодом прошлого года:

По этим данным видно, что число пользователей мобильных устройств в мире увеличилось за год на 168 млн человек!

А вот так проводят пользователи время в сети:

На начало 2023 года в Российской Федерации насчитывалось 127,6 млн интернет-пользователей, проникновение интернета составляло 88,2%

В январе 2023 года в России было 106,0 млн пользователей социальных сетей, что составляет 73,3 процента от общей численности населения.

Всего на начало 2023 года в России было активно 227,0 млн сотовых мобильных подключений, что соответствует 156,9% всего населения.

Такая концентрация активностей вокруг мобильных устройств и приложений, деловых и персональных данных, хранящихся в них, приводит к тому, что абстрактная стоимость информации перевешивает цену самого устройства. Именно поэтому задача защиты мобильного устройства как от киберугроз так и от банальной утери или выхода из строя является критически важной. К сожалению, часть пользователей осознает важность этих задач лишь постфактум.

Обеспечение безопасности мобильных приложений начинается со старта разработки, ведь уже на старте проекта можно позаботится о его защите.

Об описании уязвимостей мобильных приложений позаботилось сообщество OWASP (Open Web Application Security Project). Это открытый проект обеспечения безопасности веб-приложений, в который входят корпорации, образовательные организации и частные лица со всего мира, лучшие эксперты отрасли. В рамках этого проекта были классифицированы основные уязвимости, определены меры по борьбе с ними. В результате появился документ под названием OWASP Mobile TOP-10. Рассмотрим этот документ более подробно.

1. Обход архитектурных ограничений (М1: Improper Platform Usage). Категория охватывает злоупотребление особенностями платформы, обхода ограничений или неиспользования систем контроля управления безопасности платформы. В качестве одной мер по защите можно рекомендовать использование Intent в Android-приложениях и Keychain в iOS.

protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); explicit_btn = (Button)findViewById(R.id.explicit_Intent); explicit_btn.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { Intent intent = new Intent(getBaseContext(), SecondActivity.class); startActivity(intent); } }); }

Листинг 1. Использование Intent в Android-приложении.

{ let keychainItemQuery = [ kSecValueData: pass.data(using: .utf8)!, kSecClass: kSecClassGenericPassword ] as CFDictionary let status = SecItemAdd(keychainItemQuery, nil) }

Листинг 2. Использование Keychain в iOS-приложении.

2. Небезопасное хранение данных (М2: Insecure Data Storage). К категории относятся небезопасное хранение и непреднамеренные утечки данных.

Возможные меры безопасности в Android-приложении:

хранение информации в памяти устройства (RAM)
использование EncryptedSharedPreferences, EncryptedDataStore

{ val masterKey = MasterKey.Builder(this) .setKeyScheme(MasterKey.KeyScheme.AES256_GCM) .build() EncryptedSharedPreferences.create(this, "myEncryptedPrefsFile", masterKey, PrefKeyEncryptionScheme.AES256_SIV, PrefValueEncryptionScheme.AES256_GCM).edit { putString("mySecretKey", "mySecretValue") } }

Листинг 3. Использование EncryptedSharedPreferences в Android-приложении.

Возможные меры безопасности в iOS-приложении:

хранение информации в памяти устройства (RAM)
использование Keychain, Encrypted RealmSwift, SQLCipher

{ // Generate a random encryption key var key = Data(count: 64) _ = key.withUnsafeMutableBytes { (pointer: UnsafeMutableRawBufferPointer) in SecRandomCopyBytes(kSecRandomDefault, 64, pointer.baseAddress!) } // Configure for an encrypted realm var config = Realm.Configuration(encryptionKey: key) do { // Open the encrypted realm let realm = try Realm(configuration: config) } catch let error as NSError { } }

Листинг 4. Использование Encrypted RealmSwift в iOS-приложении.

3. Небезопасная передача данных (М3: Insecure Communication). Категория охватывает недостаточное подтверждение достоверности источников связи, неверные версии SSL, недостаточную проверку согласования, передачу конфиденциальных данных в открытом виде (cleartext) и т.д.

Возможные меры защиты:

серверная сторона должна использовать защищённое SSL/TLS соединение;
запросы на сервер идут только через HTTPS протокол с действующим SSL сертификатом;
использование SSL-Pinning в приложении;
не использовать логирование запросов;
при необходимости - шифрование передаваемых данных на стороне приложения.

4. Небезопасная аутентификация (М4: Insecure Authentication). Категория относится к аутентификации конечного пользователя или неверному управлению сеансами.

Возможные меры защиты:

на устройстве не должны хранится пароли, данные кредитных карт и другие конфиденциальные данные;
в приложении должно использоваться хэширование паролей или полное хэширование запросов с созданием токена подписи запроса, если это нужно;
сессия пользователя должна регулируется с помощью токена авторизации и токена обновления сессии, которые выдаёт сервер.

{ private fun attemptSignup() { // hashing password val hashedPassword: String = BCrypt.hashpw(password, BCrypt.gensalt()) val account: Account = Account(name, email, hashedPassword) } }

Листинг 5. Хэширование пароля в Android-приложении.

class func passwordHash(from email: String, password: String) -> String { let salt = "x4vV8bGgqqmQwgCoyXFQj+(o.nUNQhVP7ND" return "\(password).\(email).\(salt)".sha256() }

Листинг 6. Хэширование пароля в iOS-приложении.

5. Слабая криптостойкость (М5: Insufficient Cryptography). Категория описывает варианты ненадлежащего использования криптографических элементов, слабой или недостаточной криптостойкости.

Возможные меры защиты:

на устройстве не должны хранится конфиденциальные данные;
должны применяться известные криптографические стандарты, (например AES-CBC или AES-GCM с 256-bit ключом);
необходимо следовать рекомендациям NIST по используемым алгоритмам.

В приложение должны внедряться проверенные криптографические библиотеки, например:

Android: Jetpack Security, средства Java и Android (например, Cipher, SecretKey);
iOS: CryptoSwift.

6. Небезопасная авторизация (М6: Insecure Authorization). Раскрытие информации пользователя, которую злоумышленники могут получить с сервера.

Возможные меры защиты:

отключение подробного логирования ошибок на сервере (на продакшен);
возвращать минимально нужный объем информации в ответах сервера;
скрытие расположения любых конфиденциальных страниц на сервере, которые могут быть доступны через Интернет;
административные страницы или другие зоны ограниченного доступа должны скрываться из общего доступа через Интернет.

7. Контроль содержимого клиентских приложений (М7: Client Code Quality). Категория рассматривает контроль за входными данными.

Возможные меры защиты:

использование блоков контроля (private, public и тд) за исключением try/catch;
контроль входящих параметров и имён файлов;
не запрашивать ненужные для работы приложения разрешения;
контроль за утечками памяти;
обфускация кода;
использование только проверенных библиотек от других разработчиков.

8. Модификация данных (М8: Code Tampering). Категория описывает изменение исполняемых файлов, локальных ресурсов, перехват вызовов сторонних процессов, подмена runtime методов и динамическую модификацию памяти.

Возможные меры защиты в Android-приложениях:

использования класса PackageManager для проверки подлинности подписи приложения;проверка имени пакета;
обфускация с использованием ProGuardи т.д.

Возможные меры защиты в iOS-приложениях:

использование методов для обнаружения Jailbreak;
обфускация кода с помощью SwiftShield и т.д.

9. Анализ исходного кода (М9: Reverse Engineering). Категория включает в себя анализ бинарных файлов для определения исходного кода, библиотек, алгоритмов и т.д.

Возможные меры защиты в Android-приложениях:

проверка подписи приложения;
проверка запущен ли root на устройстве (SafetyNet);
обфускация кода.

Возможные меры защиты в iOS-приложениях:

использование Swift вместо Objective C;
обфускация кода;
обнаружение программ, сканирующих runtime, таких как Cycript and Frida.

10. Скрытый функционал (М10: Extraneous Functionality). Часто разработчики включают в код приложений скрытые функциональные возможности, бэкдоры или другие механизмы, функциональность которых предназначена для общего использования.

Возможные меры защиты:

код-ревью на протяжении всей разработки;
проверка конфигурации приложения перед релизом;
проверка отсутствия тестовых данных в релизных сборках;
проверка точек входа на сервер;
отключение излишнего логирования в релизных сборках.

Соблюдение вышеуказанных рекомендаций поможет значительно повысить безопасность мобильных приложений.

Для анализа защищенности, помимо вышеуказанных, используются подходы и методики следующих мировых институтов и стандартов специализирующихся на обеспечении безопасности:

Open Source Security Testing Methodology Manual («OSSTMM»);
Technical Guide to Information Security Testing and Assessment (SP 800-115);
ISACA IS auditing procedure «Security assessment-penetration testing and vulnerability analysis»;
Penetration Testing Execution Standard («PTES»);
A Penetration Testing Model («BSI»);
Payment Card Industry («PCI») Data Security Standard («DSS») Guidance: PCI Information Supplement: Penetration Testing Guidance;
Federal Risk and Authorization Management Program («FedRAMP»): FedRAMP Penetration Test Guidance.

Однако все работы по анализу защищенности мобильных приложений можно разделить на следующие этапы:

1. Сбор информации и первичный анализ стека технологий:

Сбор первичной информации (предоставление дистрибутивов приложений и учётных данных, IP-адресов тестируемых сервисов).
Идентификация элементов инфраструктуры.
Определение архитектуры и бизнес логики приложения.
Определение доступного и скрытого контента.
Определение критичных точек входа на ресурс.

2. Тестирование конфигурации:

Тестирование конфигурации сервера.
Тестирование конфигурации сервера.
Проверка временных, резервных и неисполняемых файлов для поиска чувствительной информации.
Тестирование конфигурации элементов информационного окружения и платформы бекэнда.
Тестирование конфигурации мобильного приложения.

3. Тестирование системы аутентификации:

Определение механизма аутентификации.
Тестирование парольной политики.
Тестирование процесса регистрации новых пользователей.
Тестирование функции восстановления аккаунта и смены пароля.
Проверка учетных данных по умолчанию.
Тестирование на устойчивость к перебору имен пользователей.
Тестирование на устойчивость к перебору паролей.
Тестирование корректности работы механизма блокировок в случае перебора пароля.

4. Тестирование механизма управлениями сессиями:

Анализ механизмов «Web-API» и «OAuth».
Определение ролей пользователей.
Проверка возможности повышения привилегий.
Определение механизма управления сессиями.
Проверка области действий cookies.
Тестирование корректной работы механизма управления сессиями.

5. Тестирование защищённости транспортного уровня:

Идентификация протоколов взаимодействия «клиент-сервер».
Тестирование защищённости протоколов взаимодействия «клиент-сервер»

6. Проверка на корректность обработки передаваемых данных:

Проверка всех данных, возвращаемых сервером и передаваемых клиентом.
Тестирование на наличие SQL-инъекций.
Тестирование на внедрение команд.
Тестирование обхода каталогов.
Тестирование неконтролируемого внедрение скриптов.
Тестирование неконтролируемой загрузки файлов.
Тестирование других вариантов инъекций (SMTP inj, SOAP inj, LDAP inj, XPath inj, Frame inj).
Тестирование нативных программных недостатков.

7. Тестирование логики работы приложения:

Проверка на возможность оказания влияния сторонними веб-приложениями.
Проверка на наличие концептуальных уязвимостей, связанных с логикой работы веб-приложения и его функциональными возможностями.

8. Формирование отчёта:

Определение актуальных угроз информационной безопасности.
Анализ влияния обнаруженных уязвимостей.
Разработка рекомендаций по повышению уровня защищённости приложений и серверной части.

Итак, резюмируем: мобильные устройства — привлекательная мишень для хакерских атак, ведь в них хранятся и обрабатываются большие объемы личной информации и данные банковских карт.

Хранение пользовательской информации в открытом виде, незащищенные данные на снимках состояния экрана, ключи и пароли в исходном коде — это лишь немногие из тех недостатков, что открывают просторы для проведения кибератак.

Пользователи могут сами способствовать компрометации своих устройств: расширять стандартные возможности смартфона, лишая его защиты, переходить по подозрительным ссылкам в SMS сообщениях, загружать программы из неофициальных источников, поэтому безопасность пользовательских данных — ответственность не только разработчиков приложений, но и самих владельцев мобильных устройств.

Говоря о мобильных приложениях, нельзя недооценивать риск кибератаки в результате эксплуатации серверных уязвимостей. Серверы мобильных приложений защищены не лучше, чем клиентские части.

Риски связаны не только с брешами в защите клиента или сервера, но и с уязвимостями, которые возникают в процессе клиент-серверного взаимодействия. Обмен данными по открытому протоколу грозит полной компрометацией передаваемого трафика. Но даже защищенные соединения не всегда надежны, что говорит об отсутствии у разработчиков глубокого понимания важности вопросов безопасности.

Механизмы защиты являются слабым звеном мобильных приложений. Большинство уязвимостей были заложены еще на этапе проектирования и стали следствием недостаточной проработки концепции защиты. Рекомендуется тщательно прорабатывать вопросы безопасности мобильного приложения и регулярно проводить тестирование его защищенности, начиная с самых ранних стадий жизненного цикла. Наиболее эффективным методом проверки является метод белого ящика, при котором предполагается наличие у эксперта доступа к исходному коду системы.