Безопасность мобильных приложений, или «Кто проверит проверяющих?»
Поздравляю, Вы второй человек, взломавший сегодня сейф Ван дер Водэ.Таким образом, мистер Оушен, Вы вступили в длинные ряды тех, кто приложил титанические усилия, чтобы добиться целии, в итоге, стать только вторым.Вам неизвестны имена этих людей, потому что они покрыты забвением.Вам знакомо слово «забвение»? Это означает, что о Васзабывают все и навсегда».Мистер Ночной Лис (к/ф »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. Как можно защищать пользователя, который себе это поставит? Предлагается проверка на установленный jailbreak? Во-первых, любую проверку на jailbreak можно обойти. Во-вторых, вряд ли пользователь не в курсе, что у него jailbreak; и тут стоит задуматься, кого мы -защищаем: пользователя от атак или приложение от пользователя. В-третьих, наличие некоторых проверок может привести к проблемам при прохождении appstore review, либо при работе приложения, ведь многие проверки заключаются в том, что приложение пытается делать то, чего приложениям на не-jailbreak устройствах делать недозволенно.
Вывод: Аргумент ошибочен. Не будем защищать приложение и данные пользователя от самого пользователя.
Системные скриншоты АргументСистемные скриншоты не маскируются, и могут содержать приватные платежные данные клиентов. Системные скриншоты хранятся в памяти устройства и легко доступны при подключении к компьютеру.КонтраргументНу опять же, скорей проверялся незалоченный телефон. Для системных скриншотов тоже используется «iOS Data Protection», и в залоченном телефоне они недоступны. А если телефон разблокирован и до него есть доступ — то посмотреть скриншоты не составит труда никому.
ВыводАргумент надуманный и призван посеять панику, ведь скриншоты защищены на уровне системы.
Отладчик АргументПриложение при старте не производит проверок на наличие отладчика, что позволяет восстановить алгоритмы работы приложения и модифицировать его.
КонтраргументВосстановить алгоритмы работы — непонятно в чём цель этого действия и зачем о нем писать? Никаких секретных алгоритмов у нас нет, а модифицировать приложение можно только при наличии jailbreak, и мы об этом уже писали — это может повредить только самому пользователю.
ВыводАргумент бессмысленный. Непонятно, зачем он приведен и понимает ли автор так называемой «презентации» смысл того, о чем пишет.
ИТОГ:
Как видите, пункты безопасности в экспресс-анализе затронуты верные, но их трактовка и подача вызывают некоторые вопросы.
Из всех перечисленных аргументов имеет смысл улучшить только безопасность соединения, применив пиннинг сертификата. В свое время мы предлагали это сделать заказчику, но не продвинулись в решении этого вопроса на стороне сервера. Возможно, этот анализ поможет нам в диалоге с заказчиком в качестве дополнительного аргумента.
В целом, товарищи сотворили презентацию в красном цвете с громкими словами и, как вы уже увидели, неглубокими утверждениями и навели панику на компанию-заказчика.Объективен ли был этот анализ и какова его цель? Правильно ли потрачены время и деньги нашего клиента? Насколько вообще этично с профессиональной точки зрения приводить заведомо некорректные аргументы против чужого продукта?
Как говорится, кто проверит того, кто проверял? Мы всегда рады конструктивной критике по своим продуктам, но тут уровень аргументации и адекватность подхода компрометируют саму идею перекрестного анализа.Удачного всем дня и успехов в разработке приложений… безопасных приложений.
