Содержание
Сегодня мы бы хотели поговорить о безопасности iOS приложений и защите пользовательских данных. Для начала стоит определиться с понятиями. Что такое пользовательские данные? И почему их нужно защищать? Прежде всего имеются в виду учетные данные, данные и выписки с банковских аккаунтов, медицинские данные и т.д. Иными словами — все то, что относится к личной и конфиденциальной информации.
Защита пользовательских данных необходима из соображений безопасности и/или в соответствии с требованиями различных правовых документов (например HIPAA). Кроме того, дополнительные меры предосторожности повышают уровень пользовательского доверия к приложению и сервису в целом.
Схема приложения
Типичная схема современного клиент-серверного приложения выглядит примерно так:
Она состоит из трех компонентов:
- Client — ваше iOS приложение
- Канал связи — интернет
- Сервер вашего приложения
Проблемы с безопасностью могут возникать на всех трех участках пути пользовательских данных. В этой связи, каждый из них требует обеспечения безопасности и правильного подхода к защите.
Хранение данных — возможные ошибки
Чаще всего — это:
- Небезопасное хранение.
- Утечка данных. Дело в том, что некоторые компоненты операционной системы могут сохранять чувствительные данные, а разработчик этого не понимает или не ожидает и не принимает никаких защитных мер.
- Неправильная криптография.
- Слабая или полностью отсутствующая защита исполняемых файлов.
Каждая из возможных ошибок нуждается в предметном рассмотрении.
Небезопасное хранение
Начнем с небезопасного хранения данных. Все приложения в iOS выполняются в песочнице. Там же хранятся их данные. При этом приложения, размещенные в одной песочнице, не имеют доступа к песочницам других приложений. Казалось бы все хорошо. Приложение сохранило файл, другое приложение прочитать этот файл не может — все в порядке. Однако хранение данных в песочнице не означает, что их не могут прочитать извне. Зачастую для этого даже не требуется jailbreak.
Если вы не желаете столкнуться с подобной проблемой, следуйте нашим рекомендациям:
- Не храните чувствительные данные в открытом виде (CoreData/NSUserDafaults/ и т.д.).
- Используйте доступные методики шифрования данных.
- Не используйте статические ключи шифрования.
- Для пользовательских учеток и хранения ключа шифрования применяйте KeyChain.
- Используйте DataProtection.
- Выбирайте максимально строгий класс защиты, при котором приложение сохраняет возможность работать
Последние пункты требуют короткого комментария. Классы защиты определяют, при каких условиях тот или иной элемент информации (файл или запись KeyChain) будут доступны для приложения, а также попадает ли запись KeyChain в бекап.
Утечки данных
Как правило, персональные данные пользователя при выполнении сетевых запросов сохраняются в кеше HTTP или в Cookies. Кроме того, они размещаются в песочнице приложения. Это — небезопасно. Чтобы избежать утечки информации из песочницы, необходимо установить настройки кеширования запросов и работы с Cookies.
Еще одна распространенная проблема — это скриншот чувствительных данных в app switcher. Когда вы покидаете или сворачиваете приложение, система скринит его текущее состояние. Далее изображение демонстрируется в app switcher, и персональные данные могут оказаться предметом постороннего внимания. Для сохранности информации следует модифицировать пользовательский интерфейс перед выходом из приложения.
И еще. Иногда пользователи не устанавливают Passcode или просто проявляют небрежность по отношению к защите персональных данных. Именно поэтому мы рекомендуем обратить внимание на экран авторизации с пинкодом или Touch ID. Речь идет о дополнительной защите данных на уровне пользовательского интерфейса.
Криптография
Здесь все просто. Забудьте о статических ключах шифрования и алгоритмах, которые выдают один и тот же ключ на всех устройствах. Доверьте реализацию алгоритмов криптографии профессионалам.
Защита исполняемых фалов
Защита исполняемых фалов в iOS является, не столько жизненной необходимостью, сколько правилом хорошего тона. Посудите сами. Приложение работает в песочнице. Программный код подписан. Соответственно использовать какую-либо уязвимость крайне сложно. Более того — это не нанесет серьезный ущерб системе.
И все же мы рекомендуем дополнительные меры предосторожности
- Использование защиты стека
- Применение технологии ASLR
- Удаление отладочной информации и логов из релизных сборок
Канал связи — в чем опасность?
С приложением разобрались. Следующий компонент клиент-серверного приложения — это канал связи с сервером. Как правило, речь идет об интернете.
Какие угрозы для персональных данных скрывает глобальная сеть? Например, использование HTTP вместо HTTPS (“s” на конце означает secure!) Однако и с механизмом принудительной активации защищенного соединения следует работать правильно.
Основа безопасности TLS (transport layer security) — это проверка сертификата. Если вы не проверяете сертификат на валидность, гарантия безопасного соединения с сервером отсутствует. Но и это еще не все. Для обеспечения максимальной безопасности мы рекомендуем использовать Certificate Pinning и подпись каждого запроса к серверу. Certificate Pinning позволит избежать подмены сертификата из доверенных источников с целью проведения MiM атаки. Ну а подпись каждого запроса предотвращает повторные запросы к серверу в случае его перехвата и обхода TLS.
Сервер — основа безопасности
Наконец, поговорим о сервере. Мобильное приложение ни в коем случае не должно раскрывать информацию о нем. Для этого в релизной сборке следует удалять любые упоминания о тестовых серверах и/или тестовых эндпойнтах, так как именно они находятся в первой группе риска, будучи слабо защищенными или незащищенными вообще.
Следуя предложенным рекомендациям, вы можете быть уверены в том, что пользовательские данные надежно защищены. Кроме того, заметьте — описанные меры предосторожности не требуют серьезных финансовых затрат. Большая часть механизмов защиты реализуется стандартными, хорошо документированными методами.