Безопасность мобильных приложений: 8 уязвимостей iOS и Android

📅 Опубликовано: 🔄 Обновлено:
мобильная безопасностьiOSAndroidReact NativeFlutterOWASP Mobile Top 10криптографияаутентификация
Безопасность мобильных приложений: 8 уязвимостей iOS и Android

Коротко: 78% мобильных приложений содержат критические уязвимости безопасности. Разбираем 8 главных угроз для iOS и Android, включая небезопасное хранение данных, слабую криптографию и проблемы аутентификации. С примерами из практики и конкретными решениями для защиты пользовательских данных.

Содержание

Почему безопасность мобильного приложения — это не роскошь?

Помните историю с приложением банка, которое хранило PIN-коды в открытом виде? Или когда популярное фитнес-приложение "случайно" светило геолокацию секретных военных баз? Это не байки из интернета — реальные случаи, которые стоили компаниям миллионы долларов и доверие пользователей.

За последние два года мы в DS495 проводили аудиты безопасности для более чем 40 мобильных приложений. Печальная статистика: 78% из них содержали критические уязвимости, которые могли привести к утечке персональных данных.

Вот что происходит, когда безопасность игнорируют:

  • Штрафы от регуляторов — GDPR может оштрафовать на сумму до 4% от годового оборота компании
  • Блокировка в App Store или Google Play — восстановление может занять месяцы
  • Репутационные потери — 86% пользователей удаляют приложение после новости о взломе
  • Прямые финансовые убытки — средний ущерб от утечки данных составляет $4,45 млн
Интересный факт: злоумышленникам требуется в среднем 12 минут, чтобы взломать плохо защищённое мобильное приложение. За это время вы даже кофе не успеете выпить.

Какие угрозы подстерегают мобильные приложения?

OWASP Mobile Top 10 — это своеобразный хит-парад уязвимостей мобильных приложений. Каждые несколько лет эксперты обновляют список самых опасных проблем. Актуальная версия выглядит так:

Ранг Уязвимость Критичность Частота встречаемости
1 Небезопасное хранение данных Высокая 76%
2 Небезопасная криптография Высокая 68%
3 Небезопасная аутентификация Критическая 61%
4 Небезопасная авторизация Критическая 59%
5 Недостаточная криптография сети Высокая 54%

Мы сосредоточимся на 8 наиболее критических проблемах, с которыми сталкиваемся при разработке и аудите приложений для iOS и Android. Особое внимание уделим кроссплатформенным решениям — React Native и Flutter — где проблемы безопасности часто усугубляются.

Небезопасное хранение данных: когда телефон превращается в сейф из картона

Представьте: вы разрабатываете банковское приложение и решаете сохранить данные карты пользователя в SharedPreferences на Android или UserDefaults на iOS. Звучит удобно, правда? Только вот эти данные может прочитать любой, кто получит физический доступ к устройству.

Где чаще всего прячут данные неправильно:

  • SQLite базы без шифрования — как записка на холодильнике, только с банковскими реквизитами
  • Лог-файлы — туда попадает всё подряд, включая пароли и токены
  • Кэш и временные файлы — операционная система может их сохранить где угодно
  • Cloud backup — iCloud и Google Drive не всегда безопасны для чувствительных данных

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

Правильные способы хранения данных:

Для iOS:

  • Keychain Services для паролей и токенов
  • Core Data с NSPersistentStoreFileProtectionKey
  • Шифрование файлов через CommonCrypto

Для Android:

  • Android Keystore для криптографических ключей
  • EncryptedSharedPreferences для настроек
  • Room database с SQLCipher для больших объёмов данных

Для React Native и Flutter:

  • react-native-keychain / flutter_secure_storage
  • Шифрование на уровне приложения перед сохранением
  • Использование нативных API через bridge
Нужна помощь с этой задачей? Команда DS495 решит её под ключ. Обсудить проект →

Слабая криптография в iOS и Android приложениях

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

Топ ошибок в криптографии мобильных приложений:

  1. Использование MD5 и SHA1 для хеширования паролей — эти алгоритмы взламываются за секунды
  2. Хранение ключей шифрования в коде — как спрятать ключ от сейфа под ковриком
  3. Слабая генерация случайных чисел — использование времени или идентификатора устройства как источника энтропии
  4. Устаревшие алгоритмы — DES, RC4 и другие "музейные экспонаты"

Как-то к нам обратился клиент с финтех-приложением. При аудите выяснилось, что они шифруют транзакции алгоритмом, который NASA использовала в 1970-х. Современный смартфон мог взломать такое шифрование за 15 минут.

