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

Question

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

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

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

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

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

Answer 1

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

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

Избегайте безопасности из-за неясности.Храните конфиденциальные данные только на диске, если это необходимо.Как правило, не разрешайте хранение PIN / TAN.

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

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

Answer 2

Я недавно исследовал эту тему и нашел эту статью полезной, особенно в цитируемой части:

Код для собственного приложения хранится в виде двоичного исполняемого файла, который дополнительно шифруется; его дешифрование выполняется только тогда, когда исполняемый файл загружается процессором в оперативную память, и весь процесс дешифрования происходит на аппаратном уровне. Вот почему очень сложно создавать инструменты для дешифрования в автономном режиме. Единственный способ расшифровать зашифрованные двоичные данные - использовать взломанное устройство с несколькими установленными специальными инструментами.

Безопасность в iOS: защита содержимого файла .ipa от Стояна Стоянова