Данные
Улучшение перемещает модели в приложение для приложений без или с ограниченным доступом к сети.
Эти модели представляют значительный IP для наших клиентов, и это важно что мы защищаем любые данные, загруженные на устройство, от кражи.
С того момента, как вы публикуете данные / секреты c, в том смысле, что вы включаете их в двоичное приложение своего мобильного приложения или загружаете позже в устройство и хранить его в зашифрованном виде, вы должны считать его скомпрометированным. Здесь нет никаких доказательств, что бы вы ни пытались, вы можете только усложнить кражу, но со всеми инструментами, доступными для интроспекции и инструментального кода во время выполнения, ваши зашифрованные данные могут быть извлечены из функции, которая их расшифровывает:
Расшифруйте строки данных в памяти перед загрузкой в JS ВМ.
Пример очень популярной инструментальной инфраструктуры: Frida :
Внедряйте свои собственные сценарии в процессы черного ящика. Подключайте любую функцию, шпионите за криптографическими API или отслеживайте частный код приложения, исходный код не требуется. Отредактируйте, нажмите «Сохранить» и сразу увидите результаты. И все это без этапов компиляции или перезапуска программы.
Закрытый ключ
Сейчас я думаю использовать что-то вроде iOS AES-шифрования. Не зашивать закрытый ключ в приложении, а вместо этого передавать его через https после входа пользователя в систему, сохраняя его в цепочке ключей.
Хотя не жестко кодировать закрытый ключ на устройстве, это мудро решение, что это не мешает злоумышленнику выполнить атаку человека посередине (MitM), чтобы украсть его, или использовать инструментальную платформу для подключения к коду, который хранит его в цепочке для ключей, но вы, возможно, уже знаете об этом или нет , потому что это не ясно из:
Я вижу очевидные недостатки этого подхода ...
На мой взгляд, и в качестве примечания, я думаю, что Во-первых, вам и бизнесу необходимо подумать, перевешивают ли выгоды для пользователя от того, что прогнозы делаются локально на их устройстве, огромный риск переноса данных из облака на устройство, и необходимо ли обеспечить защиту данных. следует принимать во внимание, потому что штрафы за нарушение данных могут иметь огромное влияние на будущее организации.
* 103 6 *iOS Решения
Каков наилучший метод и доступные параметры в iOS (> 11.0) прямо сейчас, которые не будут нарушать экспорт шифрования l aws или даже приложение Apple store rules et c?
Я не являюсь экспертом в iOS, поэтому я не могу вам сильно помочь, кроме как рекомендовать вам использовать как можно больше техник обфускации и само приложение во время выполнения -protections (R ASP) в верхней части решения, которое вы уже разработали для защиты ваших данных, чтобы вы могли усложнить жизнь злоумышленнику.
R ASP:
Самозащита рабочего приложения (R ASP) - это технология безопасности, которая использует инструменты времени выполнения для обнаружения и блокирования компьютерных атак, используя информацию изнутри работающего программного обеспечения.
R Утверждается, что технология ASP улучшает безопасность программного обеспечения, отслеживая его входные данные и блокируя те, которые могут допускать атаки, одновременно защищая среду выполнения от нежелательных изменений и взлома.
Вы также можете попробовать использовать передовые биометрические решения, чтобы убедиться, что реальный пользователь присутствует во время использования мобильного приложения, но помня, что более опытные злоумышленники всегда найдут способ для извлечения данных на управляющий сервер. Вопрос не в том, смогут ли они, а в том, когда это произойдет, и когда это произойдет, это нарушение данных, и вам нужно заранее спланировать, чтобы справиться с его коммерческими и юридическими последствиями.
Итак, после того, как вы примените наиболее подходящие средства защиты приложений, у вас все еще есть проблема, которую нужно решить, которая сводится к тому, чтобы ваш сервер API знал , что делает запрос, потому что кажется, что вы уже реализовали аутентификация пользователя для решения от имени , который делает запрос.
Разница между КТО и ЧТО обращаются к серверу API
При загрузке данных в устройство вам нужно подумать, как вы обеспечите, чтобы ваш сервер API действительно принимал запросы на загрузку от чего вы ожидаете, подлинного экземпляра вашего мобильного приложения, а не от скрипта, бота и т. д. c., и мне нужно предупредить вас, что аутентификация пользователя говорит только от имени , который запрос делает, а не что это делает.
Я написал серию статьи об API и безопасности мобильных устройств, а также в статье Почему вашему мобильному приложению нужен ключ API? вы можете подробно прочитать разницу между n who и what обращается к вашему серверу API, но я извлечу из него основные моменты:
The what это то, что делает запрос к серверу API. Действительно ли это подлинный экземпляр вашего мобильного приложения, или это бот, автоматизированный скрипт или злоумышленник, вручную копающийся на вашем сервере API с помощью такого инструмента, как Postman?
The who является пользователем мобильного приложения, которое мы можем аутентифицировать, авторизовать и идентифицировать несколькими способами, например, используя потоки OpenID Connect или OAUTH2.
Подумайте о who как пользователь ваш сервер API сможет аутентифицировать и авторизовать доступ к данным, а также думать о what как о программном обеспечении, выполняющем этот запрос от имени пользователя.
Ясно это заблуждение возникает снова и снова, даже среди опытных разработчиков, девопов и разработчиков, потому что наша отрасль больше ориентирована на выявление кто , а не что .
Подход других
Я вижу очевидные недостатки этого подхода и хотел бы услышать, как другие подошли к этому?
Как я сказал ранее Я не являюсь экспертом в области iOS, и мне нечего предложить вам, кроме того, что я уже упоминал в разделе iOS Solutions, но если вы хотите узнать, как можно заблокировать свое мобильное приложение для API сервер, чтобы с очень высокой степенью уверенности отвечать только на запросы от подлинного экземпляра вашего мобильного приложения, тогда я рекомендую вам прочитать мой принятый ответ на вопрос Как защитить API REST для мобильного приложения? , в частности, раздел Защита сервера API и раздел Возможное лучшее решение , где вы узнаете, как концепция аттестации мобильных приложений может стать возможной. Решение этой проблемы.
Хотите go Дополнительную милю?
В любом ответе на секретный вопрос я всегда хотел бы сослаться на потрясающую работу фонда OW ASP .
Для мобильных приложений
OW ASP Mobile Security Project - 10 основных рисков
The OW ASP Mobile Security Pr oject - это централизованный ресурс, предназначенный для предоставления разработчикам и командам безопасности ресурсов, необходимых для создания и поддержки безопасных мобильных приложений. В рамках проекта наша цель состоит в том, чтобы классифицировать риски мобильной безопасности и обеспечить средства управления развитием, чтобы уменьшить их влияние или вероятность использования.
OW ASP - Руководство по тестированию мобильной безопасности :
The Mobile Security Testing Guide (MSTG) - это подробное руководство по разработке, тестированию и обратному проектированию безопасности мобильных приложений.
Для APIS
OW ASP Топ 10 безопасности API
OW ASP API Security Project стремится предоставить ценность разработчикам программного обеспечения и оценщикам безопасности, подчеркивая потенциальные риски небезопасных API и демонстрируя, как эти риски могут быть снижены. Чтобы способствовать достижению этой цели, OW ASP API Security Project создаст и будет поддерживать документ «10 основных рисков безопасности API», а также портал документации для передовых методов создания или оценки API.