Как защитить IPA приложения от хаков, если возможно обратное проектирование

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

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

Теперь клиент настаивает на том, чтобы мы зафиксировали эти дыры в области безопасности и опубликовали приложение. Однако мы не знаем, как им удалось получить все эти данные из приложения IPA. Я просмотрел это через SO и нашел конкретную запись, в которой упоминается ссылка , в которой говорится, что вы не можете сохранить свое приложение от взлома.

Пожалуйста, помогите мне устранить эти уязвимости безопасности или, если это невозможно, как убедить клиента.

Изменить: Недавно просмотрела эту страницу. Похоже, что EnsureIT от Arxan может предотвратить использование IPA от обратного проектирования. Кто-нибудь испытал это?

Ответ 1

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

Что касается вашего вопроса: безопасно не предположить, что жестко закодированный URL-адрес, даже если он запутан за пределами веры, не может быть очищен от вашего продукта. Всегда разрабатывайте ваши приложения таким образом, чтобы безопасность пользовательских данных гарантировалась (насколько это возможно), даже если встроенные ресурсы были скомпрометированы. Если знание только одного URL представляет угрозу безопасности, то ваш подход и API ваших клиентов по своей сути небезопасны. Помните, что такая информация могла быть захвачена атакой "человек в середине" (и другими способами атаки).

Избегайте безопасности от неизвестности. Храните конфиденциальные данные только на диске, если это необходимо. Как правило, не допускается хранение ПИН/ТАН.

Некоторые мысли, которые могут (или не могут) убедить вашего клиента в том, что ваше приложение настолько безопасно, насколько это возможно:

Пока приложение работает на не-jailbroken-устройстве, маловероятно, что злоумышленник, даже со знанием внутренних приложений вашего приложения, может получить какие-либо пользовательские данные, поскольку iPhone обычно не предлагает возможности вмешательства с вашим приложением
Если злоумышленник может получить данные ваших пользователей и при условии, что вы защищаете эти данные всеми доступными средствами iOS (- > keychain → crypto chip → ...), то это не ваша ошибка. Это означает, что устройство либо взломанно, либо есть уязвимости для самой системы, которые были использованы, вы просто ничего не можете сделать с любой возможностью.
Невозможно предотвратить обратное проектирование вашего приложения. Даже если вы приложили больше усилий к обфускации, атакующий с сильной мотивацией все равно сможет получить то, что он хочет. Ваш клиент должен привыкнуть к этому, поскольку это факт.
Другие платформы страдают от подобных уязвимостей, однако на iPhone, по крайней мере, у вас есть несколько закрытая среда и снижение риска нападения с помощью троянов и т.д.
Правительства и охранные фирмы получают взломанные на регулярной основе, хотя теперь им нужно как защитить себя. Это означает, что жизнь по своей сути небезопасна, справляется с ней.