Из года в год iOS обходит своего главного соперника на рынке операционных систем, Android, по степени безопасности. Под безопасностью мы имеем в виду то, насколько сложно посторонним людям получить доступ к данным пользователя мобильного устройства. Основная причина устойчивости к атакам системы iOS по сравнению с детищем Энди Рубина — это закрытые код и экосистема и дотошная проверка как программной начинки, так и устройств. А Android со своей идеей опенсорса, тысячами моделей устройств от десятков производителей и актуальными версиями ОС (шестью против трёх на iOS), которые невозможно покрыть единой защитой, остаётся удобной мишенью для мошенников.
Стало быть, iOS безопаснее Android? Взглянем на свежие данные от cvedetails.com о количестве
Android — 2146 уязвимостей, 3 место;
iOS — 1514 уязвимостей, 7 место.
Итак, iOS входит в десятку самых уязвимых цифровых продуктов. В сентябре 2017 года Евгений Зобнин, редактор рубрик Unixoid и Mobile в журнале Хакер, уже указывал на минимальный разрыв в количестве уязвимостей у двух систем. Если кратко, то проблема, по его словам, не в самом Android, а в устройствах, которые на нём работают. Выборка из 100 уязвимостей, сделанная Евгением, показывает, что на код ОС приходится чуть меньше трети уязвимостей, а основную опасность несут драйверы процессора Qualcomm (по большей части) и других модулей и компонентов.
…о багах iOS быстро забывают, они просто перестают быть актуальнымииз-за обновления всех устройств до новой версии ОС. А вот о багах Android помнят долго, ведь уязвимости даже двух- и трёхлетней давности остаются актуальными для миллионов устройств.
Если говорить об уязвимостях, iOS определенно не самая защищенная ОС, а Android не самая дырявая. А вот среднестатистический смартфон на Android — это решето. Все эти модификации, добавленные производителем, баги в фирменных загрузчиках, вечные проблемы с обновлениями — все это сводит на нет старания Google сделать Android безопаснее.
Евгений Зобнин
Но оставим упомянутые 1495 уязвимостей iOS на совести Apple. Мы в Лайв Тайпинг создаём приложения для их устройств и должны сделать всё, что от нас зависит, чтобы личным данным пользователей вашего приложения вместе с вашей и нашей репутацией ничего не угрожало. Как мы это делаем, мы расскажем ниже.
Какие данные считаются личными и не должны попадать третьим лицам
Понятие «личные данные» определяется целью приложения и контекстом, в котором оно используется. Злоумышленнику не всегда интересны имена и фамилии пользователей, но если вы разрабатываете приложение по бронированию частного самолёта, вряд ли
Итак, к личным данным относятся:
- токен, с помощью которого делаются запросы к API;
- номер кредитной карты;
- имя и фамилия;
- номер телефона;
- имейл;
- пароль.
Где же хранятся данные и в каком виде?
Основная часть данных не хранится в приложении. Исключением является, пожалуй, только токен — уникальный для конкретного клиента набор символов, с помощью которого клиентская сторона (приложение) делает все запросы к серверу. Если
Токены бывают бессрочные и временные: бессрочные действуют до тех пор, пока пользователь не разлогинится принудительно, а у временных есть срок жизни и их нужно обновлять. Последние действуют в банковских приложениях.
Токен хранится в Keychain (в переводе с английского — «связка ключей»). Это зашифрованная база данных для хранения метаданных и конфиденциальной информации от Apple.
Некоторые нюансы разработки
Технически в Keychain можно хранить не только токен, но и пароли, имейл, номер телефона
В качестве примера мы приведём обработку данных с помощью функции passwordHash:
![](https://livetyping.com/assets/images/blog/с-помощью-функции-passwordHash.png)
Эта функция принимает адрес электронной почты и пароль и возвращает хешированную строку. «Соль» — это уникальная строка, которая передаётся
Таким образом, злоумышленник, скомпрометировавший Keychain, найдет этот хеш. Он может создать таблицу часто используемых паролей и их хешей для сравнения с этим хешем. Если бы пароль пользователя хешировали без «соли», и он существовал в
Добавление «соли» увеличивает сложность атаки. Кроме того, в примере мы комбинируем электронную почту и пароль пользователя с «солью» для создания хеша, что ещё больше усложняет получение пароля.
Для взаимодействия с сервером приложение и сервер будут использовать одну «соль». Это позволяет им строить хеши одинаковым образом и сравнивать два хеша для проверки личности.
Взаимодействие приложения напрямую с Keychain осложняется, особенно в Swift. Нужно использовать Apple Security Framework, который преимущественно написан на языке C. К счастью можно избежать использования низкоуровневого API, заимствуя Swift оболочку GenericKeychain от Apple.
Ответственность мобильного разработчика за безопасность данных в том, чтобы все нужные данные хранились в Keychain.
Типы уязвимостей
Третье лицо может получить доступ к данным:
- в момент их передачи;
- подсмотрев или просто зная Apple ID и, соответственно, Keychain. Такая возможность стала реальной благодаря уязвимости, обнаруженной в октябре 2017 года разработчиком Феликсом Краузе. 30 строк кода в приложении воссоздают системное всплывающее окно, запрашивающее Apple ID. Чтобы проверить, запрашивается ли Apple ID системой или приложением, Краузе посоветовал свернуть приложение, и если вместе с ним свернётся и окно, то оно явно преследует нехорошие цели;
- зайдя в Developer Center и iTunes Connect через Apple ID. Но двухфакторная аутентификация требует вводить пароль от Apple ID и четырёхзначный код, что затрудняет несанкционированный доступ к этим службам. Даже получив доступ, злоумышленник сможет управлять приложением (выставлять цены, удалить), а не самими данными.
Атака Man-in-the-middle (MITM)
MITM широко используется для похищения номеров банковских карточек, логинов, паролей
Если данные передаются между приложением и сервером через протокол HTTP, то они передаются в нешифрованном виде. Как правило, сейчас общение мобильного приложения с бэкендом происходит через HTTPS, обеспечивающий шифрование. Получить зашифрованный трафик ты можешь, но он тебе ничего не даст.
Как шифруется трафик? Чтобы сервер и приложение общались через зашифрованный канал, сервер должен пройти аутентификацию. Для этого он высылает приложению цифровой сертификат, включающий имя сервера, имя центра сертификации и открытый ключ сервера. Перед тем, как передать данные, приложение сверяет данные из сертификата с теми, что уже хранит в себе, и так убеждается, что сервер аутентичный. После подтверждения создаётся сеансовый ключ, шифрующий трафик.
Атаки MITM реализуются через подмену сертификатов. Принцип атаки заключается в том, чтобы заставить приложение думать, что сертификат атакующего — валидный.
![Man-in-the-Middle Man-in-the-Middle](https://livetyping.com/assets/images/blog/il_Protection_of_IOS_application.png)
Атака происходит по одной из четырёх техник:
- добавление сертификата в хранилище пользовательских сертификатов в приложении. Это эксплоит (вредоносный код, экспулатирующий уязвимость), когда атакующий внедряет в приложение пользователя сертификат и может встать в зашифрованный канал и воровать данные;
- модификация, когда сертификат вшивается в само приложение. Это можно сделать даже не на стадии разработки, а когда приложение заражено.
- Обход SSL pinning. Все современные приложения используют SSL pinning как панацею от MITM. Смысл в том, что сертификат напрямую вшивается в код, а не хранится в телефоне, где его можно подменить, и обфусцируется, то есть видоизменяется до неузнаваемости. Сертификат сохраненяет работоспособность, но становится недоступным для злоумышленника, даже если тот сделает
реверс-инжиниринг . Но SSL pinning можно обойти, если подключиться напрямую к работающему приложению на телефоне, которое хранится в оперативной памяти; реверс-инжиниринг приложения и изучение алгоритма верификации сертификата. Бывает так, что механизм проверки сертификата в приложении кастомный или используеткакие-то библиотеки.Реверс-инжиниринг помогает изучить исходный код и понять, как библиотека валидирует сертификат, найти уязвимости в валидации и проэксплуатировать их.
- злоумышленник скачивает приложение, как обычный пользователь, «ревёрсит», находит уязвимости и воспроизводит их на своём устройстве
- злоумышленник пишет эксплоит и доставляет этот эксплоит в устройство: через вирусы, вредоносные ссылки, скачивания
и т. д.
Методы, препятствующие
В большинстве случаев злоумышленники используют первый тип атаки, связанный с логическими ошибками в проверке сертификатов. Её механизм есть в мобильном приложении, и в большинстве случаев он реализован с ошибками, которые позволяют внедрить эксплоит.
Как предотвращать перехваты
Для начала, любое мобильное приложение должно создаваться по стандартам. Среди таких стандартов — обращение приложения к пользователю с просьбой открыть ему доступ к камере, микрофону, фотографиям
Следующий важный этап в жизни данных — это их передача из приложения на сервер. Чтобы никто не смог перехватить их в этот момент, используется:
- токен, который получает приложение в момент авторизации пользователя;
- зашифрованное соединение на стороне сервера (
SSL-сертификат ); HTTPS-протокол . ВHTTPS-канале используется протокол TLS. Разработчики сами не занимаются шифрованием, они просто настраивают HTTPS, а остальную магию делает протокол.
Казалось бы,
Мы рассказали, как
Touch ID и Face ID
Идентификация по отпечатку пальца и лицу соответственно. Apple утверждает, что возможность совпадения отпечатков пальцев — 1:50000, а параметров лица — 1:1000000. Такая низкая статистика совпадений дополняется ещё и тем, что биометрические данные не хранятся на устройстве в чистом виде — они преобразуются в математическую модель, не поддающуюся расшифровке.
Пароли и отпечатки (вернее, их математические представления) находятся под защитой системы Secure Enclave, и только она имеет к ней доступ. Secure Enclave изолирована от iOS, поэтому данные не будут использованы операционной системой и программами, не попадут на сервера Apple или в хранилище iCloud. В этом владельцев айфонов заверяет официальное описание технологии.
![Apple A7 Apple A7](https://livetyping.com/assets/images/blog/Touch-ID-Secure-Enclave-A7.jpg)
В августе 2017 года, когда iOS 11 находилась на стадии
Face ID можно протестировать и проверить только на физическом устройстве. Работу Touch ID можно воссоздать в симуляторе xCode, начиная с девятой версии.
Для идентификации пользователя с помощью Face ID и Touch ID используется Local Authentication framework.
Ещё один нюанс разработки
Импортируем Local Authentication framework:
![Local Authentication Framework Local Authentication Framework](https://livetyping.com/assets/images/blog/Импортируем-Local-Authentication-framework.png)
Создаём новый класс:
![biometricIDAuth biometricIDAuth](https://livetyping.com/assets/images/blog/Создаём-новый-класс.png)
Теперь нам понадобится ссылка на LAContext (контекст). Контекст ссылается на контекст аутентификации, который является «представителем» Local Authentication framework.
![LAContext LAContext](https://livetyping.com/assets/images/blog/ссылка-на-LAContext.png)
Также нам понадобится функция, которая поможет узнать, доступен ли биометрический идентификатор на устройстве пользователя:
![](https://livetyping.com/assets/images/blog/биометрический-идентификатор-на-устройстве-пользователя.png)
Затем добавляем функцию, которая произведет идентификацию пользователя, либо же вернет ошибку идентификации:
![Функция для идентификации пользователя Функция для идентификации пользователя](https://livetyping.com/assets/images/blog/добавляем-функцию-которая-произведет-идентификацию-пользователя.png)
В случае, если пользователь не проходит биометрическую идентификацию пять раз, либо отменяет её, ему предлагается ввести
Защита имени и фамилии
В iOS есть два элемента, позволяющие вводить данные: textfield и textview. Чаще всего для ввода пароля, имени и фамилии используется textfield. Он настраивается с помощью некоторых методов: для пароля необходимо выставлять параметр Secure Entry, чтобы перекрывать пароль точками; если важны имя и фамилия, то можно отключить автокоррекцию (отключить поле autocorrectiontype) и система не будет их запоминать и индексириовать.
Размывание экрана приложения при сворачивании
Метод необходим для приложений, которые содержат личные данные пользователей и которые можно тайком подсмотреть. Частный случай — банковские приложения.
![Размывание экрана в приложении Размывание экрана в приложении](https://livetyping.com/assets/images/blog/screen-blur.png)
Когда пользователь сворачивает приложение, операционная система применяет к нему этот метод. Как результат, в режиме мультизадачности пользователь видит экран приложения размытым, но его состояние сохраняется.
Итоги
Чтобы данные пользователей вашего приложения оставались в безопасности, мы:
- храним данные в Keychain;
- обрабатываем все разрешения на доступ к контактам, фото
и т. п. ; - прописываем адрес сервера, к которому нужно обращаться через
HTTPS-протокол ; - настраиваем доступ через Touch ID, Face ID и через
код-пароль , хранящийся в Keychain, если палец не считывается; - предусматриваем безопасный ввод данных через textfield и textview и обрабатываем его по правилам (вводим закрытым без посторонних символов)
- размываем экран с личными данными при сворачивании приложения;
- выкатываем регулярные обновления.
Обновления, касающиеся безопасности, выкатываются в нескольких случаях:
- в приложении обнаружена ошибка, касающаяся безопасности системы;
- если меняется законодательство стран, в которых пользуются приложением;
- если Apple выпускает обновление, затрагивающее политику безопасности приложения.