Безопасность мобильных приложений, или «Кто проверит проверяющих?»

Поздравляю, Вы второй человек,
взломавший сегодня сейф Ван дер Водэ.
Таким образом, мистер Оушен,
Вы вступили в длинные ряды тех,
кто приложил титанические усилия,
чтобы добиться цели
и, в итоге, стать только вторым.
Вам неизвестны имена этих людей,
потому что они покрыты забвением.
Вам знакомо слово «забвение»?
Это означает, что о Вас
забывают все и навсегда".
Мистер Ночной Лис (к/ф «12 друзей Оушена»)

Привет, читатель !
Представь, что ты портной и ты сшил человеку костюм на заказ. Человек рассказал тебе, как он хочет выглядеть в этом костюме, куда в нем ходить и сколько примерно готов за него заплатить. Ты его внимательно выслушал, снял все мерки, с любовью шил этот прекрасный костюм мечты, используя все современные модные тренды. Соблюдал все пожелания своего дорогого клиента. И вот настал звездный час: костюм готов, человек его надел, и он счастлив, разглядывая себя в зеркале. Вечером он позвонил и сказал, что жене и гостям на его юбилее он тоже понравился. Но один из гостей сказал, что у этого костюма есть недостатки: он не желтого цвета, в нем нельзя тушить пожар, любой может украсть этот костюм, и (оба на!) – у него нет капюшона и в карман нельзя положить молоток или пилу.

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

Вот и мы оказались на месте этого портного. Сделали компании-клиенту мобильное приложение на заказ. Обсуждали каждый шаг с учетом потребностей пользователей (пользователей конкретно этого приложения, а не в целом ЛЮБОГО мобильного приложения), согласовали каждый элемент. Все счастливы, включая пользователей, но тут нарисовался некий Гость со своим МНЕНИЕМ. И засунуть бы куда-нибудь это его МНЕНИЕ, да оно такое корявое и угловатое, что вряд ли куда влезет.

Судите сами

Все мы (практически все) пользуемся смартфонами и мобильными приложениями. И, конечно, все мы (некоторые из нас) задумываемся над безопасностью наших личных данных, которые мы храним в телефоне. Но, так или иначе, большинство полагается в этом на разработчиков приложений. Действительно, задача безопасного хранения и передачи данных — одна из важнейших задач, которой занимаются разработчики. Не мудрено, что компании-заказчики стараются перестраховаться и иногда отдают разработанное приложение на ревью третьей компании (желательно, широко известной).
С нами тоже произошёл такой случай, и приложение нашей компании попало на так называемую «проверку». В результате образовалась некая презентация с описанием того, как все плохо. Ниже мы привели аргументы проверяющих, свои комментарии и выводы. Наслаждайтесь

Безопасность соединения

Аргумент
Соединение с сервером производится с использованием протокола https и TLS-шифрованием трафика, что де-факто является стандартом для современных приложений. Тем не менее, реализация на устройстве не соответствует всем требованиям корректного использования https. В частности, приложение устанавливает соединение, получив любой TLS-сертификат. Эта уязвимость позволяет осуществить полное прослушивание конфиденциальных данных приложения:
• Можно прочесть в открытом виде все передаваемые данные или изменить их.
• Утечке подвергаются PAN-номера кредитных карт, CVC/CVV-коды, личные данные пользователя.
• Подмена форм оплаты, перехват данных.

Контраргумент
Коллеги, ну ведь всё-таки не любой TLS-сертификат, а любой доверенный на уровне операционной системы. Конечно, пользователь может “нечаянно” добавить сертификат злоумышленника, получившего контроль над каналом связи. Такая “уязвимость” свойственна в принципе всем сайтам. Тем не менее жизнь не останавливается, и люди регистрируются и совершают покупки на сайтах. Тут очень многое зависит от осторожности самого пользователя. В случае приложения можно повысить безопасность, внедрив в приложение конкретный сертификат, используемый сервером (SSL Pinning). Но это требует согласования с заказчиком и препятствует смене сертификата (по крайней мере, соответствующего ему ключа) на сервере без обновления приложения.

Вывод
Аргумент в целом не совсем точен. Большинство приложений, а также браузеры работают на том же уровне безопасности соединения. Написанный таким образом, он может сильно напугать заказчика, в чем очевидно и была цель.

Данные приложения

Аргумент
Данные клиента хранятся на устройстве в открытом виде. Не используются ни системные средства защиты (Keychain, iOS Data Protection), ни шифрование этих данных. Данная уязвимость позволяет:
На любом устройстве (без jailbreak и прочих модификаций) при подключении к компьютеру за минуту получить данные пользователя. Это можно сделать, например, файловым менеджером iFunBox.

