
Иван Алякскин
Android Security
10.04.2018 1664
Другие статьи автора
Возможные способы реализации мобильных приложений
Джентльменский набор мобильного проекта
Исключаем фактор «так исторически сложилось» на Android/Mobile-проекте
Android Legacy
Задорный ReactNative вносит летние краски в “кровавый enterprise”
Архитектура, рефакторинг, или Что действительно важно
Чек-лист для Knowledge Transfer
Dynamic Systems Development Method (DSDM)
Документация в картинках
Последние статьи в блоге
Предположим, нам дали два целых числа, но не примитивы, а Integer-объекты…
Станьте тренером в Учебном центре IBS
Новые курсы в нашем каталоге! Научитесь управлять проектами и выстраивать комплексную архитектуру
Самый популярный язык программирования в 2023 году
Верните до 95% средств за обучение
Java-сертификация: "за" и "против”. Часть 2
Java-сертификация: "за" и "против”. Часть 1
Работа и развлечения в эпоху искусственного интеллекта
IBS Training Center при поддержке Фонда “Сколково” создал российскую систему сертификации для системных аналитиков
Запускаем сертификацию на знание системы Test IT
Безопасность мобильных приложений очень важна, так как сегодня бизнес выносит львиную часть работы с клиентом в мобильные приложения, а это подразумевает наличие и обработку персональных данных клиента.
Основные проблемы и уязвимости стары как мир и описаны на www.owasp.org
Кратенько это:
- Improper platform usage;
- Insecure data storage;
- Insecure communication;
- Insecure Authentication;
- Insufficient Cryptography;
- Insecure Authorization;
- Client Code Quality;
- Code Tampering;
- Reverse engineering.

Отлично, теперь все понятно. Но постойте, что это на самом деле это значит для Android-проекта?
- Начните с выключения логов, которые идут в logcat в production-приложении.
- Создайте безопасное хранилище с использованием KeyStore – это такой компонент для получения ключей для последующего шифрования данных.
- Не полагайтесь на SharedPreferences и MODE_PRIVATE, храните там только зашифрованные данные.
- Используйте Permissions в динамике, не полагайтесь на полученные разрешения во время старта или настройки приложения.
- Используйте и создавайте свои собственные Permissions, проверяйте их наличие при работе компонентов.
- Ограничивайте функционал Services и ContentProviders, которые выставлены в систему, проверяйте то, что ими пользуются «доверенные» программные пакеты: по подписи, имени пакета и порой даже при наличии определенного Permission.
- Не передавайте никакую Sensitive-информацию в Intent’ах.
- Добавьте обфускацию кода, просто но уже доступно.
- Защитите сетевое взаимодействие:
- a. Используйте NetworkConfig;
- b. Или ограничьтесь самостоятельно реализованным SSL Pinning’ом.
- Используйте SQLCipher, не надо городить собственные велосипеды.
- Запретите backup вашего приложения, поменяйте значение allowBackup в false, пусть «мамкин хакер» хоть чуть-чуть потрудится над тем, чтобы слить ваше приложение перед тем, как приступить к взлому.
- В случае возможности пользуйтесь Google Attestation API.
- Ограничивайте использование приложения в моменты, когда что-то идет не так, вашу активити вызывает не тот пакет или подпись не совсем та, что вы ожидали. Предусматривайте возможность информирования пользователя о том, что что-то не так на его телефоне или же просто не давайте пользоваться приложением.
P.S.: не забывайте делать «экранирование» пользовательского ввода ;)
Расскажи друзьям:
Как не пропустить самое интересное?
Подписывайтесь на наш ежемесячный дайджест!