Избегайте отключения закрепления сертификатов Android - PullRequest
0 голосов
/ 07 февраля 2019

Я занимаюсь разработкой приложения для Android, в котором используется закрепление сертификатов (аналогично this ).

Однако я сталкивался с библиотеками динамических инструментов, такими как Frida или, что еще хуже, Возражение , которое может обойти эту защиту.

Я понимаю, что безопасность должна быть реализована на стороне сервера, но я бы хотел посторонних глаз посмотретьмой API.Кроме того, я также понимаю, что исполняемые файлы Java легко разбирать и анализировать.

Как я могу сделать этот процесс более сложным для злоумышленника, то есть выполнять основные команды, такие как objection '

android sslpinning disable

терпеть неудачу и укреплять мое приложение?Я видел, что в зависимости от имен активов этот процесс также завершается сбоем.

Есть идеи?

Ответы [ 2 ]

0 голосов
/ 10 мая 2019

Возможное решение

Как я могу сделать этот процесс более сложным для злоумышленника

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

Итак, при успешной аттестацииЧто касается целостности мобильного приложения, то облачной службой выдается кратковременный токен JWT, который подписывается с секретом, о котором знают только сервер API и служба аттестации мобильных приложений в облаке.В случае сбоя при аттестации мобильного приложения токен JWT подписывается секретом, которого сервер API не знает.

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

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

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

Есть идеи?

Вы можете попробовать применить собственное решение или найти существующее решение SAAS Mobile App Attestation, такое как Approov (я работаю здесь), которое предоставляет SDK для нескольких платформ, включая iOS, Android, React Native идругие.Для интеграции также потребуется небольшая проверка кода сервера API для проверки токена JWT, выпущенного облачной службой.Эта проверка необходима для того, чтобы сервер API мог решать, какие запросы обслуживать, а какие отклонять.

Сводка

В конце концов, решение, используемое для защиты вашего APIСервер и мобильное приложение должны быть выбраны в соответствии со стоимостью того, что вы пытаетесь защитить, и с юридическими требованиями для этого типа данных, например, нормативами GDPR в Европе.

Пройдя лишнюю милю

Вы, похоже, в безопасности мобильных приложений, я хотел бы порекомендовать вам:

OWASP Mobile Security Project - 10 основных рисков

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

0 голосов
/ 09 февраля 2019

Несколько сложных сред могут затруднить присоединение и манипулирование приложением Frida и аналогичных инструментов.Однако, имея достаточно времени, мотивации и / или денег, вы можете даже сломать эти рамки.

Однако обычно вопрос не в том, "использовать или нет", а в том, сколько денег вы готовы заплатить, чтобы получить эту небольшую дополнительную защиту?

Насколько я знаю, нетбесплатные или даже дешевые защищающие фреймворки (исправьте меня, если я ошибаюсь, и предоставьте ссылки на эти бесплатные / дешевые решения с хорошей защитой), поэтому вопрос лишь в том, какую защиту вы хотите и сколько готовы заплатить.

Примечание: Proguard и R8 не являются закаливающими фреймворками! Они лишь немного запутывают код, но особенно когда дело доходит до закрепления сертификата и отключения его через Frida, они не предлагают никакой защиты!

...