;
Иван Алякскин
Android Security
10.04.2018 1896
Другие статьи автора
Возможные способы реализации мобильных приложений
Джентльменский набор мобильного проекта
Исключаем фактор «так исторически сложилось» на Android/Mobile-проекте
Android Legacy
Задорный ReactNative вносит летние краски в “кровавый enterprise”
Архитектура, рефакторинг, или Что действительно важно
Чек-лист для Knowledge Transfer
Dynamic Systems Development Method (DSDM)
Документация в картинках
Последние статьи в блоге
Кейс: Сертификация команды системных аналитиков
Путь к Fullstack-тестировщику: что нужно знать о ручном и автоматизированном тестировании?
ИИ-тестировщик: ожидания и реальность
Системный аналитик 100 lvl — дорожная карта развития
Как оценивать работу тестировщиков по науке
Учебный центр IBS получил сертификат ГОСТ Р ИСО 9001-2015
Совет по развитию сертификации ИТ-специалистов при АПКИТ аккредитовал «Платформу сертификации IBS»
Java-сертификация: IBS в сравнении с Oracle
Исследование IBS: число новых ИТ-решений в реестре ПО выросло в 2023 году более чем на треть
6 суперспособностей Fullstack-тестировщиков, которые напоминают навыки животных
Безопасность мобильных приложений очень важна, так как сегодня бизнес выносит львиную часть работы с клиентом в мобильные приложения, а это подразумевает наличие и обработку персональных данных клиента.
Основные проблемы и уязвимости стары как мир и описаны на 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.: не забывайте делать «экранирование» пользовательского ввода ;)
Расскажи друзьям:
Как не пропустить самое интересное?
Подписывайтесь на наш ежемесячный дайджест!