Контраргумент
Это утверждение обманчиво: похоже, что коллеги проверяли приложение на разблокированном телефоне. Дело в том, что для защиты данных используется iOS Data Protection (флаг NSFileProtectionComplete – и мы это перепроверили). Это означает, что когда устройство с настроенным pin'ом или Touch ID заблокировано (locked), файл зашифрован, и может быть расшифрован только после разблокирования. Если же устройство не заблокировано, то говорить о защите данных от злоумышленника, имеющего физический доступ к устройству, бессмысленно: он может просто запустить приложение и всё посмотреть.

Вариант повышения безопасности с помощью пин-кода нами рассматривался. Однако его использование на приложении для защиты данных — идея весьма спорная. Если сделать его необязательным, пользователь может его не установить, точно так же, как и не установить его на все устройство. Если сделать его обязательным, пользователям придется вводить два пин-кода: на телефон и на приложение. Кроме того, без пин-кода на устройстве незащищенными остаются такие вещи как почта, браузер (с кэшем и сохраненными паролями), звонки и сообщения. Имея к ним доступ, злоумышленник может не только нанести и без того значительный ущерб, но и скорее всего получить доступ к аккаунту пользователя на сервере (если он есть и, например, имеет функцию “забыли пароль"). Да и вряд ли приложение хранит данные более критичные, нежели перечисленные вещи.

Вывод: Аргумент ошибочен. Мы считаем, что имела место ошибка проверяющего либо проверяющий умышленно рассчитывал, что это ошибку сделает заказчик, если попытается проверить это сам. Прочитать данные на заблокированном телефоне нельзя, а имея устройство в руках можно делать всё в открытом приложении.

Угроза JailBreak

Аргумент
При наличии установленного jailbreak есть возможность дистанционно скопировать данные приложения вместе с базой данных и другими файлами

Контраргумент
Что-либо защищать или гарантировать «при наличии установленного jailbreak» — это совсем другая история. Мы вообще рекомендуем ничего никому «при наличии установленного jailbreak» не гарантировать. Например, бывает и такое: github.com/iSECPartners/ios-ssl-kill-switch ^[1]. Как можно защищать пользователя, который себе это поставит? Предлагается проверка на установленный jailbreak? Во-первых, любую проверку на jailbreak можно обойти. Во-вторых, вряд ли пользователь не в курсе, что у него jailbreak; и тут стоит задуматься, кого мы -защищаем: пользователя от атак или приложение от пользователя. В-третьих, наличие некоторых проверок может привести к проблемам при прохождении appstore review, либо при работе приложения, ведь многие проверки заключаются в том, что приложение пытается делать то, чего приложениям на не-jailbreak устройствах делать недозволенно.

Вывод: Аргумент ошибочен. Не будем защищать приложение и данные пользователя от самого пользователя.

Системные скриншоты

Аргумент
Системные скриншоты не маскируются, и могут содержать приватные платежные данные клиентов. Системные скриншоты хранятся в памяти устройства и легко доступны при подключении к компьютеру.

Контраргумент
Ну опять же, скорей проверялся незалоченный телефон. Для системных скриншотов тоже используется «iOS Data Protection», и в залоченном телефоне они недоступны. А если телефон разблокирован и до него есть доступ – то посмотреть скриншоты не составит труда никому.

Вывод
Аргумент надуманный и призван посеять панику, ведь скриншоты защищены на уровне системы.

Отладчик

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

Контраргумент
Восстановить алгоритмы работы – непонятно в чём цель этого действия и зачем о нем писать? Никаких секретных алгоритмов у нас нет, а модифицировать приложение можно только при наличии jailbreak, и мы об этом уже писали – это может повредить только самому пользователю.

Вывод
Аргумент бессмысленный. Непонятно, зачем он приведен и понимает ли автор так называемой «презентации» смысл того, о чем пишет.

ИТОГ:

Как видите, пункты безопасности в экспресс-анализе затронуты верные, но их трактовка и подача вызывают некоторые вопросы.

Из всех перечисленных аргументов имеет смысл улучшить только безопасность соединения, применив пиннинг сертификата. В свое время мы предлагали это сделать заказчику, но не продвинулись в решении этого вопроса на стороне сервера. Возможно, этот анализ поможет нам в диалоге с заказчиком в качестве дополнительного аргумента.

В целом, товарищи сотворили презентацию в красном цвете с громкими словами и, как вы уже увидели, неглубокими утверждениями и навели панику на компанию-заказчика.
Объективен ли был этот анализ и какова его цель?
Правильно ли потрачены время и деньги нашего клиента?
Насколько вообще этично с профессиональной точки зрения приводить заведомо некорректные аргументы против чужого продукта?

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

Автор: eastbanctech

Источник ^[2]