Вопрос или проблема
Из личного опыта, многие мобильные приложения, которые я тестировал, не активнo обнаруживают и предотвращают (с предупреждением) или даже блокируют запуск приложения на/в:
- корневом/jailbroken устройстве Android/iOS
- эмулированной среде
- устройстве с устаревшей iOS или с устаревшим Android
Хотя это хорошо для целей тестирования безопасности, можно предположить, что в общем случае вы захотите предотвратить запуск вашего приложения на таких устройствах с самого начала, поскольку это может представлять дополнительные риски для данных, которые обрабатываются в приложении. Для устройств с устаревшими операционными системами (ОС), которые больше не получают обновления безопасности, я бы применил принцип “предположить нарушение” из модели нулевого доверия.
Я мог бы представить, что предпочтительно аппаратное подтверждение было бы идеальным для “обнаружения root”1 и для предотвращения запуска приложений на корневых/jailbroken устройствах. Для “обнаружения эмуляции” можно использовать тот же или похожий подход к обнаружению эмуляции для Flutter, хотя мне это не кажется очень надежным. Для устаревших операционных систем2, которые больше не поддерживаются, можно просто убрать их из Play и App Store для определенных мобильных версий ОС для новых установок. Кроме того и в обратной совместимости (когда это будет представлено достаточно рано) можно ввести активную проверку, которая установит дату окончания использования определенных версий ОС, или, более надежно, вызвать API, чтобы иметь возможность ‘прекратить’ (и, возможно, удалить данные приложения) на старых версиях приложения без необходимости сначала их обновлять.
Должны ли разработчики мобильных приложений принимать активные меры против трех упомянутых случаев, и должны ли аудиторы безопасности, тестировщики на проникновение, возможно, информировать разработчиков мобильных приложений о нехватке таких мер? Существуют ли известные отраслевые стандарты, требующие или советующие подобные меры для мобильных приложений?
1: Например, такая как библиотека RootBeer для Android.
2: Что также сообщается как проблема в разделе ‘Анализ манифеста’ статическими анализаторами, такими как MobSF следующим образом: “Приложение может быть установлено на уязвимую версию Android. Это приложение может быть установлено на более старую версию Android, которая имеет несколько уязвимостей. Поддерживайте версию Android => 10, API 29 для получения разумных обновлений безопасности.”
Нет, такое требование ухудшило бы безопасность, а не улучшило. Учтите, что GrapheneOS считается более безопасным, чем стандартный Android, но то, что вы предлагаете, запрещало бы это.
Исключение эмулированных сред снизило бы безопасность, а не повысило. Как пользователь, я мог бы запустить конкретное приложение в эмулированной среде специально потому, что не доверяю этому приложению. Поэтому по соображениям безопасности я решил не предоставлять приложению полный доступ к моему устройству, а запускать его в закрытой среде.
Вы предлагаете предотвратить это по соображениям безопасности. Чью безопасность вы пытаетесь защитить здесь? Для меня это выглядит так, что разработчик приложения считает, что их безопасность важнее моей пользовательской безопасности. Мне это кажется плохой идеей.
Ответ или решение
Необходимость активного предотвращения работы мобильных приложений на устаревших устройствах, рутированных устройствах и эмуляторах с целью повышения безопасности является предметом обсуждения в сообществе разработчиков. Этот вопрос имеет множество нюансов, и, хотя существуют веские аргументы в пользу такой практики, важно учитывать и потенциальные риски и последствия.
Аргументы в пользу предотвращения работы на устаревших и рутированных устройствах
-
Безопасность данных: Устаревшие операционные системы не получают обновлений безопасности, что делает их уязвимыми. Использование таких устройств для доступа к приложениям может подставить под угрозу личные данные пользователей. Применение принципа «предположим, что произошла утечка» (assume breach), как вы упомянули, действительно имеет смысл. Поэтому можно обоснованно требовать от пользователей обновления на более современные и защищенные версии ОС.
-
Управление рисками с рутированием: Рутирование (или джейлбрейк) устройств позволяет пользователям обойти стандартные ограничения системы, что делает их более уязвимыми для вредоносного ПО. Аргумент в пользу использования технологий для обнаружения рутирования (например, библиотека RootBeer) имеет право на жизнь, особенно в приложениях, которые обрабатывают чувствительные данные.
-
Поддержка стандартизации: В некоторых отраслях могут существовать стандарты, которые требуют от разработчиков принимать меры для защиты данных. Например, передовые практики в сфере финансовых технологий (FinTech) стремятся к повышению безопасности путем ограничения доступа к приложениям на уязвимых устройствах.
Аргументы против
-
Сложность и универсальность использования: Как вы упомянули, некоторые операционные системы, такие как GrapheneOS, предлагают повышенный уровень безопасности, несмотря на то, что они могут быть классифицированы как рутированные или модифицированные. Забота о безопасности пользователя должна быть важнее, чем удовлетворение интересов разработчика.
-
Использование эмуляторов: Эмуляторы могут служить средством защиты пользователей от потенциально небезопасных приложений, позволяя им изолировать приложения от основной системы. Запрет на использование эмуляторов может создать дополнительные проблемы для пользователей, которым нужна степень контроля над своими устройствами.
-
Технические ограничения: Обнаружение рутирования и эмуляции не всегда надежно. Существуют возможности «обмануть» такие детекторы, что может привести к ложным срабатываниям и недовольству пользователей.
Вывод
Исходя из вышеизложенного, можно сделать вывод, что мобильные разработчики должны принять активные меры для предотвращения работы приложений на устаревших и рутированных устройствах, особенно если приложении обрабатываются чувствительные данные. Однако это следует делать, учитывая компромиссы и обеспечивая пользователям возможность выбирать.
Стандарты безопасности, такие как PCI DSS для финансовых услуг, могут рекомендовать такие меры, и информационная безопасность должна оставаться на первом месте. Однако всегда следует помнить о гибкости и необходимости предоставления пользователям возможности контролировать свою собственную безопасность, особенно в случае с эмуляторами и адаптированными ОС.
Таким образом, разработки должны учитывать не только безопасность приложения, но и оставлять пространство для выбора пользователя, что может улучшить общую безопасность всех взаимодействий.