Современные стандарты криптографии:

Задача Рекомендуемый алгоритм Размер ключа Примечания
Симметричное шифрование AES-256-GCM 256 бит Встроенная защита от изменений
Хеширование паролей Argon2id — Победитель Password Hashing Competition
Асимметричное шифрование RSA-OAEP 4096 бит Для небольших данных
Цифровые подписи ECDSA P-256 Быстро работает на мобильных

Проблемы аутентификации и авторизации

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

Самые болезненные проблемы аутентификации:

Слабые пароли без политики сложности Приложение позволяет создать пароль "123456". В 2024 году это звучит как анекдот, но 43% приложений до сих пор не проверяют сложность паролей.

Отсутствие двухфакторной аутентификации SMS-коды уже не считаются надёжными — их можно перехватить. TOTP (временные коды из Google Authenticator) или push-уведомления гораздо безопаснее.

Проблемы с токенами JWT токены без подписи, вечные refresh token'ы, хранение токенов в localStorage — классика жанра уязвимостей.

Проблемы авторизации не менее серьёзны:

  • Insecure Direct Object References (IDOR) — пользователь может получить доступ к чужим данным, просто изменив ID в URL
  • Privilege Escalation — обычный пользователь получает права администратора
  • Отсутствие проверок на стороне сервера — вся логика авторизации находится в мобильном приложении

Недавний случай из практики: в одном e-commerce приложении можно было получить доступ к заказам любого пользователя, просто перебрав номера заказов. Система проверяла только то, что пользователь авторизован, но не проверяла, его ли это заказ.

Сетевые уязвимости в React Native и Flutter приложениях

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

Основные сетевые угрозы:

Man-in-the-Middle (MITM) атаки Злоумышленник перехватывает трафик между приложением и сервером. Особенно опасно в публичных Wi-Fi сетях — аэропорты, кафе, отели превращаются в охотничьи угодья для хакеров.

Certificate Pinning bypass Многие разработчики забывают реализовать привязку сертификатов. В результате приложение доверяет любому валидному SSL-сертификату, даже поддельному.

Небезопасные HTTP-соединения Да, в 2024 году до сих пор встречаются приложения, которые отправляют чувствительные данные по HTTP. Это как кричать номер банковской карты на всю улицу.

Особенности кроссплатформенных решений:

React Native использует стандартные сетевые библиотеки платформы, но добавляет свои подводные камни:

  • Metro bundler может включить дебаг-информацию в продакшен-сборку
  • JavaScript Bridge создаёт дополнительную поверхность для атак
  • React DevTools в production-сборках — прямая дорога к взлому

Flutter компилируется в нативный код, но имеет свои особенности:

  • Dart VM может оставлять отладочную информацию в release-сборках
  • HTTP-клиент требует ручной настройки certificate pinning
  • Observatory port может остаться открытым в production

Платформенные особенности безопасности App Store и Google Play

App Store и Google Play — это не просто магазины приложений, а первая линия обороны против вредоносного софта. Но их подходы к безопасности кардинально отличаются.

Политика безопасности App Store:

Apple известна своим строгим подходом к модерации. Каждое приложение проходит ручную проверку, которая занимает от 24 до 72 часов. Основные требования:

  • App Transport Security (ATS) — обязательно для всех HTTPS-соединений
  • Keychain sharing — строгие ограничения на доступ к данным других приложений
  • Data Collection Disclosure — обязательно указывать, какие данные собирает приложение
  • Third-party SDKs — ответственность за безопасность сторонних библиотек лежит на разработчике

Политика безопасности Google Play:

Google использует автоматизированную проверку через Play Protect, дополненную выборочной ручной модерацией:

  • Target API Level — новые приложения должны использовать актуальную версию Android API
  • App Bundle signing — Google подписывает приложения своим ключом
  • Sensitive permissions — ограничения на использование опасных разрешений
  • Play Console security — обязательная двухфакторная аутентификация для разработчиков
Интересная статистика: App Store блокирует около 40% приложений на этапе модерации, Google Play — только 8%. При этом количество вредоносных приложений в обеих платформах примерно одинаковое — около 0,02%.

Требования к кроссплатформенным приложениям:

React Native приложения должны соответствовать требованиям обеих платформ одновременно:

  • Отключение Remote JavaScript Debugging в production
  • Использование Hermes или V8 engine вместо JavaScriptCore для Android
  • Проверка на наличие чувствительных данных в bundle.js

Flutter приложения проходят более строгую проверку:

  • Компиляция в release mode с включённой обфускацией
  • Удаление всех debug символов из финальной сборки
  • Использование ProGuard/R8 для дополнительной защиты Android-версии

Как защитить мобильное приложение: пошаговое руководство

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

Этап 1: Анализ и планирование (1-2 недели)

Шаг 1.1: Проведите инвентаризацию данных Составьте список всех данных, которые обрабатывает ваше приложение:

  • Персональная информация пользователей
  • Платёжные данные
  • Геолокация
  • Медицинская информация
  • Корпоративные данные

Шаг 1.2: Классифицируйте данные по уровню чувствительности

  • Публичные — можно публиковать без ограничений
  • Внутренние — для использования внутри компании
  • Конфиденциальные — требуют специальной защиты
  • Критические — максимальный уровень защиты

Шаг 1.3: Определите угрозы для каждой категории данных Используйте методологию STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege).

Этап 2: Защита на уровне кода (3-4 недели)

Шаг 2.1: Настройте безопасное хранение данных

// Пример для React Native
import {setInternetCredentials} from 'react-native-keychain';

await setInternetCredentials(
  'server', 
  username, 
  password
);

Шаг 2.2: Реализуйте правильную криптографию

  • Используйте только современные алгоритмы (AES-256, RSA-4096)
  • Никогда не храните ключи шифрования в коде
  • Реализуйте key rotation каждые 6-12 месяцев

Шаг 2.3: Настройте network security

  • Certificate pinning для критических соединений
  • HSTS headers на сервере
  • Проверка целостности данных через HMAC

Этап 3: Защита на уровне инфраструктуры (2-3 недели)

Шаг 3.1: Настройте мониторинг безопасности

  • Логирование всех операций с чувствительными данными
  • Alerting на подозрительную активность
  • Regular security scanning

Шаг 3.2: Реализуйте backup и disaster recovery

  • Регулярное резервное копирование
  • Тестирование восстановления данных
  • Geographic redundancy для критических систем

Этап 4: Тестирование безопасности (1-2 недели)

Шаг 4.1: Automated security testing

  • SAST (Static Application Security Testing)
  • DAST (Dynamic Application Security Testing)
  • Dependency checking

Шаг 4.2: Manual penetration testing

  • Тестирование бизнес-логики
  • Social engineering тесты
  • Physical security assessment

Это часть серии материалов по теме «Кибербезопасность». Основная статья серии: Пентест интернет-магазина: как выявить 15 критических уязвимостей OWASP за 7 дней и защитить платёжные данные от утечки через SSL-шифрование и настройку WAF в 2026 году.

Читайте также

Частые вопросы

В: Сколько стоит аудит безопасности мобильного приложения?

О: Стоимость зависит от сложности приложения. Базовый аудит простого приложения — от 150 000 рублей, комплексная проверка enterprise-решения — до 1 500 000 рублей. В среднем на аудит уходит 2-4 недели.

В: Какие данные нельзя хранить на мобильном устройстве?

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

В: React Native или Flutter — что безопаснее?

О: Flutter имеет преимущество из-за компиляции в нативный код, но React Native тоже можно сделать безопасным при правильной настройке. Главное — не экономить на реализации security мер и регулярно обновлять зависимости.

В: Как часто нужно обновлять системы безопасности?

О: Security патчи — немедленно после выхода. Полный аудит безопасности — каждые 6-12 месяцев. Обновление криптографических ключей — каждые 6 месяцев. Пентесты — перед каждым крупным релизом и раз в год для стабильных приложений.

В: Нужно ли шифровать данные в приложениях для внутреннего использования?

О: Обязательно. Корпоративные данные часто более ценны для злоумышленников, чем личная информация пользователей. 60% успешных кибератак направлены именно на внутренние системы компаний.

В: Можно ли полностью защитить приложение от взлома?

О: Стопроцентной защиты не существует. Цель — сделать взлом настолько сложным и затратным, чтобы злоумышленнику было проще найти более лёгкую цель. Хорошая защита повышает стоимость атаки в 100-1000 раз.

В: Что делать, если обнаружили уязвимость в уже опубликованном приложении?

О: Немедленно выпустить патч и обновление. Если уязвимость критическая — обратиться в App Store и Google Play с просьбой об экстренном review. Уведомить пользователей через push-уведомления и не скрывать проблему — честность в таких вопросах важнее PR.

Нужна помощь с этим? Обсудить проект с DS495 →